Code review interview: how to review code out loud

What to look for, in priority order

1. Intent: what is this change supposed to do, and does it?
2. Correctness: logic errors, off-by-one errors, null and empty cases, error handling.
3. Security: injection, unsafe input handling, secrets in code, authorisation checks.
4. Concurrency and state: races, shared mutable state, transaction boundaries.
5. Performance: N+1 queries, unnecessary work in loops, unbounded memory.
6. Tests: are the important paths and edge cases covered?
7. Readability: naming, structure, duplication, comments that explain why.

How to run the review

Read the description or ask what the change is for. Skim the whole diff once to understand its shape, then read carefully. Narrate as you go: “This function fetches orders for each user inside the loop — that's a query per user.” At the end, summarise: the one or two issues that block merging, a few that should be fixed, and optional suggestions. Interviewers weigh this prioritisation heavily; twenty style nits with a missed security bug is a poor review.

Severity labels

A worked example

A function receives a username from a request, builds a SQL string by concatenating it, runs the query, loops over results calling another query for each user's orders, and returns a list. Review: blocking — SQL injection; use parameterised queries. Should fix — N+1 queries in the loop; fetch orders in one query with a join or IN clause. Should fix — no handling when the user doesn't exist; it currently throws on an empty result. Suggestion — the function both queries and formats; separate data access from presentation. Question — is pagination needed if a user has thousands of orders? Then: “Overall the logic is clear; the injection issue blocks merging, and the rest are straightforward.”

Tone matters

• Comment on the code, not the person: “this query” rather than “you forgot”.
• Explain why, so the comment teaches: “parameterising prevents injection when usernames contain quotes.”
• Offer a concrete alternative where you can.
• Ask questions when you lack context instead of asserting.
• Acknowledge what's good — it tells the interviewer you can tell the difference.

When the code looks fine

Sometimes the snippet is genuinely decent, and candidates panic and invent problems. Don't. Say that the logic looks correct, explain what you checked to reach that conclusion, and move to the second tier: tests that are missing, an edge case worth documenting, an error message that could be clearer, a name that could be more precise. Then ask about context that might change your view — expected data size, who calls this, how failures are monitored. Interviewers sometimes use clean code deliberately to see whether a candidate can tell good from bad, and a calm, accurate “this is solid, here's what I'd add” is the right answer.

Variants you might meet

Some companies show you their own past code with planted bugs; some give you code generated by an AI assistant and ask you to judge whether it's production-ready, which overlaps with AI-assisted coding interviews; senior loops may replace a whiteboard round with a code review of a realistic pull request. Our hiring-side guide to testing coding skills without LeetCode explains why employers like the format.

Practising

Review open pull requests on open-source projects in your language — read the diff, write your review, then compare with the maintainers' comments. Do it out loud with a timer. A free AI interview assistant such as CoPilot Interview can play the author in a mock interview and push back on your comments, which is good practice for the discussion that follows a review.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.

Frequently asked questions

What is a code review interview?

A round where you review a pull request or code snippet as you would a colleague's, and are assessed on what you notice, how you prioritise findings and how you communicate them.

What should I look for in a code review interview?

Intent and correctness first, then security, concurrency, performance, tests and readability. Rank issues by severity and make sure blocking problems aren't buried under style comments.

How long is a code review interview?

Usually 30 to 60 minutes: a few minutes to understand the change, most of the time reviewing aloud, and a discussion at the end.

Is a code review interview easier than a coding interview?

It's different rather than easier. It rewards real-world experience — spotting security and performance issues and communicating well — more than algorithm practice.