[sockgrant]

I’ve heard plenty of horror stories about someone being hired that couldn’t write simple code.

It’s easy to study leet code, and it’s relevant because it shows the interviewer you can write code.

I’ve had non-leet code interviews, like write some feature in 60minutes. It was fine. It tests code and knowledge as opposed to just algorithms and tricks.

I dunno I’ve always felt that the people who can’t leet code are the ones that complain about it. The ones that can just spend a bit of time to practice and ace the interview.

[bmitc]

> It’s easy to study leet code, and it’s relevant because it shows the interviewer you can write code.

I have a million things I want to learn about. If a potential employer would rather I spend time on what amounts to trivia, then great, I don’t want to work there.

> I’ve had non-leet code interviews, like write some feature in 60minutes.

This is also a problem because it’s impossible to understand the constraints, context, specifications, etc. during this time. When I am asked to implement a feature in the real world, it takes time to understand the domain and context. Writing code is usually the last and easiest bit. It also never occurs that you need to understand and complete something in just an hour or two.

So in leetcode interviews you’re asked to turn on a bunch of knowledge you don’t really need. And in implement this feature interviews, you need to turn off a bunch of important knowledge and experience.

Both are irritating interviews.

The best way to interview, in my experience, is to ask about a project or projects someone has worked on. Even better if there’s time for them to present on it. That way you get a real world picture of their skills, they are comfortable, and you can ask detailed questions without jumping the shark. Further, it is perfectly reasonable for someone to be required to present and answer questions over something they’ve worked on in an hour or two. That does happen in the real world.

[xyzi2]

I’ve conducted many interviews that starts off with asking questions about projects. Many candidates sound like rockstars. They even nail all sorts of technical follow-up questions. Then when I start asking coding questions, and I’m not talking leetcode here, more similar to fizzbuzz, they can barely write an if-statement. My conclusion is that some people are great at talking, but you really need to test the technical abilities too.

[jonwithoutanh]

Perhaps your technical questions are not adequate enough if someone can sound like a "rockstar" while not being able to program an if statement?

I've interviewed hundreds of people over my career and I've never had an interview where I couldn't figure out their technical abilities through a conversation.

I'll tell you what leetcode interviews do find you though, they find you people that have no idea how TCP/HTTP work, they have no idea how you would debug a distributed system. They've never deployed anything to a server. They probably have no idea how to even measure the amount of work being performed by a server. They've never thought about CI/CD/Deployment/Scalability. They've never used any cloud resources. They have potentially never been through a code review.

etc, etc, etc, etc.

Someone crushing a leetcode test tells me about 1% of the stuff I'd like to know about their knowledge and abilities.

[sockgrant]

Yeah FAANG have those type of interviews too.

[trulyme]

The best interview strategy for me is to give a short take-home assignment (coworkers go through it in under an hour max.) which is somewhat related to the domain space we are hiring for.

Some solutions are rejected on the spot (bad practices, does not solve the task correctly), other candidates are invited for a technical interview. Some generic questions, then we go through the solution - with emphasis on less than perfect areas. It is quite easy to see when someone is bluffing, and you also see how the person deals with feedback.

[hiq]

> The best way to interview, in my experience, is to ask about a project or projects someone has worked on.

This doesn't scale and introduces a bunch of biases on other dimensions. People who don't have time to prepare for leetcode interviews might be the same ones that don't have time to work on FOSS, and it could be that they can barely talk about their past work for IP issues. It's also way easier to fake your way through a high-level discussion of a software engineering project (that the candidate prepared) than through a leetcode interviews.

[hokumguru]

At this point, the leetcode interviews are as much of a behavior interview as they are a technical one, no? It makes sense that they're only hiring candidates willing to spend the time and effort studying.

[erik_seaberg]

“Ask about a project” proves I understand the final implementation, but not whether I could or did choose that approach or design it myself, nor how long it took and how many false starts we had.

[vmception]

> I dunno I’ve always felt that the people who can’t leet code are the ones that complain about it.

You mean the ones that randomly receive a random problem that they hadn't memorized before.

[sockgrant]

If you’re struggling I don’t think you should try to memorize leet code problems, you should try to understand how to apply algorithms.

[skydhash]

We know how to apply them, it just that algorithms are not fit all solutions for most type of problems you encounter in the real world. I had to write a frequency analysis code. What I did was search for existing methods, found a paper that provides a mathematical procedure, then convert it to code. The data structures came directly from the OS and thankfully, there were no need to convert them to something else.

I'd say a lot of us learn about algorithms and data structures early in their career. But most of them are guidelines, not rules. So, you just remember how to google for them, not learning specific ones by heart. No one has ever told me: You need to work on this string manipulation and be done within 30mns.

[vmception]

And on the actual job you have two weeks on the sprint with barely any consequence, not time trial to beat the averages set by desperate college kids from Asia.

[sockgrant]

There’s probably better code writing interviews to be conducted, but I think writing code in an interview is important. I’ve conducted many interviews in C where the candidate has years of C but doesn’t know the stack from the heap.

So I dunno, it’s not fun doing the gimmicky leet code questions but it definitely filters candidates.

I think people in this thread take them for granted… many candidates struggle with them. The ones that think they’re easy and you just gotta study a little bit — they’re honestly probably pretty smart.

[geraldwhen]

I run feature code interviews. There are no tricks, just data modeling, simple logic, and automated tests.

I am exceptionally good at algorithms problems and I recognize it is not a useful skill I want to filter on when hiring. A dev team of 20 may only need a few to really understand algorithms to look over relevant pull requests. and even then such situations may be rare