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.

At SPA2010 last week Matt Wynne organised a BoF session around how we can change the way the UK government delivers software. We had a really constructive discussion and lots of actions came out of it, one of them being to set up a group for people who are interested in getting involved to effectively communicate and bring together our collective knowledge and abilities, create a bit of a movement.

If you are interested in actively getting involved (rather than just commenting from the sidelines) please sign up:

http://groups.google.com/group/uk-soft-pract-esd

In a few days I will publish the actions we identified from the discussion and we will be looking for people eager to take on some of the tasks.

P.S. Don’t worry about the name if you don’t like it. It is likely to change and not the most important thing to be discussing at these early stages.

I’ve now been to Keith Braithwaite’s TDD as if you meant it session twice and also ran a series of coding katas in this style at work using Conway’s Game of Life.

Here’s the concept:

1) write exactly ONE failing test
2) make the test from (1) pass by first writing implementation code IN THE TEST
3) create a new implementation method/function by:
3.1) doing extract method on implementation code created as per (2), or
3.2) moving implementation code as per (2) into an existing implementation method
4) only ever create new methods IN THE TEST CLASS
5) only ever create implementation classes to provide a destination for extracting a method created as per (4).
6) populate implementation classes by doing move method from a test class into them
7) refactor as required
8 ) go to (1)

What I’ve learnt

• It’s really hard to get going.
• At first it feels ridiculous and pointless effectively testing things like true == false and having the code under test actually in the fixture.
• A recurring theme has been throwing away lots of code. Focusing on trying to do the simplest possible thing often means your understanding and your solution frequently changes and continuously becomes redundant. It’s a very frustrating experience.
• I don’t think it’s at all a practical way to write production code.

If I’m not going to use it what’s the point?

As Keith has repeatedly stated, he would not recommend you went back to your job and started coding this way. What it is though is an excellent training exercise, the equivalent of a musician practicing scales. It emphasises the core principles of TDD more than anything else I’ve tried or read.

Therefore I’d highly recommend it as something to do on a relatively regular basis to help refresh your TDD muscle memory and it’s a great way to introduce the concepts of TDD to the uninitiated.

As Queen Elizabeth II once said, “It’s all to do with the training: you can do a lot if you’re properly trained.”

The election may have put the breaks on the petition, but significant progress has been made on other fronts. In parallel to the petition I set up to demand the government review it’s outdated IT practices, Robert Chatley (with the help of a few others) wrote a letter* to the National Audit Office asking them to update their guidance and recommendations for systems development. After a couple of prods they agreed to a meeting and last week Robert Chatley and I went to see them.

To cut a long story short (I’m supposed to be packing for my hols so have to be brief) it was a very positive meeting. We met with their Director of IT and Systems Analysis, Sally Howes and her colleague Leena Mathews. Both, but especially Sally were very receptive to what we had to say. Fortuitously they are in the embryonic stages of a wide reaching review of government IT practices so this looks like a fantastic opportunity to make a real difference.

One thing they’re particularly keen on hearing about is large organisations who are using and succeeding with agile practices and specifically senior people within those organisations who they could talk to. If you know of or are working for such an organisation please email me at  with the details of people who may be appropriate for them to talk to.

*You can read a draft of the original letter to the NAO here