Clojurians Log v2

Does anyone here use "live coding" or pairing exercises as part of their interview process? If so, does it yield useful information? I freely admit that (as the person on the receiving end) I loathe them with a passion, invariably forgetting everything I once knew and getting hopelessly flustered. I'm interested to know what interviewers perceive the value to be, and whether it's more illuminating to put someone under pressure for 45 minutes than to examine something they took time to think about and get right.

I have found them useful as on several occasions, I've interviewed someone whose CV looks good but can't actually seem to program. It also gives you a sense of how they communicate and how they would be to work with.

I can see the communication angle, but do you feel it's a better indication of coding ability than the take-home test? Or do you discount those because of plagiarism/collaboration concerns? I'm probably too prejudiced against pairing tests, since I suck at doing them so utterly!

I wouldn't see it as an either/or thing, both give a useful signal

You would be amazed at how many people can mess up an apparently simple take-home test

I will do a mock pairing interview with you some time if you want, hit me up

Many thanks - I might take you up on that!😁 I recently applied to an employer who offered me the choice of pairing vs. take-home test, which I thought was a great approach (thanks @maleghast!).

We always keep reviewing the recruitment process where I work at (consultancy company) and the interview formats are one of them. I’ll describe our current process but it’s likely to change in the future. We do pair programming by default. Exceptionally when tasks are not really worth having more than one person, then we’ll be working alone. You’ll also likely to pair when designing any solution, be it when you are collaborating with one colleague or with the whole team. First step of recruitment process is super simple and you are supposed to complete the task at home on your own time. It’s meant to filter people out that can’t make the minimum for a simple exercise (it’s a fizzbuzz with a few tweaks). Then second part consist of a pair programming session with one of our devs. Again, the problem is relatively simple but it’s meant to take at least 1h30m. You’re not supposed to finish the exercise. It’s designed so that the interviewer can assess your skills not only in programming but also in communicating and dealing with different decisions possibly conflicting with previous ones. We provide the requirements partially to see how you react to (conflicting) changes. The final interview will consist on designing an architecture for a “product” with another dev and a “manager”. They will play the role of a PO. Both “live” interviews are meant to evaluate your experiencing in architecting and implementing solutions, dealing directly with clients. We look for things ranging from software engineering, communication to teamwork skills hence this whole process. Sorry for the long description but I couldn’t leave anything out. I hope it’s helpful for you.

Very helpful - thank you for the detailed description! I can fully understand the emphasis on communication and collaboration, both of which I regard as essential parts of the job - not only for pragmatic work-related reasons, but for my own personal happiness. However, I find the interview-time simulation of pairing to be essentially dissimilar to its "real-life" counterpart, and hugely stressful. Under those conditions, I never give of my best, and fear that interviewers come away with the irrevocable impression that I'm barely able to code! I feel it's an imperfect solution to finding the right person, but I quite understand that the ideal "one size fits all" approach does not exist.

We understand that kind of reaction. We try to make people as comfortable as possible at the beginning of the interview and we notice people are sometimes quite nervous. Ice breakers are good for that. What happened in the past (more than once) is that we repeated the interview if we find it wasn’t fair due to stressful conditions. Candidates have reached out to us, we have interviewed them again and they were hired. We know that it requires a lot of energy from people but we can’t afford having someone that 1) doesn’t have experience or potential to evolve, 2) can’t communicate clearly, and 3) can’t have an egoless approach to solving problems together with other people. We are looking for “normal” people, not ninjas or superstars. We expect you to make mistakes but we want to make sure you react well and change your course of action once you identify them.

Makes sense, and I like the "second chance" option.

If your company does pair programming "a lot" and it's the typical way your developers are expected to work most of the time, then I'd say it's fair to do a pair programming exercise as part of the interview process.

But if you're using it just as an interview technique to evaluate people -- and you don't pair program much (or at all) then I'd say it's not a useful yardstick.

(and I've already been very clear that I don't think take home exercises are a good measure, for all sorts of reasons)

Thanks Sean - I agree that take-home tests are imperfect, yet I'm not sure that pairing exercises are better. They generally seem to be a poor facsimile of the genuine article, but I recognise that my attitude is coloured by my own visceral fear of them. They precipitate a degree of panic that I can't adequately explain, and I have yet to come out of one thinking "that went OK"! However, mine seems to be an atypical response and in fairness I must concede that the problem lies with me.

@rhinocratic I've never encountered a pairing interview. I don't know how I'd react. I've paired some but not a lot. The front end folks where I work pair quite a lot.

I can imagine it being hard to set up a pairing interview that is really like pairing in the real world within that company.