Can interview pairing work? How?

I’ve paired with a pretty decent handful of people, now — enough to know what it feels like to be grooving a little bit, coming up with ideas together, bouncing creativity and stupidity off one another until something lovely (or “good enough”) emerges. It’s delicious. It’s maybe exactly what humans are for. That’s how it seems to me. I’m not going to water it down; I really think it’s amazing and wonderful.

And then there’s this thing called “interview pairing.” Yes, I realize I just put out a flag saying I wanted to be hired, but dang it, this isn’t about bad hiring experiences. — I think I’ve “done fine” in those situations, and I’m ok with me regardless. I am what I am. — But this is about my love for pairing, people, and creativity. I just have to say it: I smell a rat.

Pairing is a delicious synergy, where two people are working together to build something. They keep each other focused, add bits of brilliance to the midst once in a while, and they catch one another’s stupid stuff with good humor. After a particularly stupid moment, one says “And this is why we pair!” and everybody is happy. Or that’s the hope.

To do that takes two people giving what they’ve got, welcoming one another’s ideas, welcoming one another’s mistakes, and both thinking about how to solve the problem.

If one person is evaluating the other, looking for problems, how is she going to be a good pair? If the other is scared, or just feeling the pressure of being constantly evaluated, how will he be brilliant, energized, creative? How will you find out what kind of pair someone is if you approach pairing this way?

My guess is that it’s possible to either observe from the sidelines while someone pairs (preferably, for fun) with another developer, or to be particularly mindful while pairing with someone you’re also evaluating, so that it’s fun and creative, saving your evaluation for after the fact. (Ideally, a nice, blame-free retrospective that you do together?) But I’ve definitely seen evaluative pairing look icky, and friends have told me about similar experiences.

(This reminds me that one key to making the workplace open and creative is to encourage everybody to remember that we’re all doing this voluntarily. That is, a pairing interviewee can remind herself that we are checking each other out, looking for a match. Neither party holds all the power.)

Question for the smart people: Have you noticed this issue? Figured out a way around it? Or maybe you think people being evaluated should just buck up and deal? ^__^ Seriously… how does evaluative pairing look in your workspaces?

GeePaw sez…

Interview-pairing is not pairing. It *would* probably help identify someone who claimed to have paired but actually never had.

Other than that, I’m not buying.

Does it predict success or failure at real-world pairing? Well, maybe, but only way out in the long tails. That is, only the very best and worst will do anything other than the range from “not bad” to “reasonably good”.

Does it predict raw coding talent? Not so much. Greenfield problems that take a couple of hours to solve, in a domain you don’t live in, are not terribly representative of the work of real coding.

Is it a good way to see if someone fits the team? Hmmm. I guess it’s not any better or worse than all the other possible ways to test that in a couple of hours.

Real-world pairing success is just too complicated, depending as it does on factors like these: which problem we’re solving, how much domain knowledge we have, whether the partner is confident or timid, the nationality of the pair, the time of day, the status of the car payment, the layout of the keyboard, the difference in the chairs, physical health, individual styles, and on and on.

6 thoughts on “Can interview pairing work? How?

  1. Pingback: Can interview pairing work? How?

  2. Dan Wiebe

    I’ve conducted several dozen pairing interviews, and based on my experience I can tell you that while in theory you have a good point, in practice it doesn’t come up.

    The people I’ve paired with fall readily into two groups.

    One group contains the folks who have lied about their abilities, and have their lies miserably exposed by the experience. These interviews are painful and can never approach the level of flow achieved by a good pairing session. (One “senior Agile Java developer” I interviewed spent a good, solid seven minutes trying to figure out how to modify production code to make the assertion assertEquals(2, null); succeed.)

    The other group consists of people who are honest about what they know and don’t know. In general, pairing with these folks is enough fun that the whole evaluative thing kind of gets lost in the background.

    Maybe once Agile is common enough that you can depend on interviewees to have pairing experience we’ll need to make the allowances you suggest.

  3. June Kim

    In the scene you describe, the evaluator might be evaluating the candidate’s stress coping ability. It might dominate all other factors.

    While I acknowledge that ability is a good thing to have, yet it is a just small part of what the recruiter must be looking for in the candidate.

    For this reason I lead pair programming session with the interviewee at a later stage in the hiring process. It should be after we learn something about each other, their style, preference in communication, building some trust and rapport and etc.

    So, for instance, the process might be something like paper, phone, one-to-one, audition(we can even make gradual progress into pair programming in this stage, too), group work and so on.

    Most of all, I keep in my mind this question while interviewing any person : how can I bring up the interviewee’s potential strengths(even something herself wouldn’t be aware of) on to the table?

    A good tip for better pair programming session : record the screen of pair programming and do the retrospectives with the interviewee watching the video(the interviewer could do it alone as well).

    Once in my early career as a hiring process consultant, one interviewee confessed to me after having gone through a few stages : “whether I get the job or not, I can wholeheartedly say this has been the best interview process I ever had in my life. I learned a lot about myself. Thank you” That was really touching.

    So I try to remember that moment while interviewing and try to make it their best interview experience and learn something new.

  4. Dave Nicolette

    My experience corresponds with Dan Wiebe’s. Unfortunately a lot of people claim to have experience with certain techniques, and then when you ask them to demonstrate the technique they are at a loss. It happens very frequently with claims of experience in TDD and/or pairing. It would be simpler if they just said they’ve heard of the technique and are interested in it, but they are not experts. I would sooner hire someone who did that than someone who claimed expertise and then fell apart during the audition phase.

    I might add: The sort of person who thrives in a collaborative environment such as a team room and who enjoys pairing will not feel scared or under pressure when pairing with someone new. It’s just the same activity they normally engage in. The sort of person we’re (probably) looking for already participates in events where he/she pairs with strangers on unfamiliar problems or katas using unfamiliar languages and testing tools, like coding dojos and code retreats. The right sort of person will feel delighted and (perhaps) surprised to find such a great environment; quite the opposite of stressed-out and scared.

    Furthermore, the “interviewer” is assessing the person’s pairing interaction style. How else are you going to get to that? Surely not just by talking. Typically we will have more than one team member with whom the candidate would be working in “real life” pair with him/her during the “interview” (audition). We want to be sure everyone is compatible. It’s as much for the candidate’s benefit as for the team’s.

  5. Angela Post author

    I guess what I’ve learned from this, and from life since I wrote this question, is that not all pairing interviews are alike. When the interviewer is fully engaged, contributing as a pair does, it can be a beautiful thing, and can create the kind of environment that allows information to come out.

    Maybe it’s when the interviewer is putting so energy toward evaluating that they’re not able to cooperate and experience paired geek joy, that’s when it doesn’t work so well. We all know that programming with someone looking over your shoulder is not pairing, right?

    I know that the pairing interviews I’ve had were so much fun that I didn’t realize they were interviews until later. Some geeks have told me about pairing interviews that were painful, uncollaborative, and stilted, but it seems like that’s far from the norm, and I’m glad. :)


Leave a Reply to Dan Wiebe Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>