One of the big unspoken reasons these questions stick around: they cause little imposter syndrome anxiety for the senior engineers who need to conduct the interview. You ask a candidate to code a toy problem, and the candidate either knows the "trick" to solving it quickly or they don't -- very little risk for you as the interviewer, you're just watching things play out.
But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.
And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.
>And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic
I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could conduct studies on this; on the other hand individuals at smaller companies might honestly remember only those times their hires filtered through this method were successful, due to confirmation bias. So it seems like an inherently difficult thing to study.
Whereas, algorithm questions lend themselves easily to a "rubric" and seeing, 1 or 2 years later, if higher "grades" corresponded to better job performance.
There are studies out there [1] from assessment providers
The problem is any one spending time on this question also has a vested interest in the answer.
FWIW my experience in hiring for my org and in the talent acquisition tech also reflects this . (Not related to the company in the link)
The reason usually this method is not as popular while the efficacy is understood is because it very hard to scale and do inconsistent evaluations and also takes a lot more time per candidate
Even for the biggest companies the analysis is only going to be as good as the internal performance measuring system and how can a company gain confidence that is working?
There was a long discussion in the GCP thread yesterday about what google has been hiring and promoting for over the last ten years and what culture that produced. Any look-back at hiring methodology vs success at google is going to embed that implicit strategy. Among other things that means another company should very much not extrapolate from Google’s experience—-even if it is based on solid data analysis—-unless they are trying to replicate that culture.
can you link to that thread? Does it dig into how a focus on rote memorization of leetcode, has made a subtle influence in how the interface/systems are designed?
But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.
And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.