Posts tagged 'job search'
-
My time the past couple days:
- Writing Project Euler solutions in Ruby, using the "get it done, get it fast, get it good" (alt: make it X) philosophy
- Realizing that I could no longer write the Python code I wrote less than a year ago
- Crushing it on phone interviews that I didn't plan on having anyway
- Faceplanting on an in-person interview that I should have been able to do better on
- Writing and analyzing algorithms with people at the office
- Taking on projects that sound interesting until you realize that you're trying to bite off way more than you can chew
It's important to stay busy with productive work, but it's tempting to think that what you're doing is valuable when in truth the marginal utility is pretty low.
In other news, it's interesting to see how natural writing Project Euler solutions is in Ruby compared to Python. I have many fewer head-scratching moments when it comes to the natural plan of attack—generally, I can just implement the solution that comes to mind, and it runs well enough. Project Euler is, I think, like Alaska: it's not where you learn, it's where you prove yourself. It just happens to be the biggest name in toy programming problems, and many people assume that it's good at teaching you… something.
Not sure what else to say. I'm trying to keep at good habits, and I started thinking about what I wanted to write on the train in today, but then I started thinking about how to build an Abstract Syntax Tree in Ruby (and whether I really need to in the first place, to do what I'd like) and lost what I was going to write. Oh well. More practice; back to the grind.
-
I don't know why this title made sense to me, except in that I haven't written in a couple days. It's been interesting, for sure—I've had a couple phone screens, which have been all over the map, but tremendously useful for learning how to better present myself—but I haven't felt like doing major work for a while.
Is this bad? The projects I'd like to do are hard to wrap my mind around at the moment; part of me wants to learn a systems language in more detail, but I know that it's not a close synergy to anything that's going to get me work, now. The only places that want systems languages want Java for the backend (or C#); learning C would definitely be a stretch in terms of immediate utility. Is that so bad?
Maybe statistical programming would be better. I don't know; there are so many things to learn out there, so many projects that could be useful to someone, and I could devote myself to them, but which? Will doing that make employers look on me more fairly? Do I want to work at a company where a single week of working in Angular would be the difference between me getting the job and not? (Probably not. A competent engineer could figure out what needs learned pretty quickly, and I don't know if I'd want to work for a company that would disagree.)
I want to have a job, so I can worry about more granular things, instead of whether I'll run out of money before this process finishes. I want to be learning a ton of new things about production code, and making my own projects on the side. I want to write a couple books and learn TeX and not feel guilty that I'm not working on finding work. Soon.
-
I've been thinking about interviews on a conceptual level a lot recently, and especially the question of what is my greatest weakness. Without exposing too many of my cards to people who might be interviewing me in the future, it's an interesting question, and one that's hard for me to nail down.
I have a hard time coming up with traits that are not both strengths and weaknesses. It reminds me of role-playing games: every skill point invested comes with an opportunity cost. Further, I have an outstanding question about real humans: to what degree are certain traits mutually exclusive? For instance, someone who looks really sharp all the time is probably not going to be the ultimate hacker; hygiene takes a non-trivial overhead cost on your mental processes that is (probably) incompatible with being a super-hacker.
We don't really know enough about how brains work to nail down everything there is to know about what traits are likely to manifest in a single individual. Does competitiveness relate intrinsically to violence or impulsiveness or something else? There's no way to know, yet.
So in light of all this, some things I'm not so good at:
- Putting down work when it's "good enough"
- Biting off small pieces of large tasks
- Trying to think through everything that could happen in an abstract situation instead of doing and seeing what happens
- Getting started
- Multi-tasking
- Giving myself enough credit
- Doing things whose purpose I don't understand
- Doing things when I don't respect the desired outcome
- Attacking a task via the sides instead of the front
- Killing my darlings
- Writing concisely; respecting my readers' attention
- Accepting less than an optimal solution
On the flipside, I am super-tenacious and will see a problem through to the bitter end, if it's possible at my level (e.g. without a PhD in Math and six years advanced study).
These bullets seem to cluster around a couple personality traits. I'm slow to start, slow to transition, and absolutely dogged in the middle. I work very well when I am concerned with the process and not the purpose—what I refer to as "suspension of disbelief" tasks. To elaborate, when I started in the Army it was easy for me to just perform, because I was working against my former self, trying to become faster, stronger, more Army, etc. When I just started at City College, it was easy for me to give my classes everything I had, because my purpose then was to get the best GPA I could, acting as if the degree was the only thing that mattered. Later on, I saw what a clusterf*** the Army was, and how misguided leadership was; later on, I saw what a house of cards the world of higher education was, and couldn't stay in that world when there are ways of educating that are clearly better.
The act of identifying trends and clusters gives some insight on how to attack them. For instance, when I don't respect the desired outcome of a task, try to identify something in it that will make me better. If, some day, the answer looks to be "get enough money to go home and do something that I care about", that will be a sign it's time to quit that job.
So, the answer to the "real" interview question—"what is your greatest weakness and what have you done to compensate for it—for me would be … something like this:
"I am not decisive when I don't have complete information. What I do to compensate is to try to identify some complete task that I can tackle, and set my mental benchmark for success in such a way that I do what needs done and move on to the next thing. By the time I've gotten my feet wet on something I understand the scope of the larger problem much better."
It's a work in progress, obviously.
-
For unto every one that hath shall be given, and he shall have abundance: but from him that hath not shall be taken even that which he hath. (Matthew 25:29)
Yesterday I was looking up an old contact (who is a lot like me, but much further along, and with enough money to not have to care), and the memories came back in a rush. It's hard to sum up what anything is, what any experience is like to people who aren't you, but I can mention one thing, the thing that I needed to read.
In this essay, he talks about how he writes. He has an easy writing style, and apparently people come to him and ask him how he writes so well. His response is that he deliberately writes what is easy and approachable (e.g. that which he knows a lot about), and in time the other things he wants to write get easier. He tackles those in their own time, once he has enough practice/warm up/etc. under his belt for those to be easy to write.
Like others, I write darlings, and it's hard for me to kill my darlings. It's pleasing to me that when others proofread my work, they point out problem points in the same places I see them ("Oh, this is no good… I'll leave it in for now, though…" "Yeah, this is no good, you should change this/take it out/jump in a lake"). That's not to say that I always know how something needs to be changed, only that I recognize weak spots.
Anyway, all this comes together into some thoughts about skill generation in general. Writing and graphic design and programming aren't so different in many ways, ways that could fill a book, which is not particularly surprising given my philosophy of "everything is everything". In keeping with the spirit of this entry, though, I'll point out that when you stumble in your craft, the best thing to do is keep working on something.
Admittedly, you will need time to let your brain process. When you make a typo and overlook it for an hour straight, that's usually a sign that you need to do something else, like run on the treadmill for an hour, drink heavily, and pass out. (By morning, all your problems will be much shallower.) There is a route to maximal learning and maximal skill development, and it doesn't typically involve doing the same dumb thing until you're too tired to do anything right, and by the way, you've just spent an hour anti-training by practicing bad habits.
It's been a long couple days, for no particularly good reason. I've actually made a lot of important progress—note here that I'm not saying a lot of progress, in an absolute sense—in getting my head screwed on straight and doing important work. I talked to a lot of people, in different contexts, and these low time, high value conversations are really great for figuring out what I want, and need.
I started sketching out a book that I want to write in parallel with the book I need to write (because my battery died and I had a long train trip, oddly). I think this book will feed into the book I've been trying to write for the better part of three years, if I can make some headway on it. Meanwhile, I have my eyes on a half dozen pet projects that can help strengthen my portfolio. None of them are small enough to sink my teeth into at the moment, and none of them are dire, but like writing, the act of thinking of pet projects leads to thinking of more pet projects. I still need to figure out how to have a brainstorming repository, since every time I start something it all just gets more fragmented, but that should come in time.
Ugh. In other news, I'm wrestling with some asset pipeline issues with heroku, and I'm about to tear my hair out. It's distracting me, and thus I'm not able to give enough attention to writing this. I know there's more I wanted to write, but I have a hard deadline tonight so I'll have to pick this up later, if I can find the track again.
-
I have to write for the book I owe in October starting soon, so I've been thinking more about writing in general and how things are communicated. (Perhaps this could be considered semiotic thought?)
The urge to try to tackle a different book has resurged, especially now that I'm writing here without the threat of fine. Writing is comforting; however, this style of writing is a bit too unrefined and "work avoidance" to really lead anywhere. If nothing else, the medium format stuff seems to be a good lead in to starting work, and getting into a good groove. I wonder if other people feel the same way, and that's why some people get to the office early and work on email?
(As a sidenote, perhaps that's reason enough to get out of bed early, other than the cat crying. Maybe I can find something to write about in a longer format and see what happens to my motivation/well-being.)
The segue here is that Tommy asked me for a progress update, and I described to him some of my struggles, and he was pretty good at reassuring me that I'm on the right path. But what helped, and is helping, most, are the short phrases—remember, when you came here, you were already above the top 95%; what's more important than the company is the team you'll be working with, etc.
I try to collect little clippings and reminders of things and hold on to them until they stick with me. This is one of my lingering problems, actually: getting all the clustered information out of my head and into a format where I can manipulate it. I was actually considering exploring some different technologies in order to make a Scrivener knock-off, because the plethora of similar tools never seem to quite mesh up with my needs, but I know that that's probably another blind alley. If I could figure out the interaction model or something, maybe it'd be easier, but it certainly wouldn't be trivial by any means.
It's surprising how much productive work relies around having the right information available in the right format and being able to manipulate it in an easy manner. This is probably the central problem of software, in short: while maybe 90% of apps boil down to CRUD, making interactions painless and contextually meaningful is the where interesting work happens.
There's a link here, though: getting the right "core idea" matters as much in writing as it does in software (or mathematical proofs, or… so many things). In most mental work, there's some foundational piece that helps you stay on track, and helps the audience get in tune with you. Good writing will have a rhythm, where a long description will build to a purpose, or a witty or touching statement, and that will stick with people. Good software has a clear purpose, I think, and should be similarly scrutable to an audience.
-
What are the relative demand levels for entry-level engineers vs. engineers with experience? Are they equivalent? Presumably, if the pipeline stays somewhat stable, there should be slightly fewer devs with 3+ experience at any moment than entry level devs; where are the demand levels?
If you just can't fill a slot for a mid-career developer, and you have a reasonably-sized team (i.e. not a single devops, a CEO, and a dude in sales), you should be able to take up some of the slack by hiring junior devs and managing/mentoring them adequately.
A company that can figure out how to do this will be picking up money that others are leaving on the table, because a lot of those Jr Devs will end up being the mid-career devs with (hopefully) a bit of loyalty.
Have I said these exact words before?
-
The more your name is out there, the more interest you can get and the more you can identify your market value. It's analogous to a stock market: a low-volume symbol will likely have a large spread, which is (analogous to) the margin of error.
I'm not intending to tip my hand too much, and worst case I can make some of these entries private in case I feel that they put me on a weaker footing in my search. But the cost of not marketing yourself, in my case, may turn out to be about $15-20k/year.
I know who I am, but without marketing, no one else is going to know that I've got a lot to bring to the table. But the fears that I have—of being judged, of not having others see me the way I see myself—while not precisely abnormal, are doing me a disservice in this process.
All I want to do is to work on coding projects, because I'm not my own best advocate, but I know somewhere out there is a company that really wants me, they just have no way of knowing it yet.
In related thinking: I am not as virulently against marketing as a lot of people out there. It's nice to just be able to research the thing you want, look through objective(ish) reviews, and then make an informed decision, but I honestly believe that only works for the barest minority of products. There is some threshold, before which a product is not getting enough people using it who honestly would want to. Tracking information about consumer preference and demographics is part of a process of getting sellers in contact with buyers who would lean in their direction; I think the common (unstated) fear is that the established brands have the money to drown out more fringe companies.
In turn, though, and especially when some fringe company is trying to generate network effects, sometimes no one wants the minority player. In the internet age there's not a ton of room for another full OS, because each one siphons off talent, and it's really hard to develop all the features people have come to expect without an existing technology base. I suspect the next major OS will supplant someone.
Similarly, anyone could have seen the Seamless/Grubhub buyout coming. I don't want to have to figure out which company my local delivery joint uses; I just want some damned food. And there are a lot of Grubhubs out there. You haven't heard of most of them, and they'll probably die, or stay marginal for a long time.
Which might not, after all, be such a bad thing. Most regions have at least two grocery stores, and those grocery stores have operating regions… fragmentation isn't always bad. They are a highly commodified market, though: every single one of them sells Cheerios, bananas, and Ajax, so they're not that different, whereas two different websites in a similar field might have completely different interfaces and data models, as well as corporate partners/networks.
I don't know what an area of technology that can support true competition over a long period of time looks like, or if it can even exist. And I don't know if I really want to work for a will-have-been… but I know that engineering jobs are so transient that it probably doesn't matter in the end.
The next two years are for straight up learning. Don't forget that.
-
Continuing on the idea of identity, I'm starting to think that in any practice as personal as job hunting, it's tremendously challenging to disassociate yourself from the process of searching. Meaning, largely, that you're never not looking for work for yourself, you're always thinking about what you'll be growing into in the (near) future when you're looking for work.
Perhaps the key, especially for someone as identity-sensitive as I am, is to pretend that you're looking for the sake of someone else. I can give good advice to others, and I know what I should be doing, but thus far I've been terrible at following through.
I can't imagine myself at a lot of these places, but I have to credit that at least partially to my lack of imagination.
In the meantime, I think my goal until I run out of ramen is to pretend that everything is about someone else, and that I've just been employed by this person to do the legwork of a hard-core job search, and that they're the one who is living in terror.
-
I've just started to read Corman's Algorithms, and in the first chapter a thought occurred to me.
There was a recent post about how inter-connected the Facebook codebase is. First of all, I found it quite surprising how much code there is, but I assume a good chunk of it is for scalability, which is certainly important (it's basically a mystery to me how facebook works at all, given that there's no way their user database can exist as a single object on a single machine).
However, thinking further, and thinking about the sorts of companies I see out there, it seems like there are a lot of people solving the same kinds of problems. And between one thing and another, I started wondering: how much of this is because our languages for expressing common problems haven't matured?
There's a cap on median engineer intelligence (it doesn't really matter what this means, but for the sake of argument, let's say the median engineer working in web technologies has an IQ no higher than 130, or two sigma above the population). Engineers are in a weird spot inasmuch as they work in one of the few industries where your job is very similar to your training and tool-building. A teacher can take classes on being a better teacher, and make resources to make teaching better and easier, but at the end of the day if they don't get in front of a classroom, they're not doing their job.
An engineer, on the other hand, can write a framework to make their work easier, learn (or create) a domain-specific language to speed up one aspect of their job that's repetitive, and at the end of the day have in hand new knowledge, work that pays the bills, and a tool they can release for other developers to use. This probably goes a long way in explaining the galapagosation of technologies, especially web technologies.
At some point, the learning curve of understanding how everything goes together becomes too challenging. Thus, our median engineer can't get much more efficient, because there are too many things to keep track of, and too many things that can break, and he wants to understand his toolchain and not look a fool because he can't tell his boss why the database got borked.
The thing is, we already have specialists (Database Engineers, SysAdmins, Front-end, Back-end, Project Engineers, the list goes on), and the role of "DevOps" kind of papers over the fact that at some scale, a company should be concerned with differentiation of responsibilities. All engineers should have some idea of how their work might affect other domains, but the job of optimization should lie in the hands of experts. (Note here Conway's Law, which states that "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations".)
Is it possible to make a framework which would make engineers more productive, and capable of expressing higher-order concepts without having to worry about the entire stack?
One attempt at an answer: the sorts of problems that companies are focused on solving largely center around CRUD, certainly. We're getting to a point where most of the things people want to accomplish involve finding a collection of rows in a database, and presenting them in a way that makes sense to users. Visual pattern matching, just-in-time data delivery, etc, are all very important to making a successful application. But when all the code you use on the front-end is visible to users (via JavaScript) and the actions people take are generally similar across the board (CRUD), creating a niche relies on largely on branding and network effects.
The original "killer app" on Facebook was (probably) checking out the pictures of cute girls in your classes, and bragging about your awesomeness in an attempt to improve social standing, and not much has changed. They leverage more aspects of homo now, ten years on—the desire to be informed, the desire to feel social without the costs—but these things depend on the network that was bootstrapped via "cool, attractive young people".
And yes, I'm being a bit glib, but the problems that Facebook solves in interesting ways mostly center around speed, availability, scale, and presentation. The CRUD core is kind of… boring?
The company that eats Amazon's lunch, by contrast, will make it easier to actually shop, and not just find something close. This is presentation and filtering layer technology, and Amazon's existence hasn't shut the door on other online marketplaces the way Facebook has largely supplanted all other entrants to vanilla social networking.
Amazon's power has come, in turn, from its infrastructure and its internal APIs. Most engineers, when they hear "Amazon" now, will think more naturally of AWS than of the original online bookseller. Sure, Amazon will always mean books on some level, but they drive so. much. of the web that I wouldn't be surprised if that becomes their core business (just like I joke about Google becoming primarily a car manufacturer).
[A funny sidenote: how many online stores, I wonder, are running on AWS on the backend? Amazon is pretty content-agnostic, even when the instances they're hosting would compete with their original niche.]
Meanwhile, technology stacks are maturing—
redisfor cache,capistranofor server management,dockerfor deployment—thus freeing engineers from having to roll their own, so to speak. Interesting companies are getting more meta (sidenote: I really need to play with SquareSpace to see what they enable people to do… but it's possible that they'll kill the indie web dev)… and I don't actually know what the engineers are doing at the rest of these companies? Is it all just gluing frameworks together, whiling away time until the company is aquihired?And there's something empowering to playing the "Full Stack Engineer" game as long as you can. Outside Project Management, FSEs are among the few who can say they're able to realize a vision, which the parts-and-glue, division-of-labor engineers probably can't.
Other than inertia, then, I suspect a primary reason this industry hasn't settled on a single stack is because as long as there's capital flowing, people are having fun at work—and occasionally making money doing so. If software engineers collectively decided they wanted to change the world in a more meaningful way, they certainly could (or at least could make a good stab at it). However, at that point, the majority of the industry would be consigning themselves to grunt work, the sort of work that mostly appeals to milquetoast personalities with pocket protectors, and late-career people with families and hobbies.
A business idea, then, would be "do whatever would make software engineering boring, the fastest, for the most people". That would pull the rug out from under the entire field for a while, though, until the middle-road engineers could figure out a way to build on top of this new stack and have fun doing so.
-
A summary of the majority of the postings I see:
- We want a full-stack engineer
- With skills in our exact tech stack (modulo one or two things)
- With five years experience
I'm not so stupid that I believe everything they say—with work that's important enough and with enough money coming in, they would find a way to make a non-ideal candidate work—but there is no way that there are enough engineers out there able to fit these criteria.
In any industry (or endeavor) there's going to be some "limiting factor". In chemistry, for instance, you generally try to use excess of your cheap reagent to try to get the highest yield possible of your most expensive reagent. However, one has to wonder, where are all the jobs posting asking for engineers with 10+ years experience? (Note: I'm not looking at the "senior" positions, but even if those are looking for people with 10+ years experience, where are the 15 year positions?)
This is the factor that makes me think, especially, that "5 years" is just a shorthand for "we don't want dummies". I doubt there's any industry where dead weight is as dangerous as it is in software; if you can get your foot in the door elsewhere, you can have a career as a mediocre … whatever… but there's not a lot of room for mediocre in software. If you can't understand the standard processes of abstraction, problem solving (etc), there's not much room for you in software.
However, the career progression for engineers is a bit shady. Salaries go from (slave wages of) about $45k to a healthy median of $80-90, up to about $130… and then what? I know one guy who was a project manager and made a very large salary, but I don't hear a lot about a lot of others.
That's an interesting thought, though: is the next level of abstraction above software engineer project manager? The thing that is more abstract than writing large projects is coordinating teams that write large projects, perhaps?
Back to the point, though: no one wants to bear the responsibility for training, and no one wants to bear the risk of getting that one guy who just will never add value to the organization. So I assume, at this point, that the entry point for engineers is a convoluted process of signalling and trials: internships, pedigree, networking, taking chances on people who seem otherwise intelligent.
So far there's nothing novel here. I'm curious, though:
- Is there an overall model that would be able to take advantage of the (presumable) under-tapped pool of future engineers with aptitude?
- Or, is there a model that would pull more people into the industry and train them to produce more?
- Is there a language (paradigm?) that would make programming accessible to more people, or are we already close to peak utilization of programming-capable people in the population at large?
- If so, is there a language (paradigm?) that would take the finite quantity of engineers and make them more powerful?
What's the skill cap on an engineer?