4 ms·

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

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 4y ago
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.
- quickthrower2 4y ago
  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
- wiseowise 4y ago
  > 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 4y ago
    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 4y ago
  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 4y ago
    > "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%).
valenterry 4y ago
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 4y ago
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.

andrewingram 4y ago

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.

quickthrower2 4y ago
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
wiseowise 4y ago
> 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 4y ago
  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 4y ago
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 4y ago
  > "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%).

valenterry 4y ago

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 4y ago

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.