Why Reviewing AI Code All Day Leaves You Rusty for Interviews

There's a particular unpleasant surprise that I think a lot of working engineers are currently on track for, and I'd much rather you meet it at your desk than in a real loop. Your job, somewhere over the last couple of years, tilted toward prompting an assistant, reading what it produced, and deciding whether to keep it. You feel sharp, because you exercise judgment about code all day long. Then an interview lands on the calendar, you open a practice problem in an empty editor for the first time in months, and the first twenty minutes are far rougher than your day job says they have any right to be.

If some version of that has already happened to you, nothing went wrong with you specifically. The job changed underneath everyone at roughly the same time, faster than anyone's prep habits could adjust, and it changed in a direction that happens to starve the exact skill most coding interviews grade hardest. The mechanism behind the rust is well documented in the learning research, it has nothing to do with talent, and keeping it in check doesn't take much if you start before a loop is on the calendar. So: what a review-heavy week trains, why it feels like more than it is, and a short weekly routine that keeps the other muscle warm.

Recognizing code and producing it are different muscles

When you review code (a teammate's PR, or the assistant's third attempt at the function you specced), the code already exists, and your job is to check it against what you know. Does it handle the empty case, is that boundary off by one, would you have structured it this way. That's recognition with judgment layered on top, and I don't want to undersell it, because it's a real skill and a hard one; being able to audit code you didn't write is arguably the defining skill of this stretch of the industry. But an interviewer handing you a problem and an empty editor is asking for something else entirely. Nothing exists yet to check. You have to pull the pattern out of memory, commit to an approach with nothing on screen to react to, and produce working code while narrating your reasoning. That's retrieval and generation, and the learning research treats it as a separate capacity from recognition rather than a harder setting of the same one.

The study I keep coming back to on this is Karpicke & Blunt (2011), published in Science, which found that retrieval practice (closing the material and forcing yourself to reproduce it) beat elaborative studying with concept mapping for long-term retention. The students doing the more comfortable, more reference-in-hand activity learned less, and durably so. Reviewing code is firmly on the comfortable side of that line. It rehearses judging what's in front of you, and it barely touches producing from nothing, which means a week with forty reviews in it can contribute almost nothing to the ability a coding interview is testing.

What a prompt-and-review week trains

Try a rough tally. Over your last normal work week, count how many times you evaluated code that already existed: diffs scanned, PRs reviewed, assistant output accepted, rejected, or edited. Then count how many times you produced a nontrivial piece of code from an empty file, with no reference open and nothing to react to. Among the engineers I talk to, the first number is routinely in the hundreds and the second is frequently zero, and the ratio got there without anyone choosing it. The tooling improved, the assistant took over the first draft, and the from-scratch generating evaporated out of the week one release at a time.

To be clear about what I'm not saying: none of the review time is wasted. Verification is increasingly the job, and some interview formats have begun grading it directly (I wrote about who allows what, and how to practice for those interviews, in the AI-assisted interviews article). But the interview formats are moving slower than the work changed, and as far as I can tell from candidate reports and the loops I'm still close to, the large majority of loops still include at least one interview that is you, a problem, and an editor with nothing in it. That interview doesn't award partial credit for how sharp your review instincts have gotten, and in the debriefs I've sat in, a slow and silent first fifteen minutes colors the writeup out of proportion to what it says about the candidate.

The fluency illusion means you won't feel the rust forming

The reason this catches people by surprise is a second, sneakier effect stacked on the first one. A review-heavy day is a fluency machine: nearly everything you read is finished, plausible, reasonably clean code, and it all parses easily. The learning literature has a name for what that ease does to your self-assessment, the fluency illusion: material that processes smoothly feels mastered, and the feeling is not reliable. It's the same trap as rereading a textbook chapter until it feels obvious and then blanking on the exam, except now the rereading is your full-time job. So your sense of how sharp you are drifts upward while the generation muscle idles, and nothing in the day job ever forces the two back into agreement.

Here's a cheap test to run this week: try to cold-write the thing you merged yesterday. Pick a function the assistant drafted and you reviewed, approved, and shipped. Close the tab, open an empty file, and reproduce the core of it from memory, or at minimum explain it out loud with no reference: the data structures, the edge cases it covers, the reason it survives empty input. If it flows, your retrieval is in better shape than this article is assuming, which is good news. If you find yourself reaching for the tab inside two minutes, which seems to be the usual outcome, you've just located the gap for free, at your desk, months before an interview would have located it for you.

The good news about rust

I spend a decent amount of my non-keyboard time gardening, and the most reassuring thing I know about rust comes from reclaiming beds. A bed you stop tending doesn't revert to bare dirt; it grows over. And clearing an overgrown bed turns out to be a completely different job from breaking new ground, because under the weeds the soil is already worked, the edges are already cut, and a weekend of weeding gets back most of what originally took seasons to build. Skills seem to behave the same way, at least every time I've watched someone come back from a rusty stretch. What you learned (the patterns, the triggers, the syntax that used to be automatic) doesn't leave; the path to it grows over. Nobody coming back from two years of review-heavy work has to relearn what a sliding window is. They need a handful of ugly warm-up sessions to clear the path, and session one is only that ugly once. So write the first couple of sessions off as weeding in advance, and grade them purely on whether they happened.

A weekly maintenance dose

Which brings me to the prescription, deliberately small, because the audience I have in mind is someone with a full-time job and no loop currently scheduled. The goal is preventative: keep the generation muscle warm enough that if an interview materializes, you're polishing rather than rebuilding. An hour or so a week covers it. The menu, cheapest first, and mixing week to week is encouraged:

One blind timed problem in a plain editor, narrated out loud. Thirty-five minutes, a problem you haven't seen, an editor with the assistant off (and ideally autocomplete too), and your voice going the whole time. The narration half matters as much as the code half (the full argument for why is in talking while coding), and the one habit I'd keep up is saying your triggers out loud, "sorted input makes me think of two pointers," the reflex I cataloged in the pattern trigger article. One of these a week maintains. It won't build new range, and it doesn't need to, because maintenance is the entire assignment.

Whiteboard a system from an engineering blog post. Pick a public writeup of a real system, run the design yourself first (timed, out loud, any whiteboard or a sheet of paper), and only then read their version and diff the two the way you'd review a pull request. This is the drill that comes with its own answer key, and the full solo routine around it lives in the solo system design article.

Re-explain yesterday's merged diff from memory. The self-test from earlier, run on a schedule. Ten minutes at your desk, tab closed, out loud: what the change does, how it does it, what breaks it. This one converts the day job itself into retrieval practice, which makes it the easiest to sustain, and it doubles as a check on how much of your own week you absorbed.

One real mock a week, once interviewing stops being hypothetical. The solo drills above cover structure and retrieval, and none of them pushes back in real time. When a loop is plausibly coming, add one full mock a week: a friend running a strict 45-minute interview while your phone records (free, and the mock-with-a-friend kit makes that session behave like a real interview), peer mocks on Pramp (which lives on Exponent these days), or, if you want something on demand that responds and probes, one system design mock a week is what we built Preppable around. I'd point review-heavy engineers at system design mocks specifically, because design is the discipline where solo practice is hardest to keep honest, and the explaining-under-pressure muscle it exercises transfers to every other interview in the loop.

The cheapest possible moment to start an hour-a-week habit is while no loop is on the calendar and the practice is free. The job really did change underneath all of us, reviewing well really is a skill worth being proud of, and neither of those facts changes what the empty editor will ask of you. A blind problem this week, narrated out loud to an empty room, will tell you where you stand, and whatever it tells you, you'll have months to do something about it instead of days.