The rule changed mid-game
For a decade the coding interview had one unwritten law: close the tab, no autocomplete, definitely no AI. That law is breaking.
Across late-2025 into 2026, multiple companies have reportedly started running AI-enabled interview rounds — where the assistant isn’t contraband, it’s part of the toolkit. The reasoning is blunt: you’ll use AI every day on the job, so they want to watch you use it well.
This is not universal yet, and the exact format differs per company and per team. Treat the specifics below as the reported shape of the shift, not a guarantee of what you’ll face. But the direction is clear enough to prep for.
What the new rounds reportedly look like
Meta — AI-enabled coding round. Reports describe a CoderPad-style environment with a three-panel layout: a file explorer, a code editor, and an AI chat panel. Roughly 60 minutes. You drive; the AI assists on request. The problem tends to be larger or more open-ended than a classic single-function LeetCode prompt, because they expect AI to absorb the boilerplate.
Google — code-comprehension round. Reports point to a round centered on reading and reasoning about code, paired with a Gemini-style assistant. The skill under the microscope is understanding an unfamiliar codebase and explaining/modifying it correctly — not recalling syntax.
Shopify — multiple AI-enabled rounds. Shopify has been public about expecting AI fluency, with several rounds where AI use is allowed or encouraged.
Canva — AI tool use required. Reports indicate rounds where using an AI tool isn’t just permitted but expected as part of how you work.
Different harnesses, same thesis: the interview now includes the AI, so it can measure how you collaborate with it.
The real eval shift: produce → judge
This is the whole point, so sit with it.
Old question: “Can you produce correct code?”
New question: “Can you judge code?”
When the AI can generate a plausible solution in four seconds, generation stops being the bottleneck — and stops being the signal. What’s scarce, and therefore what’s tested, is everything around the generation:
- Prompt quality — can you specify the problem precisely enough to get useful output?
- Spotting wrong output — can you tell when the AI is confidently incorrect?
- Debugging it — when it’s wrong, can you fix it instead of re-rolling and hoping?
- Verifying correctness — do you actually test, or do you trust the vibes?
- Knowing when not to trust it — do you recognize the cases where the AI is structurally likely to fail (tricky edge cases, unusual constraints, security-sensitive logic)?
You cannot validate code you don’t understand. That’s why this format does not let you skip fundamentals — it raises the floor on them. The AI writes the first draft; you’re the senior reviewer who has to sign off.
How to prep
Still master the patterns. You can’t catch a bug in a sliding-window solution if you don’t know how the window is supposed to invariant-hold. Everything in /interview/coding-patterns/ is now validation equipment, not just production equipment. Know the patterns cold so you can audit AI output against them in real time.
Practice prompting deliberately. Don’t free-associate at the model. Practice stating the problem, the constraints, the signature you want, and the edge cases up front. Then practice the follow-up: “this fails on an empty array — fix only that.” Tight prompts get tight code.
Practice reading and debugging AI-generated code under time. This is the muscle almost nobody trains. Generate a solution, then hunt it: where’s the off-by-one, the unhandled null, the wrong base case, the O(n²) hiding in an innocent .includes() inside a loop? Do this on a clock, because the round is on a clock.
Communicate your verification out loud. “Before I trust this, I’m going to trace it on [], on a single element, and on duplicates.” Saying it is half the score.
What interviewers actually score
Same human judgment as always, pointed at a new surface:
| Signal | What good looks like |
|---|---|
| Problem decomposition | Breaks an open-ended prompt into pieces before prompting |
| Prompt iteration | Refines the ask when output is wrong, instead of accepting it |
| Catching bugs / edge cases | Spots incorrect AI output and names why it’s wrong |
| Testing | Runs concrete cases; doesn’t declare victory on a clean compile |
| Clear reasoning | Explains every line of the final code as if they wrote it |
Notice none of these is “typed the answer fastest.” The AI types fast. You’re scored on judgment.
Common failure modes
These are the ways candidates lose an AI-enabled round:
- Blind paste. AI emits code, candidate drops it in, moves on. First failing test ends them — because they never read it.
- No testing. Clean compile treated as correct. The edge case they never ran is the one the interviewer planned the whole question around.
- Over-prompting instead of thinking. When stuck, they re-prompt the model ten different ways rather than reasoning about the actual bug. The interviewer watches a candidate outsource their thinking and finds nothing to score.
- Can’t explain the code. “Why does this line use
<=and not<?” — silence. If you can’t defend the generated code, you didn’t earn it, and the interviewer knows.
The throughline: every failure mode is a failure to engage with the AI’s output as a critical reviewer.
In the room: running 60 minutes
A concrete way to spend an AI-enabled hour without drowning:
Minutes 0–10 — understand and decompose, no AI yet. Read the prompt. Restate it. Clarify constraints and inputs with the interviewer. Sketch the approach and name the pattern out loud. Do this with your own brain — it’s the part the AI can’t do for you, and it frames every prompt that follows.
Minutes 10–35 — drive the AI in small chunks. Prompt for one piece at a time with a clear spec (“write a function that merges overlapping intervals, sorted by start, O(n log n)”). Read every line it returns before accepting it. Narrate what you’re checking. If it’s wrong, fix it directly or re-prompt with the specific defect — don’t blank-slate retry.
Minutes 35–50 — verify hard. Run it. Trace the nasty cases yourself: empty input, single element, duplicates, max constraints, the off-by-one boundary. Say what you’re testing and why. This is where most of your score lives.
Minutes 50–60 — explain and harden. Walk the interviewer through the final solution as if you wrote every character. State the complexity. Call out one edge case you’d add a test for in production. Close like a senior reviewer signing off on a PR.
The shape to internalize: you think, the AI types, you verify. Never the reverse.
Where this fits
This format doesn’t replace the rest of your prep — it sits on top of it. You still need the patterns to validate output: /interview/coding-patterns/. You still need to reason about scale and trade-offs, which AI is especially shaky at: /interview/system-design-int/. And the only way to get fluent at narrating your judgment under time pressure is reps: /interview/mock-coding/.
The candidates who win these rounds aren’t the ones who prompt the best. They’re the ones who’d have passed the old closed-tab interview and know exactly when to stop trusting the machine.