Ivan Moore wrote an article a while back on how he runs pair programming interviews. After introducing them to the recruitment process at my company I have to agree with Ivan that they’re incredibly valuable – among other things they’re a great way for a potential employee to show they have a developer conscience. I wanted to share some of our learnings too.

Real Code

We use real code and real problems we’ve already had to solve. I know others like to use programming exercises, but we like to see how candidates deal with problems which are more relevant to the job they’re applying for such as dealing with legacy code and unit testing.

Code Review

We start by walking the candidate through the code and it’s context, give them 10 minutes to review the code by themselves and then discuss their thoughts. Outside of the actual pairing exercise this is a great opportunity for them to show us how well they understand OO principles and practices by identifying any code smells. We’re also looking out for how well they explain their answers as an ability to communicate well is essential.

The Exercise

Next we roll up our sleeves and start programming. We set the candidate a challenge (in the same code base), work with them as much as possible without making it too easy, explain anything they’re unclear of and help them with any tools they’re not familiar with. Whenever we come to a tricky or challenging situation we ask them what options we have. If they’re totally stuck we will suggest possible solutions, but ultimately they’re the one making the decisions. The exercise continues until the allotted time runs out (1 hour normally).

It’s about what you do not how you do it

We explain to the candidate at the beginning of the interview that there is no finishing line. What we’re looking for most is how they approach a problem and how well they work with others. Often people who get the furthest do so by making risky refactorings and poor design decisions.

Pair pair programming

It’s always good to have more than one opinion so generally there will be two people in the interview aside from the candidate. One takes part in the exercise whilst the other acts as an observer. This allows the navigator to focus on the exercise. After the interview we get together and discuss our thoughts. Often one of us will have forgotten or not noticed something from the interview and this ensures we get the most balanced and fair view possible.

Does it work?

So far everyone who we’ve recruited who has taken part in the pairing exercise has lived up to, if not excelled our expectations of them based on how they performed. One drawback is although we do try to keep the interview as relaxed as possible it can be quite intimidating for some, however having done quite a few now I cannot imagine recruiting a developer without using this technique as part of the interview process.