Hacker News Reader

Comment by AndrewStephens | Hacker News Reader

Cracking the Code Interview is a great book and excellent for practice and brushing up. But I have found leet-code questions terrible for actually interviewing candidates. A lot of them boil down to whether the candidate knows the specific trick or can regurgitate the memorized solution.

(Maybe I am just bitter because I have more than once bombed a leet-code interview myself)

I interview a lot of people and my go-to coding question is actually a pretty simple question that might be found in a 2-year coding course. What I am looking for is production ready code, good error handling, tidy design, and understandable code. All things that leet-coding specifically discourages.

View on HN

Leet Code style questions are a shorthand assessment for two things:

1. Raw mental horsepower

2. The ability to just repeatedly do focused learning, aka just grinding

And sure, it probably does favor #2 these days - but that is a critically important skill. You can trade one for the other, but everybody has some amount of both, and these questions figure out, roughly, your computed aggregate score of these.

They have a very high false negative rate, but an exceptionally low false positive rate for a 60 minute interview, so it works very well in companies with large interview candidate pipelines.

It's def not "Raw mental horsepower" it's more knowing an obscure algorithmic trick.

People love to say things like this. In my experience on both sides of these coding interviews in FAANG companies, the questions are basically never algorithmically intensive.

The furthest I've ever seen it go in practice: binary search, BFS/DFS, hash tables. I've never seen any more obscure algorithmic trick than standard uses of these algorithms and data structures.

I'm not saying leetcode doesn't have more insane questions, but interviews tend to be straightforward.

Why is 2, the ability to grind/memorize random problems, important for any company? I can't think of any company I've worked at, where that would be useful during my day to day work.

You don't think rote learning is a desirable skill of candidates that employers look for?

Can you think of anything we do for, say, the first two decades of our life, that could send this signal?

Maybe I'm in the minority, but I don't think the ability to memorize dozens of algorithms and then spit them out on demand is really that useful to most practicing software developers, nor is it a good signal about one's technical expertise.

I disagree. Many of the leet code problems can be solved by thinking them through and coming up with a solution without ever seeing the problem before. If the candidate gets stuck, the interviewer should act as a partner and offer occasional hints in case some sort of trick is involved.

Maybe we have different things in mind when we say "leet-code questions".

I don't know why leet-code style interviews would discourage the things you mentioned.

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?

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.

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 )

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.

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.

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.

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.

Reply on news.ycombinator.com