How to Hire Great Developers

In the past couple of days, a couple of great essays have surfaced that take my original riff on the topic of inane interview questions and improve on it.

First up is Worse Than Failure (sorry, I still prefer their old name, “The Daily WTF”), discussing Job Interview 2.0. I don’t know about the author’s assertion that Microsoft was the first to use the technique of asking prospective developers about such things as why manhole covers are round or how to estimate the number of gas stations in the US. But regardless — I’m with him on this one. Who cares why manhole covers are round? Why not look up the number of gas stations on Goog … er, on the web? The basic point, I think, is well taken, and is summed up by the following quote from WTF:

One reader shared with me the story of his brainteaser interview.

During a screening interview, I was asked how I would design a bike fit for someone visually impaired. I responded something to the effect of, “What, like, for blind people?”, and she answered yes.

I thought for a moment and then I responded, “Well.. a blind person riding a bike doesn’t sound like a very safe idea, so I would make the bike stationary, maybe with a fan blowing in the person’s face. He probably wouldn’t even know the difference.”

She was speechless.

Now, granted, he will not get the job. Despite the complete absurdity of the design request, and the complete practicality of his answer, the job will go to a candidate who manages to answer the question by designing an extremely overcomplicated solution for a completely non-existent problem. And that candidate will be the same person who designs their software.

Finally, Imram on Tech has a post making the point that there is a distinction between one’s knowledge of programming arcana and one’s ability to be a good developer. A sample:

There seems to be a popular misconception that if a software developer knows a lot about programming then it follows that they’re a good developer.

Returning to the football analogy, imagine you were back at school picking players for your team. Who gets picked first:

1. The kids who are athletic and good at football
2. The kids who are athletic and can make a good run down the pitch, even if their football specific skills aren’t that great.
3. The kids who aren’t athletic but know how to play football
4. The kids who aren’t athletic and know nothing about football

This is another excellent point. There is a widespread misconception (even stronger in some other countries than here in the US) that memorizing huge quantities of facts is a prerequisite for being a good developer. The truth is that basic ability is the first prerequisite — by some accounts I’ve read, 60% of the population can’t grasp the basics of programming if their life depended on it; some colleges screen applicants for their computer science departments by testing for this.

If you can conceptualize basic variable assignment and flow control, then the next step is to have and hone a great problem solving ability. Decent people skills are part of this. Raw knowledge comes in last, because if you have the ability to perceive, define and solve problems effectively then you have the ability to find knowledge when you need it and the motivation to educate yourself as and when needed.

This isn’t to say that experienced developers won’t have a great deal of knowledge in their heads. But it will be knowledge acquired in response to the problems they’ve already solved and/or are interested in, and their ongoing self-education will be driven by the demands of their current projects and their own curiosity. They will not simply memorize a bunch of stuff in advance. That is what reference materials and Google and a developer’s own corpus of code are for.

Bottom line: the last thing you want on your team is a developer whose mind is cluttered with irrelevant details but has no common sense, or who is prone to favor the most baroque and theoretical path to a solution.

A last point: even if these interview tactics were desirable, asking someone to answer these kinds of questions under the unique and artificial pressures of a job interview, is probably not going to produce accurate results anyway. You could argue that you want the people who are confident and can deliver under pressure, but I’d counter that if your work environment is under-resourced to the extent that it’s a pressure cooker, you’re going to burn out even super-stars. Hello? This is knowledge work, people. You need to provide a relaxed environment conducive to concentration, focus, exploration and continual improvement.

So how should you evaluate developers? My practice has always been to discuss real-world projects and problems we’re facing, and ask candidates how they would approach those problems. I am much more interested in the thought process that goes into analyzing the problem, the kinds of questions they ask, and whether their analysis and solution are valid, than I am in the minute details of how they would mechanically implement their solution. If they can discern what needs to be done, then they can be trained (or can come up to speed on their own) with any tools and practices in our environment that they are not immediately conversant with.

I also look for curiosity. Not the ersatz, abstract curiosity of someone who likes to solve obscure puzzles, but the strong drive to find pragmatic, better ways to accomplish the mundane things most businesses want implemented in software. Incurious people generally make lousy developers. It’s hard to have any fire in your belly for something that bores you. I’m looking for someone who’s actually enjoys continuous improvement — whose greatest pleasure is tweaking code and improving their development approaches to make them better even when not asked to, yet knowing the point of diminishing returns beyond which they should not go.

This brings up a fact which should be painfully obvious: developers should be interviewed by developers, not by managers with no current dev experience or by HR drones. Even more so than in many professions, “it takes one to know one”. This is the kind of stuff that just can’t be evaluated by anyone but an experienced developer.