For about fifteen years, the standard coding interview was a LeetCode-medium problem on a whiteboard or shared editor. The format was stable because the underlying premise was stable: a well-prepared candidate writing code unaided in 30-45 minutes was a reasonable proxy for engineering ability. By 2024, the premise had broken. LLMs trivially solve LeetCode mediums. Candidates were either circumventing the format with AI tools or, more commonly, the format was simply no longer measuring what it had measured.
The 2026 coding interview is in transition. Some companies have stuck with the classic format and added enforcement (proctored interviews, screen monitoring). Others have shifted to formats that AI tools cannot trivially solve. This piece is a survey of the post-LLM coding interview formats and what each one actually tests.
The classic format (still alive at FAANG)
The original LeetCode-medium-on-a-shared-editor format has not disappeared. Most FAANG companies still use it, often with the addition of proctored remote interviews to deter AI use. The format is still effective at filtering out candidates who cannot code at all and at distinguishing strong from average performers when the problem is harder than what an LLM trivially handles.
The remaining problem set has shifted toward harder LeetCode-hards, multi-step problems with subtle constraints, and questions that require novel decomposition. The bar has risen because the LLM can solve the easier problems for the candidate and the company needs to filter on the residual.
Live debugging interviews
One of the fastest-growing formats. The candidate is given a real codebase (sometimes 10,000+ lines) and asked to fix a planted bug or implement a small feature. The bug or feature requires the candidate to navigate the codebase, understand the architecture, and make a focused change.
What this format tests:
- Code reading skill — can the candidate find the relevant code in a large unfamiliar codebase?
- Hypothesis generation — can the candidate form theories about where the bug is and verify them efficiently?
- Surgical changes — can the candidate make minimal, well-targeted changes rather than rewriting unrelated code?
- AI-tool fluency (when AI is permitted) — can the candidate use AI to navigate and understand the codebase efficiently?
This format is harder for LLMs to game because the codebase is novel and the bug is non-obvious. Companies using it: GitHub, GitLab, some Atlassian teams, several modern startups.
Real codebase pair programming
Similar to live debugging, but the task is open-ended: “let’s add a feature to this codebase.” The candidate has 60-90 minutes to ship a working feature in a real codebase. The interviewer pairs with them.
What this format tests:
- Whole-task delivery — can the candidate plan, implement, test, and document a small feature?
- Code style match — can the candidate match the existing codebase’s conventions rather than imposing their own?
- Trade-off articulation — when the candidate makes a choice, can they explain the alternatives they considered?
- Pair-programming dynamics — can the candidate work fluidly with the interviewer’s interjections?
AI-collaborative coding (covered in detail in the Anthropic and Cursor-era pieces)
The candidate uses AI tools openly; the interviewer grades the AI-collaboration skill. This is the format pioneered by Anthropic and increasingly common at AI-native companies.
Take-home with live follow-up
Stripe pioneered this format and many companies have adopted it. The candidate completes a take-home assignment over 4-8 hours, submits it, and then has a 60-90 minute follow-up where the interviewer asks the candidate to walk through the code, modify it, or extend it on the spot.
The follow-up is the actual evaluation. A candidate who used AI tools heavily in the take-home but cannot navigate the resulting code in the follow-up is filtered out. A candidate who used AI tools and genuinely understands the work passes the follow-up easily.
This format effectively makes the AI tool policy moot: the company does not care if you used AI, because the follow-up tests whether you understood what you submitted regardless of how it was produced.
Trial day / paid trial week
The candidate works on the team for a day or a week, paid, while both sides evaluate fit. Used by some YC startups and a handful of larger companies. Effectively replaces the entire interview loop with actual work.
What this format tests: everything. Real work output, team dynamics, communication, code style, debugging, architecture decisions, integration with existing engineers.
The format is expensive (the company pays for the candidate’s time and the team’s time), so it is rare. When it is used, it is often the most accurate predictor of post-hire performance.
The “explain this code” format
Less common but emerging. The interviewer shows the candidate a piece of moderately complex code (often code the AI tool produced) and asks them to walk through it line by line. Why does this code work? What is its time complexity? What edge cases does it handle? What edge cases does it miss?
This format directly tests the skill that AI tools cannot replicate: deep understanding of code’s behavior. The candidate who has spent time writing code unaided can explain code; the candidate who has only directed AI tools sometimes cannot.
What companies have largely abandoned
The pure brainteaser interview was already extinct in 2026 (Google’s 2013 retreat). Pure verbal-only “design this” with no code was always rare. The “rewrite a complex algorithm from scratch on a whiteboard” format has shifted to shared editors uniformly. None of these have changed dramatically because of LLMs; they had already shifted earlier.
How to prepare for the new formats
- For classic + harder LeetCode: grind harder problems. The bar has risen at FAANG. Aim for LeetCode hards rather than mediums.
- For live debugging: practice navigating real open-source codebases. Take an issue from a project you do not know, find the relevant code, fix it. Build the muscle.
- For real-codebase pair programming: contribute to open source. Real codebase work is hard to fake.
- For AI-collaborative: see the dedicated piece on prompt engineering during coding interviews.
- For take-home with follow-up: use AI tools as you would normally, but make sure you understand every line of what you submit. The follow-up will test it.
- For “explain this code”: read other people’s code regularly. Practice articulating what code does, not just writing it.
Frequently Asked Questions
Is LeetCode dead?
No. The classic format is alive at FAANG and at most companies that use scaled hiring. The bar has risen, but the format has not been replaced.
Which format is the strongest signal?
Trial week is the strongest signal because it is most like the actual job. Take-home with live follow-up is a close second. Pure LeetCode is the weakest signal because LLMs can solve so many of the problems.
Are AI tools allowed in live debugging?
Increasingly yes; the format is most natural with AI assistance because real engineering on real codebases involves AI tools. Confirm with the company.
How do I know which format a company uses?
Ask the recruiter. They will usually tell you. If they cannot, the company likely uses the classic format with no special twist.
What is the safest preparation path if I do not know the format?
The classic LeetCode + system design + behavioral preparation still covers 70% of interviews. Add take-home preparation (a portfolio project you understand deeply) and contribute to one open-source repo to cover the live-debugging variant. Total prep effort: 8-10 weeks for senior candidates.