Successful pair programming interviews

We've introduced pair programming as part of our interview process at REA a while ago. In general I think its been quite a success. Its a great way to get a perspective on a candidate that you otherwise won't get. You see a bit of how they work first hand, instead of trying to infer it from a conversation.

The following is a list of things that I find helpful to get the most out of a pair programming interview.

Work on familiar code
During the pair programming interview we work on the candidate's code that they have submitted prior to the face to face interview. The task is to implement a couple of additional requirements in their code. Its a much more realistic scenario and you can jump right into it as the candidate is familiar with the code.

Have the environment ready
Setup a workstation beforehand with their code open in a simple IDE. I find Sublime Text works well for this (btw. this is not your chance to convert someone to VI). Also, make sure their code is running on the workstation, you do not want to waste time with, for example, installing a particular version of Ruby.

I did this because ...
Before even looking at the additional requirements I ask candidates to talk me through their submitted code. It gives them a chance to reacquaint themselves with the code and it gives you a glimpse into their ability to explain their own work. Its a great chance to ask them why they have decided on certain implementation details.

Written requirements
Have the additional requirements in a written format. You might think it is simple enough to explain it verbally but its because you came up with it. Also, I find it helpful to read it out loud to them while they follow on paper. Keep in mind, this person is probably quite nervous, make it easy for them to comprehend what you are asking them to do.

It is an open book test
I sometimes interview candidates that are new to Ruby, I do not expect them to know the language API. I make it clear that they can use the internet if they get stuck. I have had some great insights into candidates' behaviour when they know a certain method should exist but not sure what the method name is.

The aim is not to finish
I make it very clear that the point is not to finish, we never do. Its obviously a good indicator to see how far they get but you are looking for much more than that and if finishing is the main objective you'll be missing a lot of valuable observations along the way.

Help them to be their best
Its in your best interest to see the candidate perform at their best, you want to see their potential. This means that sometimes you need to let them battle with a problem when they get stuck and other times you need to guide them to allow them to move on. You'll become a better judge of this the more you interview.

Fly against the wall
We find it helpful when a third person sits in to observe. They tend to pick up on things that you might miss. However, it is important for the observer to observe and not to get involved in the pairing, too many cooks spoil the broth ...

Debrief
Allow a few minutes at the end to debrief. Discuss what they would've done next (assuming you did not complete all the requirements), if it was it easy or hard, would they have done anything differently, etc.