I mean, it's strictly better than the typical code interview, which is timed too. And the reality today is that the majority of people have to be able to deal with a ~45min code interview to find employment in software.
My first 3 or 4 tech jobs started with interviews like this, which seemed to work fine. Then everyone fell in love with coding questions. It's funny to think some hiring managers might be going back to interviewing like every other job.
Anytime there's a blog post or a thread complaining about the 'broken coding interview process' it ends up being upvoted by everyone and their brother on HN but very rarely have I seen people offer a reasonable alternative instead.
I work for a big tech company and for our org, typically we have a couple of Algorithms/Coding rounds, a system design round, a technical communication round and a loosely structured interview/chat with a hiring manager. I think this works because people, at least on my teams, have to work on a wide array of features that could involve writing backend queues, or Hadoop jobs or some business logic on the API layer that would need to leverage caches/DBs/other appropriate key-value stores. It definitely does help to have people who have broader knowledge of Computer Science to be working on those features.
I feel our interviews have low recall and precision but a good accuracy (we end up hiring smart people we can count on to pick new things up). And FWIW I don't think we ask unreasonable questions during the coding rounds. I also feel it's a reasonably scalable way to organize a generic 'objective' and 'fair to all' interviewing process at a big company that can hold a reasonable hiring bar.
If I was running a smaller company then I probably would have kept in place a process that was closer to the bare practical requirements of the job.
Also, if the existing interview process was really that bad in practice with an abysmal correlation with successful hiring, wouldn't the companies have dropped it already?
I know this kind of sucks for applicants who think they have all the skills that are needed to practically do the things they'd have to do at the job they're interviewing for (and in some cases rightly so), but arguments bashing the current interview process would seem more valuable with the proposal for a better alternative that can comes off as reasonable after the same amount of critique and scrutiny that the current process gets.
Also, I often get confused - do people not agree that there's any correlation with hiring good engineers and the current process, or do they just think companies should have a more developer-friendly interview process? If it's the latter, then do the companies have any incentive to do so? It can't be that 'their potential hiring pool becomes wider' because if that really was such a big problem they would have changed already.
(All opinions mentioned here are mine and none are my employer's, obviously)
(Edited comment twice to attempt to make thoughts more coherent)
I disagree with this. Coding interviews are great. The interviewer needs to realise though that they're not there to be an adversary or a judge, but to help the candidate demonstrate their skills, to help the candidate get the job.
Before we criticize the current interview format and propose alternatives, we need to understand how we got here first. This is my understanding of what happened (I wasn't there for most of this!).
Leetcode-style interviews became popular in the mid 00s, primarily because they were used by hot tech companies of the time. The thing to understand is that at that time, the idea of asking people to write code during an interview what sort of revolutionary. Prior to that interviews had little structure. It wasn't unusual for the hiring manager to make the decision, some times based on credentials, recommendations, or trivial-like questions.
This type of interview became wildly popular because it allowed budding unicorns to hire programmers of high quality at scale. The process was less biased than the alternative, reproducible and scalable. Here you have two blog posts [1][2] that show the line of thought at the time.
The reality is that big tech has elevated leetcode type interview to an art. They have reached a near local optimal through years of experiments and refinements. It is working well for them so they don't have the need to take big risks such as completely revamping their hiring process.
I love the topic of hiring and interviewing and I'd love to truly get at the bottom of which method works best. I like this article because it explicitly calls out shortcomings with typical alternatives that are not usually mentioned. I hope in the future a new crop of unicorns can take these practices to the next level and do a fair comparison.
Depressingly, the difference between then and now is today's blog post would be advice for how to ace your 3 part interview, each with a 1 hour coding test and the take home project for which you are expected to sign an NDA
Our position on this has always been that if a candidate finishes our sample coding task, they are automatically granted a tech interview. It's the least you can do for someone who put in the time toward your position.
In my very recent experience (specifically in the UK for roles to do with Ruby), the shirtage of developers mean it's way less painful than it used to be, cos companies are marketing themselves on their ease of interview process. I went from sending out CVs to getting a good offer in a week, and that offer was from a 1-stage, 1-hour interview process. Don't get me wrong, I basically spent that entire week on the phone to recruiters, but still, massive improvement on the last time I was in the market.
That sounds nice! It definitely seems like a better process than 5 interviews of coding + system design and a half assed behavioral thrown in, which is what I'm used to.
Is there data on the efficacy of non traditional coding interviews vs traditional ones?
I'm all for improving the process, but as someone who at times has struggled on a coding interview, I believe that the onus to improve should be on me the candidate.
That's exactly why it pays to prepare for coding interviews. If companies are not going to be thoughtful about interviewing, candidates can either reject those companies, or prepare for those interviews. My belief is that if more candidates are professionally prepared with those closed-ended questions, this will eventually force companies to be more thoughtful.
reply