2026-07-27 · 6 min read

The coding interview is quietly turning into a code review interview

There are two numbers that together explain what's happening to technical interviews this year, and once you see them side by side it's hard to unsee. First: Fabric analyzed 19,368 technical interviews between July 2025 and January 2026 and found signs of AI assistance in 38.5% of them, climbing to 48% in purely technical roles, with 61% of the cheaters passing the bar anyway, which means the cheating isn't even bad cheating, it's good enough cheating that the interviewers can't reliably tell. Second: a current frontier model solves a LeetCode medium in well under a minute, with correct code, on the first try. Put those next to each other and the classic write-code-on-a-whiteboard round has a problem that goes deeper than cheating: even when nobody cheats, it now measures a skill that the actual job needs less of every single quarter.

The signal died twice, for two completely different reasons

The integrity problem gets the headlines, and it's real. Tools like Cluely and its open-source clones whisper answers through a screen overlay that looks like nothing on a shared screen, detection is permanently one step behind, and Fabric's data shows the cheating rate roughly doubled in the second half of 2025 alone, from about 15% to 35%. You can respond to that with an arms race of proctoring and monitored screens and browser lockdown software, and some vendors sell exactly that, but it's the kind of solution where winning looks a lot like losing because the fundamental problem isn't that candidates found a way to cheat. The fundamental problem is that the thing they're cheating on stopped mattering.

That's the deeper reason, and it has nothing to do with integrity at all. The job itself moved out from under the interview. Google's Sundar Pichai has said around three quarters of Google's new code is now AI-generated and reviewed by engineers, which means the day-to-day work for most of those engineers is reading code they didn't write, deciding whether it's correct, and catching the spots where a confident-looking function does the wrong thing. An interview that watches someone hand-write a topological sort from scratch is auditioning candidates for a role that's quietly disappearing, while telling you absolutely nothing about the role they'll actually do once they have the badge.

What the replacement round looks like

The pivot is already visible at the companies that set the template everyone else copies within two years. Google's interview loop for junior and mid-level engineers now reportedly includes a code comprehension round: you get 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, which you're expected to use. Meta piloted similar AI-aware coding rounds in late 2025 with models available to the candidate during the problem. The logic in both cases is the same and it's hard to argue with: stop pretending the model doesn't exist, hand the candidate realistic code that someone (or something) else wrote, and evaluate the one part the model genuinely can't do for them, which is judgment. Can you build a mental model of unfamiliar code under time pressure, spot what's actually wrong, tell a real defect from a stylistic preference, and then commit to a verdict you can defend out loud?

There's a side benefit that's almost too elegant: this format is naturally cheat-resistant, and not because of any proctoring technology. When the AI is explicitly allowed in the room, there's nothing left to smuggle in. The thing being graded is what you do with the AI's output, and no overlay can whisper that to you because it's not a fact to retrieve, it's a judgment to make.

How to prepare when there's no infrastructure for the new round

Here's the awkward part for candidates: there are twenty years of infrastructure for practicing the old round, thousands of LeetCode problems and YouTube walkthroughs and bootcamp curricula, and almost none for the new one. The skill being tested now is reading unfamiliar code and finding what's wrong with it, and the ways to practice that are still scattered and mostly improvised.

A few things transfer, though, and from running a review trainer and watching where people actually lose points, the pattern is consistent enough to be worth describing. The single biggest source of missed points is not reading the requirements before reading the diff, which sounds almost too obvious to say, except that most people don't do it under time pressure. They open the code first, start forming opinions about the code, and never go back to check whether the code actually matches what was asked. Most planted bugs in review rounds are fidelity bugs, code that does something plausible that isn't what the spec said, because they're cheap to write and devastating to miss, and the candidates who read the requirements first catch them at roughly twice the rate of the candidates who don't.

The second thing that separates strong from weak in a review round is naming the consequence, not just the line. "This is wrong" scores nothing in an interview, the same way it scores nothing in a real review, because the interviewer can't tell whether you understand why it matters. "A stale response can overwrite the newer one when the user types fast" shows you traced the causal chain from the bad line to the production impact, and the causal chain is the thing being graded, not the line number. On the flip side, flagging imaginary problems reads worse than missing real ones, because it tells the interviewer you'd flood their team's PRs with noise if they hired you. If the code is actually fine, saying "this looks correct, here's why" is a strong answer, not a missed opportunity. And finally, the verdict itself matters: approve or request changes is a decision under uncertainty, and hedging with "well, it depends on the context" is the weakest possible ending. Practice committing to a call and defending it, because that's the skill the round is measuring.

All of this is trainable with reps, and reps need feedback, which is the part that's hardest to find on your own. On DiffDojo you review realistic AI-written PRs with known planted bugs, give a verdict, and get graded against a canonical review that shows you what you caught, what you missed, and which of your comments were noise. The profile that accumulates over time, catch rate by failure category, verdict accuracy, false-flag precision, is the closest thing to a measured answer to "am I actually ready for this round." Today's PR is free, no signup.

The old interview advice was "grind problems until pattern recognition kicks in," and honestly the advice still holds. Only the patterns changed. They're no longer sliding windows and binary searches and dynamic programming on a whiteboard. They're hallucinated APIs that read like real ones, async code that doesn't actually wait, and implementations that are adjacent to the spec but not quite the spec, which is a much harder thing to spot than a missing semicolon, and a much more useful thing to be good at.