In times of diverse and widespread self-promotion and self-presentation techniques, it’s not as easy as it seems to know if you’re hiring great or mediocre programmers. The standard thing to do is see examples of previous work and ask for references. What we ourselves like to do is assign a quick but not easy programming task for the candidates to do before an interview. It’s been working fine so far :) On top of this you may want to look out for these candidate’s qualities while in interview:
Good programmer will see the core value of a feature and will speak if he / she thinks it adds no value to a product - as opposed to an average one, who’ll just do the work with no care for the long-term result and its relevance to the thing you’re all making. It’s not being cocky, it’s just taking the broad picture into account, which is ideal.
TEST: describe the product, ask a method of writing feature XYZ - the XYZ being a minor, non-important and non-game-changing feature - and it’s just fine if they suggest a good way of getting it done. But look for any hesitation in their reaction to the feature and possibly listen for a suggestion of an enhancement of it. This would be a great sign.
OWN VALUE VS. PRODUCT VALUE
As soon as you see a sing of someone trying to push a feature or method just because they thought of it, irrelevant of how it impacts the product - rethink the hire. Not even the best programmer’s ego should be overshadowing the path that was chosen for your product.
TEST: ask what was the best thing they’ve worked on and why - there is a tendency, that if they give their own individual work as an answer, and explain the vision was clearest and the path from start to finish as easiest - chances are their own vision is the only one they respect. It will not be true for all cases, surely, but normally it is.
FLEXIBILITY AND QUICK ADJUSTMENT
In computer programming these are essential skills to have, but programmers are also human (!), so some will be learning and adjusting way quicker than others. You really want the most flexible and open to new technology one.
TEST: unless the interviewee is experienced and you can track down the speed with which they’ve been introducing new languages to their work, there is no better way than doing a behavioural - learning test, in which a complex pattern is presented and they are asked to replicate it.
COMMUNICATION AND TEAMWORK ABILITIES
Even if your programmer will be working from home, alone - you still need to communicate a lot to make it work. A nice way of testing this is role-playing a daily-recap meeting. Notice what information comes up in the simulation (brief on what was done or a version extended by issues they’ve come across, thoughts they come up with for the product etc.). It’s not about how long the summary is, but how much valid information gets into it that you’re looking for.
With both time and work item control - this is crucial for work productivity. Whereas time control is fairly easy to test (the easiest test is punctuality of arrival for the interview and speed of getting to focus and work on the previously mentioned test), task management can be trickier to measure.
TEST: You can present a set of items that need doing and demand time estimation and priority setting. When compared to actual, standard (for your company) values for this, you will have some idea of the candidate’s preparation to properly self-manage - and estimate. But real information on this will come in time, so you may not want to sign a 12 month contract straight away.
Well, “best of programmers” to you :) They’re there - just keep looking!
Zbyszek Zemła is the founder of Shore Labs and Kanban Tool.