2026-07-27 · 6 min read

The coding interview is quietly turning into a code review interview

Two numbers explain what's happening to technical interviews this year. First: Fabric analyzed 19,368 technical interviews between July 2025 and January 2026 and found signs of AI assistance in 38.5% of them, rising to 48% in purely technical roles, with 61% of the cheaters passing the bar anyway. Second: a current frontier model solves a LeetCode medium in well under a minute. Put those together and the classic write-code-on-a-whiteboard round has a problem worse than cheating: even when nobody cheats, it now measures a skill the job needs less of every quarter.

The signal died twice

The write-code interview is failing for two independent reasons. The integrity reason gets the headlines: tools like Cluely and its open-source clones whisper answers through an overlay, detection lags a step behind, and Fabric's data shows the cheating rate roughly doubled in the second half of 2025, from 15% to 35%. An arms race of proctoring and monitored screens is one response, and some vendors sell exactly that.

But the deeper reason has nothing to do with integrity. The job itself moved. Google's Sundar Pichai has said around three quarters of Google's new code is now AI-generated and reviewed by engineers. If the day-to-day work is reading, judging, and correcting generated code, then an interview that watches someone hand-write an algorithm is auditioning candidates for a role that's disappearing, while telling you nothing about the role they'll actually do.

What the replacement round looks like

The pivot is already visible at the top of the market. Google's interview loop for junior and mid-level engineers now reportedly includes a code comprehension round: an hour with a multi-file codebase you've never seen, tasks that include finding and fixing what's broken, and, notably, an AI assistant available inside the session. Meta piloted AI-aware coding rounds in late 2025 with models available to the candidate during the problem. The logic is the same in both: stop pretending the model doesn't exist, hand the candidate realistic code, and evaluate the part the model can't do for them, which is judgment. Can you build a mental model of unfamiliar code, spot what's wrong, distinguish real defects from noise, and defend a decision?

Notice that this format is also naturally cheat-resistant, and not because of proctoring. When the AI is allowed in the room, there's nothing left to smuggle in. What's being graded is what you do with its output.

How to prepare for a review round

The awkward part for candidates: there are twenty years of infrastructure for practicing the old round and almost none for the new one. A few things that transfer, from running a review trainer and watching where people lose points:

• Read the requirements before the diff. Most missed bugs in review are fidelity bugs: the code does something plausible that isn't what was asked. Interviewers plant these because they're cheap to write and devastating to miss.
• Name the consequence, not just the line. "This is wrong" scores nothing. "A stale response can overwrite the newer one when the user types fast" shows the causal chain, and the causal chain is what's being graded.
• Practice restraint as explicitly as detection. Flagging imaginary problems reads worse than missing real ones: it tells the interviewer you'll flood their team's PRs with noise. If the code is fine, saying "this is fine" with reasons is a strong answer.
• Rehearse the verdict. Approve or request changes is a decision under uncertainty, and hedging ("well, it depends") is the weakest possible ending. Practice committing and defending.

All four are trainable with reps, and reps need feedback. On DiffDojo you review realistic AI-written PRs with known planted bugs, give a verdict, and get graded against a canonical review: what you caught, what you missed, which comments were noise. The profile that accumulates (catch rate by failure category, verdict accuracy, precision) is the closest thing to a measured answer to "am I ready for this round". Today's PR is free, no signup.

The old advice was "grind problems until pattern recognition kicks in". The advice survives; only the patterns changed. They're no longer sliding windows and binary searches. They're hallucinated APIs, async that doesn't wait, and code that's adjacent to the spec but not the spec.

Read next: Junior developers should learn code review before anyone pays them to write code