[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.