When we do coding at our interviews we do ping-pong pair programming. One of the things we want to see is if the person can deal with actually doing TDD. Usua

When we do coding at our interviews we do ping-pong pair programming. One of the things we want to see is if the person can deal with actually doing TDD. Usually there are 2 of us and one candidate. We explain the problem to the candidate and ask, "Do you want to write the first test, or shall we?". We've done the problem hundreds of times so we know a very, very simple first test that will lead forward. This allows the candidate to "warm up" a bit before they have to start thinking hard about the problem. Sometimes they hit the ground running and are keen to write the first test, which is also fine. The idea is that we switch back and forth. One of us writes a failing test, then the candidate writes the production code. The candidate then writes the next failing test and one of us writes the production code and the next failing test. If the candidate gets stuck, we usually try to talk through the situation and if they are really stuck, one of us will offer to take over. The candidate is allowed to look things up on the internet and even ask questions. Often we will suggest things. For instance, after the candidate writes some production code, we might say, "That works well. But how about refactoring it using inject," for example. I often use a pomodoro timer set to 20 minutes. We'll do as much as we can in the first set. After that first set we'll ask the candidate how they think it is going. We'll offer some advice about technique and such. If it was an absolute disaster (happened a couple of times), we'll just leave it there and thank the person for their time. Otherwise we'll ask if they are up for another round. Usually the first set is pretty bad because the person may never have done real TDD before, or may find the ping-pong awkward at first, or may be very nervous. Talking about how they are feeling at the break usually helps and the second set is much, much better. After the second set we'll ask the candidate how they think they did. I think this is important because if the candidate says, "It went really well" and it was actually awful, then we have a pretty good idea of their skill level. If they say, "I wasn't really happy with my performance, but I enjoyed the style of programming", then we will have to take into consideration a variety of different factors to see if we believe that the person can do better. If the person says, "I really didn't like working that way", then we can rule them out as a candidate regardless of their skill level (also happened a few times unfortunately). The feedback we've gotten from candidates on the process seems to indicate that they really enjoy this interview style. I think it removes a lot of the spotlight from the person and allows them to relax a bit. Especially having us come in and help out in sticky situations allows the candidate to get over stupid blind spots (like the converting between string and integer in the article). So far, I think it has helped us spot potential in a few people that I'm sure we would have overlooked using a more standard, "Here, solve this problem" approach. On the downside, there is still considerable room for improvement. Language lawyers (know every detail about the programming language but are still poor programmers) can often look very, very good in this kind of test. Similarly, inexperienced but very talented people can often be frustratingly mediocre because the unfamiliar method of development can hamper their style. You need to be very aware of the amount that the person improves during the interview. One final comment about this approach. We have occasionally been in a situation where we said, "I'm not sure how good this person is. They seem like their skills are fine, but whether they will be really excellent, I don't know. However, it was really fun programming with them." In those cases we have hired the person and never regretted it.