Interviewing developers

UPDATED: New title, added extra subjects and links, also added my rule #1.

The intarweb is awash with debate about the best way to interview software developers. Even I pontificated about this subject a few months ago. That article of mine was somewhat short of solid advice, but it's hard to solve somebody else's recruitment problems. With the caveat that I'm talking about recruitment for in-house software, not shrink-wrap, here's the current list of questions that I use. Bear in mind that this list changes fairly quickly, as I come across new viewpoints and try out some new ideas.

Rule #1 for me: I'm committed to eliminating false positives, even if that occasionally means a false negative. The problem is that a wrong hire can really drag a software development team backwards and downwards.

Passion

What was the candidate's favourite software project ever, whether at work or at home? I want to feel some passion from the guy, see a ferocious glint in his eye, and hopefully hear some convincing communication.

Communication

Ask the candidate for a non-technical explanation about the benefits and drawbacks of a specific technology. For example:

• Explain the Internet to a young child.
• Teach your Mum how to use Excel.
• Explain a database to your grandparents.

A lot of in-house development involves talking to end-users, business analysts, project managers, senior management, and so on. This question is designed to probe the candidate's communication skills, traditionally a weak area for many developers.

Attitude I

What was the candidate's biggest development screw-up? What insight did she learn from that? I want to see some evidence that she can come up with at least one convincing insight into the software development process.

Attitude II

How does the candidate rate his skills with XXXX technology on a scale of 1 to 10? I want to see what scale he's using, and against whom he's measuring himself. Also, is he treating the technology in question as a homogenous blob, or does he divide it up into specific areas? This question tends to induce cognitive dissonance. He wants to rate himself highly, but he's wary of what nasty questions might come down the pipe if he does so.

Horizontal Understanding

I want a fairly hardcore discussion about an area that cuts across all software development, and that every good software developer should understand. Generally I take a subject from the following list, depending on the developer's skill set:

• Error/exception handling.
• Database locking.
• Implementation inheritance.
• Auditing.
• Multi-threading. 
• Assertions.  
• Database NULLs.
• User authentication. 

Vertical Understanding

I ask the candidate to explain what's wrong with a specific piece of code. There's just no escaping the fact that software developers have to understand huge streams of code that they haven't written, so it's very fair to test at least a small part of this comprehension process. I use various examples - one of them can be found here. Another can be found here.

Problem Solving

Another essential skill in software development is the ability to solve logical problems. By that, I don't mean any of those riddles or aha! questions that were all the rage a few years ago. I mean a specific logic problem that can be solved in a stepwise way, often by juggling the stated resources in a non-obvious manner. One of my favourite questions in this vein can be found here.

Design

My final question attempts to test the candidate's design abilities. I want to see that she has some design skills, and hopefully some design aesthetics as well. For example, I might ask her to draw an entity relationship diagram that models the database entities and relationships involved in role-based user access for an application. If she succeeds in creating a reasonable model, I add extra constraints (for example, a user can have multiple potentially conflicting application roles) to see how far she can go down the rabbit hole. 

Another design question would be to ask her to design a better user interface for an ATM. Or perhaps ask her to critique the interesting code design argument made in this article.

What I'm looking for with this type of design question is a sense that the candidate can go deeper than just a surface analysis.

I usually allocate about 5 minutes for each question. With 5-10 minutes' warm-up and 5-10 minutes at the end for the candidate to ask some questions, I can usually complete the whole interview in around an hour.