The dark underbelly of Silicon Valley recruiting (and there is a silver lining)
blog.kabaim.com
blog.kabaim.com
The reality of what the press says and what tech companies say about recruiting is belied 100% by my experience looking for a job.
First of all, for job seekers, your ability to discover good-fit/good-match employers blows. Supposedly everybody needs 'engineers.' Yet 80%+ of job listings seem to be from recruiters who will vaguely describe their job, don't have a good understanding of the skill required, and can't tell you who they're hiring for. Okay, maybe a third of those recruiters have decent job descriptions. But still.
Likewise, most of the jobs listed from non-recruiters either list unreasonable/stupid/silly experience requirements (5yrs+ plus experience with agile development? You can 'learn' agile in a week), or are obviously legacy companies that nobody in their right mind will want to work for (coldfusion? really?).
And invariably when you do find something from an interesting company that's not through a recruiter, what they want is 5 years experience with their exact technology stack.
I know quite a few skilled programmers and they do not have loads of people hunting them down throwing money at them (though somebody should be).
What I believe has happened is that only programmers in a narrow community with a narrow set of experiences are being considered for reasons that are not sensible.
I would encourage any company that's trying to find good people to make good people aware that they're looking. I won't go through wishy-washy recruiters. Anybody else who cares where they work isn't going to be doing so either.
* Ability to quickly learn new languages
* Ability to quickly understand and use appropriate design patterns where sensible (even if they are unaware of the whole idea of design patterns and just do it by doing what's sensible to them from experience).
* Ability to use or adopt new stack technologies (IE maybe they're an expert in PostgreSQL or Cassandra, but if for some reason they have to use MySql or Hadoop it's not a big ordeal). Same thing for coming to grips with stuff like 3rd party APIs.
* Balance documentation and clear design approach with ability to accomplish things quickly.
* Are able to avoid poor design and extreme inefficiencies, while also being able to recognize that not everything needs to have groundbreaking performance or architecture.
* Are accustomed to creating good baseline unit tests.
* Ability to code clearly and quickly.
* Able to work well with a team and effectively communicate.
* Some ability to express design and implementation opinions graphically.
* Ability to learn and adapt and use documentation/google and knows when to ask and when to look something up.
Of course this isn't to say that there's no such thing as valid job requirements. But odds are if you're looking for a PHP dev, for example, you don't really need a 'PHP Dev,' though they might be a bit cheaper than other kinds.
Rehash of what I don't think is usually super important:
* Ability to program natively in a language on a whiteboard (though ability to use psuedocode on a whiteboard is good).
* Familiarity with specific development methodologies (the way a team works can usually be picked up quickly).
* (Most of the time) Tons of experience with a specific language. In general, the more general purpose the language, the less experience matters (I think), though there are some other factors that go into play. It does depend on what/where the programmer will be working on. But in general, I'd say a brilliant programmer who hasn't used your language or stack a lot might be more valuable than someone who does -- the heretic's nectar can be sweet indeed.
* Implementation knowledge of the head of some obscure algorithm or data structure. Maybe you should know of the algorithm. But there's no reason a good programmer necessarily knows every algorithm and its implementation details off their head. Likewise, odds are, that for the average programming job, the programmer will not be implementing a high-performance version of any algorithm because they'll be using core functionality in the language, its libraries, or their tech stack :( . And the exceptions to the rule will require some R+D time anyway.