The Code Review Round: Finding Bugs in Someone Else’s Code

Why companies use this round

Reading code is most of the job. Engineers spend far more time understanding what exists than producing something new, and this round tests that directly in a way a blank editor never can.

It also scales down well. In twenty minutes with a prepared snippet an interviewer learns whether you notice a race condition, whether you can tell a real problem from a style preference, and how you deliver criticism — which matters, because you will be reviewing colleagues next month.

Look in this order

Correctness first. Does it do what it claims for every input, not just the example? Off-by-one, empty collection, null, the boundary at zero.

Then failure paths. What happens when a dependency breaks — the network call times out, the file is missing, the parse fails. Swallowed exceptions and empty catch blocks live here, and they are the most commonly planted bug.

Then concurrency and resources. Check-then-act patterns, shared mutable state, connections opened but not released on the error path. An early return that skips a close is a classic, precisely because it looks harmless.

Then performance, where it matters. A query inside a loop is a real finding. A slightly inefficient concatenation over five elements is noise.

Style last, and briefly. Naming and formatting are worth one sentence, not five. Leading with them tells the interviewer you did not find anything real.

The trap: stopping at the first bug

Interviewers usually plant several problems at different depths. There is an obvious one near the top — a missing null check, visible in ten seconds — and it exists to see what you do after you find it.

Candidates who announce it and stop have answered a different question than the one asked. Candidates who note it and keep reading find the resource leak forty lines down, which is the one the round was built around.

Say the shallow one quickly and move on: “Missing null check on line four, easy fix. Let me keep going before I suggest changes.”

How you say it is graded too

This round doubles as a test of how you give feedback, because the code was written by a hypothetical colleague and the interviewer is imagining you saying this to a real one.

Two habits read well. Separate severity — say plainly which findings block a merge and which are preferences, because a reviewer who treats everything as equally urgent is exhausting to work with. And describe the failure, not the author: “this returns stale data when two requests arrive together” rather than “this is wrong”.

If you would ask the author a question rather than assert a bug, say so. “I would ask whether this is ever called concurrently — if it is, this counter is not safe.” That is what a real review comment looks like.

The bugs that get planted most

A short list worth knowing, because the same handful recur across companies.

The swallowed error. A catch block that logs nothing and continues, so the failure becomes invisible downstream instead of loud at the source.

The leaked resource. Something opened at the top, closed at the bottom, and an early return in the middle that skips the close entirely.

The check-then-act race. Read a value, decide based on it, write it back — correct alone, wrong the moment two callers arrive together.

The mutable default or shared cache key. State that persists between calls when it was meant to be per-call, which produces bugs that only appear under load.

When the code is fine

Occasionally the snippet is mostly correct, and the round is testing whether you invent problems to look thorough. Inventing them is the failure.

The right answer is to say what you checked and found clean, then name what you would want before approving: “Logic holds for the cases I can see. I would want to know how it behaves when the upstream call fails, and I would add a test for empty input — but I would not block on anything here.”

That answer demonstrates a review process. Three invented nitpicks demonstrate the opposite.

Where a copilot fits

Interview Copilot follows the round in real time and puts a structure on your screen while the other person is still talking — what the question is actually asking, the constraint that matters, and the trade-off worth saying out loud. Not a script to read: a scaffold you speak from, in your own words.

Read next