Is LeetCode Dead? What’s the Alternative?

This newsletter is sponsored by CodeRabbit.

Review the PR that matters most. CodeRabbit Triage ranks work across repositories, tells you what to review next and what needs your action. It also flags low-risk PRs that may be ready to close, so your queue shrinks effectively.

Try CodeRabbit

Thanks to CodeRabbit for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Are leetcode-style tech interviews finally becoming a thing of the past?

I’ve been talking with different engineers, engineering leaders, hiring managers, and recruiters about how technical interviews are changing.

And in this article, I am sharing the insights from these conversations and what I’m personally seeing across different companies.

In particular, we will answer the question if leetcode is dead, what are the alternatives that are gaining the most traction, and what I personally recommend instead of leetcode-style interviews.

Let’s start!

Leetcode-style of a tech interview have been a standard for years

Leetcode (the platform) was founded in 2015, and quite quickly after that, it became the go-to style for tech interviews in many companies. It has become a standard for “objectively” assessing the technical skills of a certain candidate.

Well, I was never a fan of it, and I’ll tell you why.

When I was a Software Engineer, preparing for interviews, I solved 200+ leetcode style type challenges, and while solving them, I kept looking for specific patterns that could be reused across different challenges.I made sure to create templates, which I could reuse for any problem that I’d be asked to solve in an interview. So, doing that, I was well prepared for interviews, and I also nailed the interview and got the job.Well, that felt good, that I was able to “grind” leetcode challenges for weeks, and I got the job, but then none of it really helped me in my day-to-day work.The work that I was doing was completely different than what I had been grinding for weeks.

So, basically, with the leetcode-style type of interview, you don’t really assess the actual skills that a specific engineer needs to be able to do the job well. You assess whether the person has been practicing such types of challenges or not.

“I’d be surprised if, by the end of 2026, companies still use such a type of an interview”

This is what Sulman Choudhary, Head of Engineering, ChatGPT, OpenAI, mentioned when I spoke with him earlier this year.

Especially these days, with AI, you can solve any of the leetcode-style challenges in a matter of seconds.

And if the standard in our industry is AI-assisted engineering, then it really makes no sense to “check the tech skills” with problems, which can be easily solved with a prompt.

I feel the same as Sulman, and I have never recommended leetcode-style type interviews (and also never personally advocated for them in my freelance and full-time roles), but surprisingly, there’s still a lot of companies using them.

I’ve talked to many people about this recently, and many share a similar sentiment.

But while many of them don’t like this type of tech interview, it seems they still very much exist across different companies. But I do see a decrease. Let’s go through that next.

Bigger companies are still doing leetcode-style tech interviews

Talking with different engineers, engineering leaders, hiring managers, and recruiters, the leetcode type tech interviews are still very much present in Big Tech and a lot of other bigger companies.

Companies like Google, Meta, Amazon, Apple, Uber, LinkedIn, etc. are still using this type of interview, especially for more backend-related roles.

And I get it; this type of interview is an objective measure, and when you’re dealing with so many engineers interviewing at the same time, it’s a way to objectively measure the results.

So, if you’re planning to interview at such a company, I highly suggest practicing such problems.

I do see some movement and “pilot” adjustments in order to be more reflective of the actual work that engineers do on a day-to-day basis. Google started an initiative called the “Code Comprehension round”.

According to Business Insider, especially for junior and mid-level roles, they have started using such an interview.

In this round, you receive a 200-500 line unfamiliar codebase, and you have 60 minutes to read it, find bugs, discuss design decisions, and suggest improvements, all while they allow you to use AI (Gemini).

There’s a much smaller chance of getting a leetcode-style tech interview at small-to-mid-size companies and AI labs

I know for quite some time now that both OpenAI and Anthropic are not big fans of this type of interview, and as you can see from the X post below, Felix Rieseberg, who is an Engineering Manager at Anthropic, even mentioned that he doesn’t see so much value in coding interviews altogether.

In his post Hunger beats tenure: Advice for junior engineers, he argues that projects beat any code written these days, which is especially relevant for junior engineers.

And the specific projects that have been built should be a much stronger signal than pure coding interviews.

Additionally, from talking with many other folks in small-to-mid-size companies, the leetcode type interview is an exception rather than the rule. Here are some alternatives I have seen or heard of.

3 most popular alternatives

Code review exercise seems to be emerging as one of the strongest alternatives

