In this article
Standards and mindset
What is the purpose of a code review?
A code review is a second person reading a change before it merges, so the team ships better code and shares knowledge. A Microsoft study found that finding defects is the main reason developers give, yet reviews turn out to be less about defects than expected and also bring knowledge transfer, team awareness and alternative solutions (Bacchelli and Bird, International Conference on Software Engineering (ICSE), 2013).
Why it is asked: it shows whether you see review as gatekeeping or as teamwork. Read more: the machine learning (ML) coding round.
What standard do you approve a change against?
Approve a change once it clearly improves the overall health of the code, even if it is not perfect. Google's published guide calls this the senior principle of review and says a change that improves the codebase should not be delayed for days or weeks because it is not perfect (Google review standard, October 2026). Reject changes that make code health worse.
Why it is asked: perfectionism slows teams, and interviewers listen for balance. Read more: the ML coding round.
How quickly should you respond to a review request?
Respond within one business day at most. Google's guidance says one business day is the maximum time to respond to a review request, and that you should review when you reach a natural break instead of interrupting focused work (Google review speed guidance, October 2026). A first response can be a question or a partial review; it does not have to be a full approval.
Why it is asked: slow reviews are a common source of team friction. Read more: how interview loops are structured.
What is a nit, and why label it?
A nit is a minor, optional comment on style or preference that should not block a change. Google's guide tells reviewers to prefix such points with "Nit:" so the author knows they can skip them, (Google review standard, October 2026). Its checklist adds that reviewers should not block a change only on personal style preferences (Google review checklist, October 2026).
Why it is asked: labelling shows you separate blockers from taste. Read more: coding interview preparation.
What to check
What do you look for when reviewing a change?
Check design, functionality, complexity, tests, naming, comments, style, consistency and documentation, in roughly that order. The Google guide's checklist covers these areas in this order, starting with design, meaning whether the pieces fit together and belong in this codebase (Google review checklist, October 2026). Leave style for last; a linter, a tool that flags style problems automatically, can check much of it.
Why it is asked: the order of your answer reveals your priorities. Read more: the ML coding round.
Text description of the diagram
- A review checks design, functionality, complexity, tests, naming and style.
- Approve once the change clearly improves the code.
How do you review a very large pull request?
A pull request is a proposed change submitted for review before it merges. For a very large one, ask the author to split it. Google's guide says about 100 lines is usually reasonable and about 1,000 lines is usually too large (Google small-change guidance, October 2026), and that a reviewer may reject a change for being too big. If it cannot be split, review the design first and the details in passes.
Why it is asked: reviewers are a limited resource and size drives quality. Read more: system design preparation.
How do you tell whether a change has enough tests?
Ask whether the tests would fail if the code broke. The guide asks reviewers to check that tests exist at the right level (unit, integration or end to end), that they are correct and useful, and that they would not start failing for no reason when the code changes (false positives) (Google review checklist, October 2026). A test that always passes gives false confidence.
Why it is asked: it separates reading code from reasoning about behaviour. Read more: coding interview preparation.
What makes code too complex?
Code is too complex when a reader cannot understand or safely change it quickly, or when it handles needs that do not exist yet. The Google guide treats both as complexity problems and warns against over-engineering for speculative future use (Google review checklist, October 2026). Suggest the simpler version and say what you would remove.
Why it is asked: it tests judgement about trade-offs, not taste. Read more: the ML coding round.
What should a good comment explain?
A good comment explains why the code does something, not what it does. The guide asks reviewers to check that comments are clear and necessary and to flag outdated ones, such as stale TODOs (Google review checklist, October 2026). If a comment is needed to explain what, the code usually needs a clearer name.
Why it is asked: it checks whether you can tell documentation from noise. Read more: coding interview preparation.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Reviewing code in the interview round
How do you review a messy pull request when you are given one live?
Read the description first, then state the intent in one sentence, then review in layers: correctness and security, tests, then readability. Say what you are doing out loud, because the interviewer is grading your process as much as the bugs. Rank findings as must fix, should fix and nit, and finish with an overall verdict.
Why it is asked: it mirrors daily work and shows how you prioritise under time. Read more: the ML coding round.
What bugs would you flag in this snippet?
def average_order(user_id, orders=[]):
cur.execute(f"SELECT total FROM orders WHERE user_id = {user_id}")
for row in cur.fetchall():
orders.append(row[0])
return sum(orders) / len(orders)Three problems. The query builds Structured Query Language (SQL) from a string, so a crafted user_id can inject SQL. The default list orders=[] is created once and shared by every call, so totals accumulate across calls. An empty result divides by zero. Fix with a parameterised query (one that sends the input separately from the SQL text, so it is never run as code), a None default and an explicit empty case.
Why it is asked: it tests whether you spot well-known traps quickly. Read more: coding interview preparation.
How do you explain a program you have never seen, such as a Monte Carlo estimate of pi?
Give the purpose first, then the inputs, the loop and the output. The program throws n uniform random points into the unit square; the fraction with estimates , so multiply it by 4. The standard error is with , which is (derivation), so each extra digit of accuracy costs about 100 times more points. Say that out loud before you read line by line.
Why it is asked: comprehension rounds test whether you can summarise intent before reading line by line.
Read the full explanation: how to estimate pi with a Monte Carlo simulation
How do you debug an unfamiliar codebase from an error log?
Start from the error, not the code: find the exception line (the last line of a Python traceback, the first line of a Java or JavaScript stack trace), then the innermost frame that belongs to your own code. Reproduce it with the smallest input, form one hypothesis, and check it with a print, a test or a debugger before changing anything. Fix the cause, add a test that fails without the fix, and say what else could produce the same log line.
Why it is asked: debugging rounds reward method over speed. Read more: the ML coding round.
What do you do when you do not understand the code you are reviewing?
Say so and ask. Read the tests and the call sites to infer intent, run the code if you can, and ask the author a specific question such as what should happen when the input is empty. Google's guide notes that if code is hard for the reviewer to understand, it will probably be hard for the next reader too, which is itself a finding (Google review checklist, October 2026).
Why it is asked: admitting uncertainty well is a senior trait. Read more: behavioural interview preparation.
Security and quality
How do you spot security problems in a review?
Look for untrusted input reaching a sensitive place: SQL strings, shell commands, file paths, deserialisation, and secrets in code. The Open Worldwide Application Security Project (OWASP) maintains a Code Review Guide as a free project for this purpose (OWASP, read October 2026). SQL injection is an attack in which input is interpreted as part of a database query; parameterised queries prevent it.
Why it is asked: reviewers are the last human check before production. Read more: system design preparation.
How do you review performance without premature optimisation?
Flag cost only where it scales with data: a query inside a loop, an unbounded list, repeated work on a hot path. Ask for a measurement before accepting a complicated speed-up. If the code runs once a day on a small table, readability wins; if it runs per request on a very large table, complexity may be justified, with a comment saying why.
Why it is asked: it tests whether you weigh cost against clarity. Read more: system design preparation.
Feedback and conflict
How do you give critical feedback to a senior engineer?
Comment on the code, ask questions where you are unsure, and give a reason with each request. Instead of "this is wrong", write "this loop calls the database per item; could we batch it?". Google's guide says disagreements should be resolved by discussion and escalation rather than letting a change stall because author and reviewer cannot agree (Google review standard, October 2026).
Why it is asked: it is a behavioural question in technical clothing. Read more: behavioural interview preparation.
What do you do when an author disagrees with your review comment?
Restate the concern with evidence, listen for context you lack, and decide whether it is a blocker or a preference. If it is a preference, concede or mark it a nit. If it is a defect, show a failing case. If you still disagree, escalate to a third reviewer or the code owner, and record the decision so the argument does not repeat.
Why it is asked: it shows how you resolve conflict without ego. Read more: behavioural interview preparation.
Reviewing AI-written code
What goes wrong with AI-generated code?
It can look correct and still be wrong, because a tool optimises for plausible code, not verified behaviour. A study of GitHub Copilot generated 1,689 programs across 89 scenarios tied to high-risk weakness types and found about 40% of them vulnerable (Pearce et al., arXiv 2108.09293, 2021). The study is from 2021, so current tools may differ; the review habit still applies.
Why it is asked: teams now review machine-written changes daily. Read more: the ML coding round.
How is reviewing AI-written code different from reviewing a colleague's?
Trust the intent less and verify the behaviour more. A colleague's change carries context you can ask about; a generated change may include unused code, invented function names, or a confident but wrong approach. Run it, read the tests it wrote with suspicion, and check every library call against the real documentation before approving.
Why it is asked: it tests whether you verify rather than trust output. Read more: coding interview preparation.
How would you correct what the machine got wrong?
Find the first wrong assumption, then fix it at the source: correct the code, add a test that captures the failure, and, if you are prompting a tool, restate the constraint it missed. Do not patch the symptom. Explain the fix in terms of the requirement it violated, so the interviewer hears reasoning, not only an edit.
Why it is asked: it separates people who steer tools from people who depend on them. Read more: the ML coding round.
Follow-up questions
How should I prepare for a code review interview?
Practise reading unfamiliar code aloud: state the intent, list the risks, and rank your findings. Review a few real public pull requests against the checklist in the Google guide, and write one comment of each kind: a blocker, a suggestion and a nit. Time yourself on a 20-line function.
Can I ask questions during a code review round?
Yes, and you should. Ask what the code is meant to do, how it is called and what the inputs look like, because a real reviewer would. Questions show you are checking intent before judging details.
What if I cannot find any bugs?
Say what you checked, then comment on risk instead: missing tests, unclear names, an edge case that is unhandled. An honest "I found no defects in these areas, and these are the risks" is stronger than inventing a problem.
- A review is for code health and shared knowledge, and approval means the change clearly improves the code.
- Check design and behaviour first, then tests, then names and style.
- Label optional points as nits and rank everything else by severity.
- Keep changes small: about 100 lines is reasonable and about 1,000 is usually too large.
- Treat AI-written code as untrusted until you have run it and checked its calls against documentation.
Sources
- The Standard of Code Review (Google Engineering Practices) — Google, 24 Oct 2026
- What to look for in a code review (Google Engineering Practices) — Google, 24 Oct 2026
- Speed of Code Reviews (Google Engineering Practices) — Google, 24 Oct 2026
- Small CLs (Google Engineering Practices) — Google, 24 Oct 2026
- Expectations, Outcomes, and Challenges of Modern Code Review — Microsoft Research (Bacchelli and Bird, International Conference on Software Engineering 2013), 1 May 2013
- Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (arXiv 2108.09293) — arXiv (Pearce et al.), 20 Aug 2021
- OWASP Code Review Guide — OWASP Foundation, 24 Oct 2026
