[deadcore]

Don't get me wrong I hate LeetCode-style interviews as much as the next guy. In fact I really, really, really suck at them! Not sure if that says more about my ability then anything but c'est la vie

In the defence of LeetCode-style questions, I do think they work, and very well may I add - with the caveat you have the throughput of candidate to make it work well? Their ability to filter out 'those who can't code' in an efficient manor while sacrificing a small amount where it filters out 'those who can code' greatly out weighs the alternatives. The alternatives needing to fit into a 1 hour timebox, be objective while also favouring the positive cases (I think I got that the right way round).

My two cents would be more around the way in which they are conducted; in my experience I've found conflict with the interviewer more then the process itself - with interviewers in my past lacking.... empathy (may not be the right word) for the person on the other end of the screen/table feeling flustered, nervous or down right stupid that they're struggling to solve a simple fizz-buzz/reverse string problem, leads to a snowball effect and pilling onto that can effect the candidate in quite a spectacular way. Best interviewer I've had asked if I was alright and got me a glass of water, props to that guy!

I dunno - I've just come to terms with having to learn how to play the game, even if I find that part of the game really hard and to some parts unfair. Such is life

[andrewingram]

There's an assumption you're making that these challenges only filter out a small amount of qualified candidates. I suspect the percentage is actually quite significant. In my experience it's usually bigger "looks good on a resume" companies that do these challenges, which suggests they're getting enough candidates in the funnel to be able to afford turning away a lot of more-than-qualified applicants.

I've failed more than my fair share of these challenges, but never (being subjective here) because I wasn't actually capable of (1) solving the problem or (2) doing the job. My take here is that I _may_ have been unqualified for these roles, but that the interview failed to actually uncover it, due to spending all the available time on low signal exercises.

[wiseowise]

> There's an assumption you're making that these challenges only filter out a small amount of qualified candidates. I suspect the percentage is actually quite significant.

Statistically that’s irrelevant, as they optimize for “do not let through rotten apple”, rather than “find good apple”.

[ep103]

Which is horseshit. I'm currently working at my first bigco company, and I would consider the MAJORITY of people they have hired in the last year to be horrifically bad hires, because they have optimized for new hires that can leetcode, but can't actually code.

We just fired a person on my team who didn't understand pass by value vs pass by reference, or how to debug in an ide, but she could manipulate strings in leetcode!

[nonameiguess]

That assumption isn't being made at all. That's why it says with sufficient throughput of candidates. If you need to hire 100 people, have 10,000 candidates, 1,000 of whom are qualified, and a 90% false negative rate, you'll get the 100 true positives you need, while leaving 900 well-qualified people pissed off. The process is bad for most of the candidates, but works fine for the company doing the hiring.

The problem comes when smaller companies that don't have the same high rate of new applicants use the same process and then complain they can't find anyone.

[andrewingram]

> "Their ability to filter out 'those who can't code' in an efficient manor while sacrificing a small amount"

This is the assumption I was referring to, that the "sacrifice" is small. It's suggesting that the false-negative rate for LeetCode challenges is small, and I'd argue it's actually quite high -- as you also suggest (your rate is 90%).

[wtetzner]

You might be right, but I don’t think that particular assumption being wrong necessarily matters.

[quickthrower2]

Big companies also have the headache of standardizing across thousands of interviews. That said you can do that more with practical exercises (build this thing…) than leetcode

[Kranar]

Any hiring process will necessarily filter out a large percentage of qualified candidates so it's not a major concern. If I'm hiring for X positions, and there are X + Y qualified candidates, then any hiring process whatsoever will necessarily have to filter out at a minimum Y candidates, and usually Y will be much much greater than X.

The problem is that the total number of candidates who apply for the position, Z, is significantly higher than X + Y by a very very large margin, and I mean orders and orders of magnitude. For every position I post I get on the order of 600-1000 applicants in a matter of a week, even though I'm only looking to hire maybe 2-3 people. Of those 1000 applicants, 80% of them are simply unqualified, and that's being really really generous just for the sake of argument (I'd wager the figure is closer to 90-95%). So once again just for the sake of argument that means 200 of them are qualified, and I'm hiring three, which means any process I choose whatsoever will filter out a minimum of 197 out of the 200 qualified people, no matter what I do.

Given that calculus, it's better for me to focus on making sure that I filter out the 800 people who are simply unqualified for the position even if that means I end up filtering some of the 200 good developers, because I have no choice but to filter out at least 197 of the good developers anyways no matter what, whereas I do have a choice about filtering out the 800 bad ones.

[valenterry]

If you think about the percentage of qualified candidates that don't pass the interview, you might even be not too far off.

But did you consider the number of qualified candidates that did not even apply because they know there will be leetcode questions?

[dormo]

I have had a great experience in a recent interview that used Byteboard. The format was two parts: First there was a design document in a Google Doc for a hypothetical system with three implementation options. All options were defendable, you just had to defend one in an essay-style answer. There were also various comments to respond to throughout the document.

The code part was a small existing codebase simulating the system in said design document. You you are given three tasks, and explicitly told you are not expected to complete all of them. I ended up using virtually all of the time (70 minutes) completing the first two tasks, and using my remaining minutes writing comments about how I'd complete the third task. When that was complete, I was given 15 minutes or so to describe what I would do if I was given another 15 minutes of time to work on the project.

My only real complains were that the time limit added some pressure (that I was able to manage reasonably) and that the grading process is opaque. I know a human grades it according to a rubric, but I don't see any of my results. The company I was interviewing for just said "Everything looks great, we're moving you forward to the next stage of the interview process".

The code didn't involve writing any fancy algorithms, but instead getting to know a (very small) existing codebase and understanding how to use it to add functionality. This is much more realistic a gauge of how good of an employee you are than how well you can implement a search algorithm from memory.