A lot of people mentioned that this is the format that they prefer now. This is quite similar to the “Code Comprehension round” by Google, where you provide a piece of code to the candidate, which includes intentional bugs, performance issues, security concerns, or opportunities for improvement.

In this round, you are evaluating how well candidates understand unfamiliar code, identify potential problems, communicate feedback, and make trade-offs. It closely resembles the work engineers do every day → doing a code review.

Product & Technical deep dive

This was mentioned by Sulman Choudhary, Head of Engineering, ChatGPT, OpenAI. It’s a combination of a System Design interview, together with product/business and AI understanding.

In this interview, candidates are given a problem that is mostly a problem related to AI. They are asked to think about the problem and how they would approach building a product around it. There is no prework required.

During the interview, the candidate and interviewers work through the problem together. They discuss what the product specification might look like and what kinds of systems and architectures would be needed to build it.

Solving a real-world problem or doing pair programming (with AI usage allowed)

The candidate is given a practical engineering task. The goal is to evaluate how effectively they use AI, understand generated code, identify mistakes, write tests, and verify their solutions.

My personal recommendations instead of leetcode

Option 1: Open-ended questions

This is my recommended type of a tech interview. This is where you are talking about a certain project, or a problem that is highly relevant to what the candidate would face on the job.

And the goal is to get a feeling how the candidate thinks and approaches problems. I definitely also recommend talking about how to use AI, when to use it, how to structure the prompts, and how to optimize them in such an interview.

Here are some questions:

Tell me about the hardest problem you have solved?
Tell me about the recent project you have worked on?
How would you solve X? (where X is a highly relevant situation in the role they are interviewing)

Sub-questions like:

What was your role on the project?
How have you contributed to its success?
What alternatives have you considered before implementing the solution?
What trade-offs did you make?
How did/would you use AI to help you deliver the project faster?
How did you know the output was correct?
How to optimize the output?

The key is to understand their judgment. How they approach solving problems, what alternatives they have thought of, whether they are a team player, and of course, how they have used AI or would use it to help them deliver the project faster.

And very importantly, you get a sense of how they communicate. Are they clear in how they are describing things, are they confident in their knowledge and understanding, or are they just blindly accepting the first solution that has been generated by AI.

Option 2

The second option is a pair-programming challenge.

I recommend giving a task that is closely related to what the candidate will be doing on a daily basis. That may be implementing a new backend service, a frontend functionality, or maybe a landing page for a new marketing campaign.

The key is to get as close as possible to what they would be doing on the job.

The candidate then shares the screen, and you work with them together, like doing a pair-programming session with a fellow engineer.

They can ask any questions they want, they can use any of the tools they would like, AI tools, IDEs, Google, Stack Overflow, etc.

The key to this challenge is not the end solution and how the code looks in the end, but how it feels working with them, and how good their judgment is in general.

Are they considering the trade-offs, are they thinking about alternatives, are the structuring prompts the right way, are they validating the output from AI tools, etc.

That tells me a lot more than the end solution.

Option 3

Another option can be a mix of both open-ended questions and a challenge, or you can also do 2 (or more) challenges, where one focuses more on solving the challenge that is highly relevant to the role without AI tools, and another challenge with AI tools.

And then you focus more on pure implementation in the first challenge, and in the second, you focus more on how they are using AI tools, whether they are validating the output, and whether they keep in mind good practices.

My recommendation is to use any of the variation/combination that you see best fit for your case. Every situation is different, and one interview type may not work for all different organizations.

What I don’t recommend

The take-home task is something that I believe to be less relevant these days, as basically anyone can generate the solution based on requirements and push it to a public repo on GitHub.

So, that gives less of a signal on how well they’d perform in the role. You can, of course, jump on a call with them and ask them for an explanation on certain parts, ask for alternatives, and why a certain decision was made.

But the reality is that with AI, you can already “prepare” quite well in advance for such questions, and a person could be lucky to get away with not really understanding what they have built.

Last words

Let’s end this article with the following:

Leetcode is not dead, but I believe the actual usage is declining and is used mostly in bigger companies, due to the high volume of applicants. I was never a fan of them, and I have always advocated for other options.But the reality is that if you want to work at a bigger company, especially in Big Tech, there’s still a good chance you’ll need to prepare for them.

You got this!

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

Interested in sponsoring this newsletter? Check the sponsorship options here.
Check out my book “The Multiplier Mindset” coming out later this year, .
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

参与讨论