[pxeger1]

> interviews should: be applicable. reflect the actual job duties

No, it doesn't matter that much what task the candidate is doing in the interview. It matters what the interviewer is looking at. I'm sure plenty of interviewers don't understand this, and I think this is often missed when people debate about Leetcode interviews - including in this article.

> most interview questions have very little to do with day-to-day responsibilities

You're missing what the interview questions are. Yes, one part of the interview is "here is a puzzle, can you solve it?", but many of the other questions should be things like "explain why this doesn't work", "why did you start with this approach?" and "are you sure that is the best name for that function?"

Leetcode interviews are perfectly "applicable", as long as the interviewer is using them as a convenient frame to see how you think, communicate, and write/read/edit code and isn't trying purely to assess your skill at quickly solving leetcode puzzles.

> cannot distinguish a senior programmer from a marketer using chatGPT

This is empirically false, because companies haven't suddenly lost all their hiring signal since ChatGPT came out. But if a company has this problem, they suck at interviewing.

(I admit the style of interviewing I'm describing has its own problems, and in particular doesn't address what I think is the biggest issue: the fact you're partly testing people's ability to (appear to) perform under acute pressure.)

[nine_k]

The problem with leetcode is time. If you know a good solution to a puzzle, or can instantly come up with it, you have the time to write it down, make it work, discuss, improve, etc. If you spend extra 10 minutes on a wrong approach, you're very strained, and if you spend 15 minutes, you're toast.

But knowing the good solution by heart is not the point! For that reason, when I ran code interviews, I often gave hints to the candidate, or sometimes just stated that a particular algorithm is a good solution, and it's usually implemented using this and that. ("Use BFS. You'll need a queue.")

This is where the demand for realistic conditions kicks in: at work, you're not going to invent an algorithm, you'll ask the machine what works in a situation like yours, consider, and choose. Doing otherwise would be imprudent.

[zanderwohl]

> but many of the other questions should be things like "explain why this doesn't work", "why did you start with this approach?" and "are you sure that is the best name for that function?"

This is important and something more interviewers should do. The blind adherence to leetcode doesn't tell you much, especially if you're silent during the interview instead of having a short back-and-forth every 15 minutes or so. The problem solving process is more important than the problem solved.

[simpaticoder]

>you're partly testing people's ability to (appear to) perform under acute pressure

You are also testing people's endurance. I once did an on-site interview with Google, and it was a solid 6 hours of leet-style puzzles, one after the other.

[godelski]

  > I admit the style of interviewing I'm describing has its own problems

We need to be clear, ALL styles of interviewing has problems. There's no global optima for problems like this. It's important to say this because people will point out problems as reasons not to switch while ignoring the existing ones. The answer entirely depends on "what are you optimizing for?" Be precise

Also worth pointing out, the style you describe is the traditional engineering interview. Leetcode type problems were initially done this way. It is also easy to make an effective system worse by trying to improve it. This often happens by trying to apply hard metrics to noisy problems. You don't improve your accuracy, you are just fitting a certain type of noise better (and encouraging Goodhart's Law).

[horns4lyfe]

That’s a good point, although of you’ve interviewed at big tech, plenty of times they’re just treating it like a standardized test.