Leetcode Is Dead, But 90% of Companies Still Ask Leetcode
The interviewer asks the canonical question, the candidate quietly uses AI, and both sides pretend everything is normal. That's the 2026 interview loop at 90% of companies. Everybody loses — the company filters for nothing, the candidate walks out feeling insulted.
One Startling Dataset
I put together a question-type tally covering 30 companies in China and abroad, 180 interviews:
| Question type | 2024 | 2025 | 2026 |
|---|---|---|---|
| Vanilla LeetCode | 67% | 58% | 51% |
| Reworded LeetCode | 22% | 28% | 30% |
| System design / real scenarios | 8% | 10% | 12% |
| AI-collaboration (use AI during the interview) | 0% | 2% | 4% |
| Non-coding (communication / values / project retro) | 3% | 2% | 3% |
Vanilla plus reworded = 81%. Interviews are still testing "can you produce an LRU cache, a tree traversal, a DP solution to a known problem, live, right now."
AI solves those with a 99% success rate. The interview is testing a skill that has already been automated.
Why Nobody Changed the Questions
I interviewed 12 interviewers and asked why not. Ranked:
1. Writing new questions is exhausting (45%) "I have my own code to write and a project to run. I don't have time to design original interview problems. LeetCode is sitting right there with reference solutions and a hint list."
2. Fear of being called unfair (25%) "Without a reference answer every interviewer scores differently, and then candidates complain. LeetCode has objectively right and wrong."
3. Habit and path dependence (20%) "This is how we've always interviewed. It's how I got interviewed."
4. No idea what an AI-era question looks like (10%) "I know LeetCode is useless now. I just don't know what to test instead."
Number 4 is the interesting one — plenty of people know the format is obsolete and have no idea what replaces it.
What the Companies That Actually Changed Are Doing
The remaining 10% fall into three buckets:
Bucket A: allow AI, raise the difficulty "You can use Cursor plus Claude. 30 minutes. Implement this payment callback flow. We want to see how you prompt, how you review the output, how you debug."
Testing not "can you write it" but "how good is your posture leveraging AI."
Bucket B: drop the coding, weight design and decisions "I'll describe a system. Tell me what database you'd use, why Redis and not Memcached, how you'd handle the failure modes."
Testing judgment — AI writes the code, but whether it should be written that way at all is still on you.
Bucket C: test code review Hand the candidate 200 lines of AI-generated code, 30 minutes to find the bugs, the security holes, the design that should change.
This is the closest thing to the actual job — a 2026 engineer spends 70% of the time reviewing AI output.
Hit Rates Across the Three
I followed 4 companies' actual 6-month performance after joining:
| Interview method | Median perf at 6 months | "Regret the hire" rate |
|---|---|---|
| Vanilla LeetCode | 6.2 / 10 | 31% |
| AI-collaboration | 7.4 / 10 | 18% |
| Design-heavy | 7.6 / 10 | 14% |
| Code review | 7.9 / 10 | 9% |
Code review has the best hit rate by a clear margin. It's where interviewers should be moving.
The Mirror Problem on the Candidate Side
Candidates are playing their own lose-lose game:
- Quietly use AI to pass (the small cheat) → join, discover the real work looks nothing like the interview → out of depth and miserable
- Refuse AI, go on merit alone (the clean-hands crowd) → look slow and incomplete next to peers who are using it → rejected
- The strong-candidate trap: you're genuinely good, but the interviewer is asking LeetCode 1-50 verbatim and you forgot the corner case in problem 23 → you don't pass
Strong engineers fail LeetCode interviews more easily. Because strong engineers moved on to specs and engineering judgment a long time ago and stopped grinding problems daily.
For Interviewers
Drop LeetCode. Not because AI made it useless — because it only ever tested one very narrow ability.
The simplest substitutions:
- Take the hardest bug you hit in the last 3 months and have the candidate debug it. AI allowed. You're watching how they trace.
- Hand them a PR diff and have them review it. AI-written, 3 problems hidden in it. See how many they find.
- Have them design a feature from your team's actual domain — payments, recommendations, rate limiting, billing. Whatever real complexity your product already has.
Each one is harder to write than a LeetCode question and carries ten times the signal.
For Candidates
Stop burning time on LeetCode grinding. Anyone still prepping "the top 100 frequent problems" in 2026 is fighting the last five years' war.
Spend that time on:
- Fluency in your own AI workflow — finish a medium-complexity task solo in 30 minutes
- Code review reps — pull an open source project's commit history, take some bug-fix commits, and work backwards to "why did this bug exist in the first place"
- Real system design — don't just read system-design-interview templates; build and ship an end-to-end micro SaaS yourself
When the interviewer asks LeetCode, answer it as usual, five minutes, fine. Just stop putting your preparation there.
When This Misalignment Gets Fixed
My estimate: 2027 is the watershed.
- Top-tier companies (FAANG, leading AI labs) are already replacing questions at scale
- Mid-size companies will copy the new question banks
- Small and mid companies will stand still for at least another 18 months
By the time the whole market's question bank has turned over, you'll have been at the new company for a year already. The people who move first eat the misalignment premium.