It's a late reply, but sure. The purpose of pairing in this context is not to see a meaningful contribution; rather, it's to see how the candidate interacts wi

It's a late reply, but sure. The purpose of pairing in this context is not to see a meaningful contribution; rather, it's to see how the candidate interacts with a codebase he's never seen before, and developers he's never worked with before. Can they spot mistakes? Recognize patterns? Read and write code? Does the candidate know the ecosystem well enough to suggest methods or libraries? Most importantly, pairing tells us whether or not the candidate can communicate effectively. Are they terrified to offer suggestions, or overly arrogant and controlling? Can they explain clearly? Do they clarify when the other half of the pair doesn't understand? For example, many moons ago, I did some pairing with a candidate that gave me a suggestion on how I could make a section of my code both smaller and easier to read by combining a couple of iterators in an obvious way that I hadn't noticed. We ended up hiring that guy. The getting-up-to-speed part happens as they pair, with a lot of explanation happening as they work on the system, and it's another important part of seeing how they work -- can the candidate understand new concepts quickly? Do they stop and ask questions when they don't understand? This type of interview is a performance hit for that employee for the day, but this is fine, as I consider hiring to be very important, and losing a day or two of engineering time over the course of a month is a price I'm willing to pay -- keep in mind that the phone screens eliminate a lot of people. Admittedly, I've never had a day when my guys didn't have work to do, but not all interviews involved the company codebase. I make it a point to carve space out for my team to do miniature research projects, in a fashion similar to the way HP used to work, or Google's "20% time". These are timeboxed, and at the end, the result needs to be made available to the team; and yes, "this didn't work because of X and Y" is totally acceptable. This always pays off in terms of education, and every now and then you get something useful out of them, but they're also fair game for pairing during programming interviews. Hopefully I've answered your questions.