The candidate had thirty minutes and a 180-line pull request. Sixty seconds in, they said: "Line 43, this variable should be camelCase." I wrote it down. Not because they were wrong. Because it was the only thing they said for the next nine minutes. That is the code review interview: no blank editor, no "invert this tree," just a real-looking PR with real problems buried in it. I switched to it three years ago and I have never gone back. It separates people faster than any algorithm question I've ever asked, and it does it on the exact skill the job actually requires. TL;DR A code review interview hands you a pull request with seeded defects and asks you to review it out loud, like a teammate would on a Tuesday. It scores severity ranking, not defect count. Three issues ranked correctly beats six issues thrown out in random order. The bugs candidates miss most are the boring ones: deploy-order hazards, missing tests for the new branch, and rate limits that never reset. Strong candidates ask what the PR is for before reading a single line. Weak ones start at line 1 and go down. The failure mode isn't missing a bug. It's spending your best minutes on formatting nits an autoformatter would have caught. What is a code review interview? A code review interview gives you an existing pull request and asks you to review it as if a coworker opened it. You read, you narrate, you ask questions, you decide what blocks the merge. Nobody writes new code. Mine is always the same shape: a PR that adds a "resend verification email" endpoint to a service you've never seen. There's a route handler, a small service class, one migration, and two tests that pass. It looks fine. It compiles. CI is green. There are six things wrong with it. What bugs are seeded in the PR? Here they are, ordered by how much damage they'd do in production, which is the reverse of the order candidates usually find them. 1. User enumeration. The endpoint returns 404 no such account for unknown emails and 200 sent for real ones. Anyone with a wordlist can now inventory your users. Two candidates out of many have ever named this unprompted. It's the highest-severity thing in the file. 2. The email address is user-controlled and unthrottled. You can point the endpoint at any address and loop it. Congratulations, your transactional domain is now a spam cannon, and your sending reputation is somebody else's problem by Thursday. 3. The rate limiter that never resets. There is a limiter. It stores lastAttemptAt and compares against a window, but it rewrites the timestamp on every request including the rejected ones. So the window slides forever and a locked-out user stays locked out. This one is my favorite, because it's the difference between reading code and running code in your head. Everyone sees the limiter. Almost nobody traces the second request through it. 4. The migration drops a column in the same deploy. The old code still reads verification_token; the migration removes it; the PR removes the reads. If those don't land in that exact order — and they won't, because instances roll one at a time — you get a few minutes of 500s. Backend candidates who've actually shipped catch this. Nobody else does. 5. An N+1 inside the loop. Real, bounded, worth a comment, not worth blocking on. It's there specifically to see whether you call it a blocker. If you do, I learn something about your judgment. 6. A leftover console.log and one inconsistent name. Bait. Pure bait. Both would be caught by a linter that this fictional repo obviously doesn't have. What do interviewers actually score in a code review interview? Severity ranking, first and mostly. I'm not counting how many issues you find. I'm watching what you reach for when you have limited attention, because that is precisely the constraint you're under in a real review with fourteen PRs in the queue. The second thing I score is whether you ask what the PR is for. Candidates who open with "what's the ticket, and is this user-facing?" are already ahead, because half the defects only look like defects once you know the endpoint is public and unauthenticated. I'll answer honestly if you ask. I will not volunteer it. Third: how you write the comment. I ask people to say the comment out loud. "This is wrong" and "if a rejected request also rewrites the timestamp, a user who hits the limit once can never get back in — want me to pull up the test?" are the same finding and completely different colleagues. One of those people I want reviewing my code at 6pm on a release day. Fourth, quietly: what you don't say. Not commenting on the naming nit at all is a small point in your favor. Spending four minutes on it is the single most common way people fail this round. Why does the code review interview beat a LeetCode question? Because it tests the job. The median engineer writes new code some of the time and reads other people's code most of the time. A code review interview measures reading under time pressure, risk judgment, and how you deliver bad news to a peer. A binary tree question measures whether you saw a binary tree question last week. It's also much harder to fake. There is no memorized pattern for "notice that this migration can't survive a rolling deploy." You either have production scars or you don't, and forty minutes of conversation makes that obvious in a way a solved problem never does. And honestly, it's kinder. Candidates leave this round having had an actual technical conversation instead of performing under a stopwatch. I've had people fail and still email to ask what the sixth bug was. How do you practice for a code review interview? Review PRs you didn't write, out loud, with a timer. Open any active open-source repo, pick a merged PR from six months ago, and give yourself fifteen minutes to say what you'd block on before reading the comments. Then read the comments. The gap between your list and the maintainer's list is your entire study plan. The part that catches people isn't the finding, it's the narrating. Talking through technical reasoning while someone silently takes notes is a distinct skill, and most of us only practice it during interviews. I ended up building a tool for that — full disclosure, it's mine: Preterview runs voice mock interviews with three different interviewer personalities, scores your resume and portfolio, and hands you a written report on how you actually sounded. I built it because I kept watching strong engineers lose rounds they'd have passed on paper. What separates senior candidates in this round? They triage before they read. They say things like "let me look at the migration first, since that's the only thing here I can't roll back." They ask about deploy topology. They distinguish between "this is a bug" and "this is a bug that matters." And when they're unsure, they say so out loud instead of hedging into vagueness: "I think this limiter is broken but I'd want to write a test before I claimed that in a comment." Junior candidates read top to bottom, comment on everything with equal weight, and treat the PR as a spot-the-difference puzzle. Which is a completely reasonable thing to do if nobody ever told you the game had a scoring function. Now somebody has. So what is a code review interview really scoring? Not your ability to find bugs. It's scoring your judgment about which bugs deserve your attention, whether you gather context before forming an opinion, and whether the comment you write makes your teammate better or just makes you feel correct. Find three issues and rank them right and you'll beat the candidate who found all six and led with the camelCase.