This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (17)
- # babashka (109)
- # beginners (212)
- # calva (1)
- # chlorine-clover (7)
- # cider (8)
- # clj-kondo (31)
- # cljsrn (2)
- # clojure (33)
- # clojure-dusseldorf (1)
- # clojure-finland (2)
- # clojure-france (22)
- # clojure-germany (1)
- # clojure-losangeles (1)
- # clojure-spec (6)
- # clojure-uk (19)
- # clojurescript (31)
- # conjure (41)
- # cryogen (1)
- # data-science (11)
- # datomic (6)
- # emacs (5)
- # exercism (8)
- # figwheel-main (2)
- # fulcro (57)
- # graalvm (15)
- # hoplon (15)
- # jobs-discuss (32)
- # kaocha (7)
- # off-topic (14)
- # pathom (2)
- # planck (9)
- # quil (1)
- # rum (5)
- # shadow-cljs (34)
- # spacemacs (33)
- # tools-deps (1)
- # xtdb (9)
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.
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.
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!
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 @U08ABGP70!).
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)
That comes out through the conversational interview based on the mind map I shared.
I've always been strongly against "technical tests" in the interview process -- but they're part of most companies' interviews and those same companies bemoan the fact that their interview process doesn't seem to work...
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.
@U0HJFE43U 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.
@U0HJFE43U I have the same reaction as you. You're not alone! I abhor them, and only ever experienced one okay session, at a company that worked very hard to remove any intimidating or unhelpful dynamics. Every other session I've done was horrible, primarily because the person interviewing seemed to have no empathy toward the inherent power dynamics.
Glad to hear it's not just me, @UKLH2NJ3W, although sorry to hear that you also suffer! It really feels like a debility.
even more conventional programming-on-a-whiteboard sorts of interviews are fraught. I've done many interviews where it feels like the candidate was failing to do themselves justice by a wide margin because the whole stressful situation was driving them to panic.
The status quo, as ever, favours the extroverts. I'm sure that my previous employers passed up many bright, capable and affable individuals in favour of those who had the gift of unshakeable self-confidence.
Our industry's interview process is horribly broken in so many ways. That is certainly one of those ways. It's why I avoid adversarial approaches in interviews (the whiteboard stuff, the "technical test", even sudden and enforced pair programming), in favor of much more conversational approaches.
It can be reasonable to have a "probation" period where you bring new recruits up to speed and see how they do in the context of real work with their teammates -- which is a much better way to evaluate this sort of stuff is going to work for them. Pay them, train them, but if it really isn't working out, have a cutoff date before they become full-time engineers on payroll. That is, if you must evaluate them post-hiring.
But my general position is: if you do the appropriate conversational interviews, you'll know whether you will be able to integrate them into your team and your workflow -- good candidates can always be taught/trained to follow new workflows, with new people.
(and if you can't figure that out from having conversations with candidates, you probably shouldn't be interviewing anyone in the first place!)
Quite so - thank you. On the isolated occasions when I've been in the position of making a hiring decision, I've already had a pretty good idea of whether or not the candidate fulfilled the technical requirements of the post or possessed the ability to acquire the skills in short order. The interview is mainly to confirm whether or not a) we can work with them and b) they will be happy working with us.