“All we want is a really good developer”

You’ve probably heard this or something similar before, maybe from a coworker or maybe even a hiring manager, but will rarely find a job post that straightforward.

Instead you often get a post with either a generic or overinflated title, cookie cutter requirements, a lengthy bulletpoint list of almost random tech buzzwords, and maybe a paragraph or two making the position seem super awesome!

Bonus points if you see the phrases “Rockstar Developer,” “Startup Mentality,” or “Hit the ground running.”

The long lists of requirements and technologies are often included in order to limit the number of applicants, making the hiring process less burdensome on the company. Problems arise because these aren’t real filters; applicants themselves are the ones determining whether or not their skills match those requirements. You will find that the filter won’t catch overly confident fools but might scare away amazing developers that don’t think they match up with a few of the buzzwords. You can administer a test in order to weed out the genuinely incompetent but, if you need to do that, you are already wasting your own time.

If a good developer is worth his or her weight in gold stock options, and a bad developer is ten times more destructive than just the one position’s loss of salary or productivity, how do you maximize your chances of finding good programmers?

You could reduce your job requirements down to an absolute minimum. Sure, your company might make extensive use of jQuery, but does that take more than a few days to get comfortable with? Then it’s not a requirement. Even strongly consider whether or not you want to specify a language as a requirement. You might have Java or Python deeply embedded in your company but, as long as you don’t need somebody capable of invoking dark magic to bridge the physical and virtual worlds, I would strongly recommend considering leaving it off as a requirement. An excellent developer can easily top a mediocre developer in almost any language within 3 months (~500 hours). It might seem like a gamble, but I think it is riskier to hire people who aren’t capable or interested in learning the right language for the job.

Feel out for people’s passion in the interview. You can find out whether or not people know how to divide in a loop during an interview but passion is where the money is. Jeff Atwood had a good theory on how to interview developers that I wholeheartedly agree with: “have the candidate give a 20 minute presentation to your team on their area of expertise.” This makes for an easy interview (on your part) and tells you more than you’ll find out with the normal array of questions.

Oh, and don’t ask riddles. Even people who like riddles don’t enjoy them while being stared at by random strangers in an intimidating setting.