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.
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.
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.
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.
This is something I have been saying to my clients for a while.
I don’t advised real code though. I know about one company that was sued because the person said I did production code, so you actually hired me.
Having two people next to the candidate puts a lot of stress on the person.
Don’t forget that doing an interview is already a stressy situation.
One risk I see is that you might end up hiring people that are a lot similar. It is always good to go for diversity, you also need people who might be less good at coding but good at softskills, debugging something etc.
What if you would make them talk at your standup?
We really do do our best to make the atmosphere relaxed – we’re certainly not attempting to create an environment to see how people work under pressure. Candidates who do find the situation a bit stressful at first mostly tend to calm down quite quickly once they’re involved in the problem.
People who find the exercise most stressful are those not prepared to admit they are stuck, which is not a good characteristic.
We find that being able to discuss the candidate with a colleague who may see things differently to you is worth the sacrifice of having two of us in the interview.