5 ms·

> Such test filter out the obvious frauds. I know everyone says that, but I really don't think that they do a good job filtering out shitty engineers. I have

by tombert 1mo ago

> Such test filter out the obvious frauds. I know everyone says that, but I really don't think that they do a good job filtering out shitty engineers. I have worked with plenty of incompetent people who managed to get past the leetcode challenge but are wholly unable to do anything useful involving software. I feel like what leetcode primarily tests is "does this person know how to use a hashmap in a way that you shouldn't actually use it because you lose cache locality", and that's literally all they test.

WalterBright 1mo ago
You might be surprised at how incompetent some engineers are. They get filtered out with the leetcode test. Of course, it doesn't filter them all out, and that's why there's a followup interview round.
- tombert 1mo ago
  I have given dozens of interviews at big companies and small companies and medium companies so I am not speaking out of my ass. These leetcode tests are not good filters, nothing is “surprising” me. Generally they are just wanky bullshit from some middle manager’s slightly-incorrect recollection of their first “data structures and algorithms” class, and the solution is almost invariably “use a hashmap” or “use a minheap”, even though the scope of these problems is usually so small that in a real implementation you would probably do in a more naive big-O-unfriendly fashion because constant factors are going to matter more. Let’s ignore the fact that most of the people who are designing these leetcode problems haven’t actually done any actual optimization and optimization is virtually never part of the job you’re interviewing for. I don’t know what the “correct” way to interview is, but I am fairly certain that the masturbatory leetcode problem is not correct.
  - marcus_holmes 1mo ago
    Agree 100%. The problem is that leetcode problems are nothing like the actual practice of writing commercial code. Writing good commercial code is about keeping things as simple as possible, as clean as possible, as readable as possible. Use libraries for the complex stuff, don't invent complex solutions. And, as you say, use standard data structures whenever possible. Don't optimise early. Don't fix performance bottlenecks unless you actually know they're causing a problem in production. And even then, throwing more hardware at the problem is often better than making the codebase more complex. None of this is anywhere near what leetcode tests. The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.
    - WalterBright 1mo ago
      > The best interview method I've seen is getting the candidate to work for a day or two alongside the team. That doesn't scale - what if you have 100 applicants? The leetcode will narrow down the field.
      - marcus_holmes 1mo ago
        Yeah, I've only seen it work for the last few applicants, but it did work really well. The "pick a bug and fix it" scales better, though still not to 100 applicants. Though I'd say putting 100 people through leetcode interviews would still break a talent acquisition process. I've been part of this kind of process before (though with arbitrary code problems not leetcode) and it was hell for the entire team going through it. Nothing got done for weeks while they were dragged into endless tech interviews.
  - WalterBright 1mo ago
    I haven't heard of any interview method that wasn't roundly condemned on HN. > the solution is almost invariably “use a hashmap” or “use a minheap” And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview
    - tombert 1mo ago
      > I haven't heard of any interview method that wasn't roundly condemned on HN. Sure, but none have been more thoroughly condemned (and correctly) than the idiotic leetcode whiteboard challenges. > And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview OR, and hear me out, you actively filter out people who know how stupid these problems are and know that big-O is misleading for a lot of these problems. You're selection-biasing towards people who are going to regurgitate bad answers, and the middle manager conducting the interviews is usually too incompetent to understand what a "constant factor" is. I've been rejected for jobs specifically because I mention that using a hashmap for these things will likely be slower than a naive implementation, even when the I get the problem "right" in the way that they wanted it. Now we could argue that I'm a bad candidate in general, but (at the risk of sounding cocky) I likely do understand data structures and algorithms better than most mediocre engineers conducting the interview, but because most engineers are pretty uninspired and have never asked "why" for anything in their lives, they will "correct" me. They will assume that me providing nuance is a lack of understanding on my end. > A quick check shows that Google, Microsoft, Nvidia, Meta, Apple, Anthropic all do leetcode testing. Yep, can confirm. I've worked at a FAANG, and they did indeed leetcode testing for the interview. It turns out that big corporations are fully capable of doing stupid things in perpetuity.
      - WalterBright 1mo ago
        I appreciate that, but my whole life I've heard again and again and again that "high stakes testing" does not work. I've heard all the arguments. But the bottom line is the testing is an effective filter. After all, would you get on a jetliner piloted by a handsome fellow with a firm handshake who failed to pass all the written tests, but really knows how to fly? It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career.
  - WalterBright 1mo ago
    [dead]

