[paxys]

People keep saying this, but no one ever shares any meaningful data to make their case. Tech companies have been using Leetcode-style interviews to hire programmers for decades, and have grown in value from nothing to trillions of dollars in that time. The industry as a whole is worth tens of trillions, and the software these fake Leetcode programmers have built has eaten the world. Large companies have all spent billions on recruiting and internal processes and have come to the same conclusion - coding interviews work, and are very effective. Why should they stop? Vibes? Online comments?

[dimgl]

I used to agree with the anti-Leetcode sentiment like the OP, but changed my tune fairly quickly once I started doing actual production-grade software engineering that goes beyond just simple CRUD and realized the things that Leetcode tests are applicable everywhere. It just kinda clicked one day for me and I started passing Leetcode assessments.

Sure, some interviews are pretty hard and some algorithms/data structures are not as common on the job. But given a complex enough system, you'll run into lots of situations where having this foundation will pay off. I mean, it's just computer science.

That's the thing about software engineering. You can get a lot done without knowing the foundational stuff. But then you're just a blunt instrument. Everything looks like a nail to a hammer.

[AndrewStephens]

I am the OP. Please understand that I am not against coding problems in interviews. Anyone who has done any interviewing will tell you that a surprising number of supposedly qualified applicants cannot code at all (usually because they have been doing project management for too long.)

And if you have a specific industry need to invert a binary tree or fill 8 containers with 32 differently sized boxes or whatever then go nuts. But I have found working through a 30 minute exercise with the candidate, asking them to explain their thought processes, and listening to what questions they ask is much better than just giving them 30 minutes to bash their head against a problem.

It is more effort for the interviewer though because it cannot be automated. But it does allow you to scale the interview by asking things like "What would it take to make your code thread safe? Imagine 4 threads. Now imagine 1000, what would you change?", etc.

[stmw]

So I agree with both things you said here - besides filtering those that can't code at all, you learn a lot by working through the problem with the candidate. And vice-versa. "30 minutes to bash their head against a problem" is not a good interview process.

[ownagefool]

I'm pro make them code and test their big o.

Honestly it's 30-45 minutes where you can establish whether the person can code, and whether they have the basic foundational knowledge to crack efficiency problems is pretty hard to beat.

Whilst there's probably diminishing returns on making the actual challenge more and more difficult, the general concept is a lot fairer than the majority of other interview types I've had thrown at me. ( Usually something they've solved internally, where they expect you to regurgitate the same answers without the same context )

[hnthrow90348765]

The problem is leetcode interviews for CRUD jobs, and there is no accountability to really stop that.

This is in part due to job titles being meaningless. Senior Software Engineer has a very large dynamic range of technical ability needed when looking industry-wide. For example, if "Developer" was the non-leetcode title, and "Engineer" was the leetcode title (with harder interviews and higher pay), it'd make things a lot more understandable for everyone.

[w0mbat]

It's not a static situation. The questions have changed, to the point where solving them in interview conditions is a separate skill. When I interviewed people at Google, I asked interesting but quite simple questions and they gave me all the information I needed. As a candidate doing interviews elsewhere I have often been asked questions that are way too complicated to actually solve in the time.

How we got to this point : as average candidates train more in interview-coding, the interviewers pick harder and harder questions. It's got to the point where the only way to reliably pass is to have pre-canned memorized solutions to hundreds of existing questions. It's an arms race divorced from the reality of the job, which is done with real world tasks, privacy, little time pressure, and access to reference materials.