This is the third article I’ve written on the ThoughtWorks recruitment process (for developers) and today I’m discussing what happens after a coding problem has been reviewed and both TW and candidate are keen to proceed: the pairing interview.
Ironically, there are normally three people in our pairing interviews; the candidate, a TW developer who will be a pair for the candidate, and a second TWer lurking ominously in the corner taking notes. Why the 3rd person, I hear you ask – because it makes it easier to take notes and give feedback from a person external to the pair.
Hint #1. The purpose of the pairing interview is to see how the candidate “performs” as part of a pair. Even though the pair is working on refining/extending the candidate’s original code submission, this code is primarily there to provide a context for the development. In some cases, the code reviewers will recommend the pairing interview to look at particular parts of the original submission, but from a recruitment perspective, the code submission was of sufficient standard to continue the recruitment process. Winning!
Hint #2. Pairing is hard, even for experienced hands. The interaction between driver and navigator is subtle and easy to get wrong. We ask candidate’s if they’ve paired before and take that into consideration because it can be an extremely stressful situation for people who have only ever coded solo. As stated before, we hire for potential and this interview is no different. We need to make an assessment about not only “how did the candidate pair?” but most importantly “how could the candidate pair given time and a less artificial situation?”. Ultimately, the question we’re trying to answer is: would I be happy coding with this person for an extended period of time on client site?
Hint #3. Pairing is a social activity. Many of the things I look for as an interviewer are how the social interaction between the driver and navigator is going, specifically:
– Does the driver want to drive? Occasionally, we meet developers who are stunned by the idea of coding in front of others and have to be coerced to take the keyboard. This is not normally a good start.
– Does the driver (the candidate for the majority of these interviews) think out loud? This is the key skill on both sides of a pair. Self-filtering before talking is not necessarily a good thing.
– How well do they respond to feedback on their submission? Are they too defensive? Are they too submissive? Extremes on either end of this spectrum can be damaging to pair effectiveness.
– What assumptions do they make about the navigator’s familiarity with their code? Are these assumptions stated? Our interviewers are going to have a good knowledge of the problem, but may not have spent much time with the candidate’s specific solution. The interviewers are never the same people who reviewed the submission originally.
– Do they ensure their pair is on board with the work being done? Do they check that they understand what is happening? We’re looking for people who have sufficient EQ to recognise when they are leaving their pair behind and correct accordingly.
– If their pair is obviously junior in terms of experience, how do they deal with that? Likewise for an obviously more experienced pair. A good pair will treat their partner as an equal contributor to the task at hand.
Hint #4. Although the social interaction is important, don’t completely forget the code. I’ll go out of my way to tell the candidate that completing the suggested extensions by the end of the interview time is not that important, but there are still some productivity signs that I look for when navigating or observing one of these interviews:
– How well do they understand their own code? (especially given the ready availability of solutions in the public domain)
– How comfortable are they in the development environment? Candidates use their own laptops, so I should be seeing signs of plenty of years at the keyboard in terms of some degree of mastery over their keyboard, IDE shortcuts, etc.
Hint #5. Interest, passion and enjoyment trump capability every time. We look to hire developers who are deeply, madly in love with the notion of writing code and we want to see signs of this when we spend time with you during recruitment. Because this interview has the advantage of using the code as the focus, the best pairing interviews I’ve been involved with have been a really enjoyable meeting of minds between developers madly hacking away at numerous variations on parts of the original submission. Note that passion doesn’t need to manifest in Jim Carrey style extroversion, but it should be obvious in terms of the speed or volume of the candidate’s speech and the language they use.
After a successful pair programming session, the next step on the journey for candidate and TW alike is a higher-level technical interview. Up next!