by tombert 1mo ago

WalterBright 1mo ago

You might be surprised at how incompetent some engineers are. They get filtered out with the leetcode test. Of course, it doesn't filter them all out, and that's why there's a followup interview round.

tombert 1mo ago
I have given dozens of interviews at big companies and small companies and medium companies so I am not speaking out of my ass. These leetcode tests are not good filters, nothing is “surprising” me. Generally they are just wanky bullshit from some middle manager’s slightly-incorrect recollection of their first “data structures and algorithms” class, and the solution is almost invariably “use a hashmap” or “use a minheap”, even though the scope of these problems is usually so small that in a real implementation you would probably do in a more naive big-O-unfriendly fashion because constant factors are going to matter more. Let’s ignore the fact that most of the people who are designing these leetcode problems haven’t actually done any actual optimization and optimization is virtually never part of the job you’re interviewing for. I don’t know what the “correct” way to interview is, but I am fairly certain that the masturbatory leetcode problem is not correct.
- marcus_holmes 1mo ago
  Agree 100%. The problem is that leetcode problems are nothing like the actual practice of writing commercial code. Writing good commercial code is about keeping things as simple as possible, as clean as possible, as readable as possible. Use libraries for the complex stuff, don't invent complex solutions. And, as you say, use standard data structures whenever possible. Don't optimise early. Don't fix performance bottlenecks unless you actually know they're causing a problem in production. And even then, throwing more hardware at the problem is often better than making the codebase more complex. None of this is anywhere near what leetcode tests. The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.
  - WalterBright 1mo ago
    > The best interview method I've seen is getting the candidate to work for a day or two alongside the team. That doesn't scale - what if you have 100 applicants? The leetcode will narrow down the field.
    - marcus_holmes 1mo ago
      Yeah, I've only seen it work for the last few applicants, but it did work really well. The "pick a bug and fix it" scales better, though still not to 100 applicants. Though I'd say putting 100 people through leetcode interviews would still break a talent acquisition process. I've been part of this kind of process before (though with arbitrary code problems not leetcode) and it was hell for the entire team going through it. Nothing got done for weeks while they were dragged into endless tech interviews.
- WalterBright 1mo ago
  I haven't heard of any interview method that wasn't roundly condemned on HN. > the solution is almost invariably “use a hashmap” or “use a minheap” And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview
  - tombert 1mo ago
    > I haven't heard of any interview method that wasn't roundly condemned on HN. Sure, but none have been more thoroughly condemned (and correctly) than the idiotic leetcode whiteboard challenges. > And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview OR, and hear me out, you actively filter out people who know how stupid these problems are and know that big-O is misleading for a lot of these problems. You're selection-biasing towards people who are going to regurgitate bad answers, and the middle manager conducting the interviews is usually too incompetent to understand what a "constant factor" is. I've been rejected for jobs specifically because I mention that using a hashmap for these things will likely be slower than a naive implementation, even when the I get the problem "right" in the way that they wanted it. Now we could argue that I'm a bad candidate in general, but (at the risk of sounding cocky) I likely do understand data structures and algorithms better than most mediocre engineers conducting the interview, but because most engineers are pretty uninspired and have never asked "why" for anything in their lives, they will "correct" me. They will assume that me providing nuance is a lack of understanding on my end. > A quick check shows that Google, Microsoft, Nvidia, Meta, Apple, Anthropic all do leetcode testing. Yep, can confirm. I've worked at a FAANG, and they did indeed leetcode testing for the interview. It turns out that big corporations are fully capable of doing stupid things in perpetuity.
    - WalterBright 1mo ago
      I appreciate that, but my whole life I've heard again and again and again that "high stakes testing" does not work. I've heard all the arguments. But the bottom line is the testing is an effective filter. After all, would you get on a jetliner piloted by a handsome fellow with a firm handshake who failed to pass all the written tests, but really knows how to fly? It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career.
- WalterBright 1mo ago
  [dead]