I think this interview gets a bad rap on HN. Much like the post author, I’ve given hundreds of coding interviews to candidates and taken many of them myself, sometimes passing and sometimes failing.
My takeaway is that if the goal of the coding interview is to “identify people who can code”, then this approach has high precision and poor recall.
In other words, most of the people who pass the interview actually can code (at a basic level—I’m not talking about high-level system design skills here). Very few people slip through this interview who cannot code. However, because of the poor recall, there are many people who actually code very well that the interview misses (a fact widely derided on here).
From the perspective of a big tech company, this situation is perfectly fine. There are so many candidates interviewing for any given role that accidentally rejecting a few exceptional candidates is quite an acceptable trade-off in order to prevent a bad hire. Most of the people who cannot code and are aware of their inability to code, yet still knowingly apply for a position that requires the ability to code tend to be BSer types that attempt to make their way into management positions as quickly as possible (and there are many of these people targeting big tech companies). It’s not that their inability to code hurts the company—it’s that they would prefer not to code at all and go straight to the politicking. The coding interview is simply a nuisance obstacle in the way of this objective. These types will often state that they refuse to interview at any company that requires a coding interview, though I admit there are still many BSers who are skilled enough to pick up some coding ability for just long enough to pass the interview.
At a small tech company or at a company that’s not a “brand name”, this approach obviously doesn’t work as well, because these companies don’t have nearly the onslaught of BSers applying to their open SWE positions. In this case, it might make sense to forgo the coding interview in favor of other approaches.
I like the coding interview because despite its flaws, it actually assesses some technical ability, even if it does so with low recall. This is very much unlike the behavioral interviews, which I think are mostly nonsense and are prime opportunities for BSers or mercenaries to slip into a company. In my experience, the behavioral interviews tend to disproportionally filter out people from unusual or underrepresented backgrounds that aren’t the right “cultural fit”. The language and terminology used in the interview, the conversational style and mannerisms, and the topics discussed all typically provide much more signal into the candidate’s position in the class hierarchy than how that person would do at the job. People like to think they can assess someone well by having a brief 1 hour conversation with them, but I just haven’t found that to be the case, because there are too many perverse incentives and biases involved.
My takeaway is that if the goal of the coding interview is to “identify people who can code”, then this approach has high precision and poor recall.
In other words, most of the people who pass the interview actually can code (at a basic level—I’m not talking about high-level system design skills here). Very few people slip through this interview who cannot code. However, because of the poor recall, there are many people who actually code very well that the interview misses (a fact widely derided on here).
From the perspective of a big tech company, this situation is perfectly fine. There are so many candidates interviewing for any given role that accidentally rejecting a few exceptional candidates is quite an acceptable trade-off in order to prevent a bad hire. Most of the people who cannot code and are aware of their inability to code, yet still knowingly apply for a position that requires the ability to code tend to be BSer types that attempt to make their way into management positions as quickly as possible (and there are many of these people targeting big tech companies). It’s not that their inability to code hurts the company—it’s that they would prefer not to code at all and go straight to the politicking. The coding interview is simply a nuisance obstacle in the way of this objective. These types will often state that they refuse to interview at any company that requires a coding interview, though I admit there are still many BSers who are skilled enough to pick up some coding ability for just long enough to pass the interview.
At a small tech company or at a company that’s not a “brand name”, this approach obviously doesn’t work as well, because these companies don’t have nearly the onslaught of BSers applying to their open SWE positions. In this case, it might make sense to forgo the coding interview in favor of other approaches.
I like the coding interview because despite its flaws, it actually assesses some technical ability, even if it does so with low recall. This is very much unlike the behavioral interviews, which I think are mostly nonsense and are prime opportunities for BSers or mercenaries to slip into a company. In my experience, the behavioral interviews tend to disproportionally filter out people from unusual or underrepresented backgrounds that aren’t the right “cultural fit”. The language and terminology used in the interview, the conversational style and mannerisms, and the topics discussed all typically provide much more signal into the candidate’s position in the class hierarchy than how that person would do at the job. People like to think they can assess someone well by having a brief 1 hour conversation with them, but I just haven’t found that to be the case, because there are too many perverse incentives and biases involved.