In this article
Before you start
This page is one part of the interview process guide: stages, rounds and who scores what.
Why interviewers ask this
A manager who cannot read unfamiliar code cannot judge a design, a review thread or an estimate, so a technical round tests that skill directly. Hello Interview's Google manager guide says "Code review is the standard technical round for EM candidates, and for many loops it's the only one." As of October 2026, Meta is reported to be piloting an AI-enabled coding round that many recent software engineer and EM candidates say they received (IGotAnOffer, Meta EM guide). Reading-and-debugging exercises are also reported by candidates in AI-lab loops; see OpenAI interview questions and process. The sources below are candidate and coach reports, not employer pages, so confirm the format with your recruiter.
A weak answer lists nitpicks or rewrites the code. A strong answer finds real defects and fixes them. A Staff answer also ranks the defects, ties each fix to a test and says whether the change should ship.
Code review round from first principles
- Code review round
- A code review round is an interview round in which the candidate reads code that someone else wrote, finds the defects, proposes fixes, and explains how the change could be better, the way a reviewer treats a teammate's submitted change, to test engineering judgment rather than puzzle speed.
- Changelist
- A changelist (CL) is one self-contained change to a code base that is put forward for review, equal to what many platforms call a pull request. Google's published review guidance uses the term throughout, so a candidate who hears it should read it as the unit of change being reviewed.
In plain words
Think of an editor checking a colleague's article before it is printed. The editor asks what the article is for. Then they read for mistakes that would embarrass the paper and mark the worst first. Last, they say whether it can run. A code review round has the same shape, with code in place of an article.
The analogy breaks in one place. An editor can polish forever, but a code reviewer is expected to say when a change is good enough. Google's review standard tells reviewers to favor approval once a change definitely improves the health of the code, even if it is imperfect.
In one precise sentence: a code review round tests whether you can find real defects in unfamiliar code, order them by severity, fix the worst, and judge when the change is ready to ship.
Step 1: Orient before you read the code
Orient by reading the description and the tests first. Input: a change you did not write. Output: one sentence on what it should do, and the part that matters most. Google's navigation guidance tells reviewers to read the description, ask whether the change makes sense, look at the most important part first, and ask the author where to start if the change is too large. It also says reading the tests first shows what the change is meant to do.
That guidance is written for real reviews, so use it here as a method, not as proof of any interview format. At Meta, candidates are reported to get a multi-file code base they did not write, and understanding it quickly is a large part of the challenge. You now have a purpose to check the code against; the next step is the reading itself.
Step 2: Find the defects and rank them by severity
Find the defects and rank them by severity. In review, severity is how much damage a defect does if it ships. Input: the main part of the change. Output: a short list, worst first.
Google's guidance says "The most important thing to cover in a review is the overall design of the CL." It then asks reviewers to think about edge cases, concurrency problems and bugs visible just by reading, and to question complexity the change does not need. Typical seeded defects, used here as illustration, are off-by-one errors, wrong conditionals and unsafe type casts.
A workable order: crashes and data loss first, wrong results at boundaries next, rare inputs and polish last. Say the ranking aloud. The interviewer then hears your priorities, not just a pile of findings.
Step 3: Fix the worst defect and name the test
Fix the worst defect with the smallest change and name the test that catches it. Input: one ranked defect. Output: a patch and a test case that fails before and passes after. Google's guidance asks reviewers to request tests of the right kind for the change (Google, what to look for).
Here is a tiny seeded bug. The loop stops one window early:
def window_sums(xs, k):
# bug: range stops one window early
return [sum(xs[i:i + k]) for i in range(len(xs) - k)]On [1, 2, 3, 4, 5] with k = 2 it returns [3, 5, 7], but four windows exist, so the right result is [3, 5, 7, 9].1 The fix is range(len(xs) - k + 1), and the test is "five items, window of two, expect four sums". One candidate reported a Google Doc with no integrated development environment (IDE) and no AI tools (Aced), so practice tracing tests by hand.
Step 4: Give a verdict, not just a list
End by saying whether the change should ship. Input: your ranked findings and fixes. Output: one verdict and what you would leave for later. Google's standard is to approve once a change definitely improves overall code health, and it states that perfect code does not exist, only better code (Google, the standard of code review).
So a strong close sounds like: "With these two fixes this improves the code; I would approve, and I would leave the naming and a possible refactor for a follow-up." Google's guidance also warns against solving problems the author only speculates might appear later. A verdict turns your list into a decision, which is what a manager does all week.
Step-by-step description
- Read the description and the tests first.
- List defects, worst first.
- Smallest fix, plus the test that catches it.
- Say whether the change should ship.
- Orient by reading the description and the tests first.
- Find the defects and rank them by severity.
- Fix the worst defect with the smallest change and name the test.
- End by saying whether the change should ship.
Worked example: four seeded bugs in about 200 lines
Take an illustrative snippet of 200 lines with four seeded bugs, in line with the more than 200 lines one Google candidate reported. That is one bug per 50 lines.1 IGotAnOffer reports five or six 45-minute interviews in a Google loop, so the plan below assumes an illustrative 45-minute round: 3 minutes to orient, 14 to read and flag, 14 to fix, 9 for test cases and 5 for the verdict.1 Reading and flagging takes 14 of the 45 minutes, about 31% of the round, and fixing takes the same share. Reading 200 lines in 14 minutes is about 14.3 lines a minute, so skim for structure first.1
| Seeded bug | Severity (illustrative) | Test that catches it |
|---|---|---|
| Missing null check on a lookup result | Highest: crashes in production | Look up a key that is absent |
| Wrong conditional at a limit | High: wrong result at the boundary | Input exactly at the limit |
| Off-by-one in a loop range | Medium: drops the last window | Five items, window two, expect four sums |
| Unsafe type cast | Lower: fails only on rare input | Pass a value of the wrong type |
Text description of the diagram
- Reading and flagging defects takes 14 of the 45 minutes.
- Fixing takes 14 minutes and test cases take 9 minutes.
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 →The Staff-level answer
Here is a change a team member submitted. Find the bugs, fix them and tell me how you would improve it.
First I read the description and the tests to learn what the change should do, and I ask whether it makes sense at all. Then I read the main part once and list defects by severity: crashes first, wrong results next, rare cases last. I fix the worst ones with the smallest change and say the test that would have caught each. Then I give a verdict: it improves the code, so I would approve after those fixes, and I would leave style and speculative generality for a follow-up. If I had more time, I would ask what the change must handle at scale.
What makes it Staff-level: it ranks the defects, ties every fix to a test, and ends with a verdict instead of a list.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Orientation | Starts reading line one with no purpose | Reads the description and tests, states what the change should do | Also asks where to start in a large change and what is out of scope |
| Defect finding | Reports style nits and misses a crash | Finds the real bugs by reading | Finds bugs and questions the design and needless complexity |
| Fixes and tests | Rewrites large parts in their own style | Makes small fixes that work | Ties each fix to a test that fails before and passes after |
| Verdict | Gives no decision | Says whether the change is good | Approves or blocks with reasons and defers the rest |
| Communication | Silent or defensive | Explains while working | Names priorities aloud and invites the interviewer's view |
Three variants of this question
Here's a frontend feature — how would you navigate this feature on a new code base?
Start with what the feature does for a user, then find its entry point and the tests, and ask the interviewer where to begin if the code is large. This unattributed variant is reported with the interviewer sharing a screen while you direct them; the method follows Google's navigation guidance, used here as an analogy, not as proof of the format.
Do engineering managers have to do LeetCode?
Often less than engineers do: at Google, code review is reported as the default technical round for L6 EM candidates, a coding phone screen is "increasingly skipped for EM candidates", and L7+ candidates reportedly get no code review round (Hello Interview; IGotAnOffer). Reports also say the coding questions for managers tend to skew more basic than those for senior individual contributors, and no employer states a difficulty bar; ask your recruiter whether a classic coding round applies at Meta.
How does Meta's AI-enabled coding round work for a manager?
Candidates describe about 60 minutes on one multi-part problem, in three phases: bug fixing, core implementation and optimization with larger inputs. As of October 2026 the format is described as a pilot and may change, so read Meta engineering manager interview: rounds and how to prepare and what an AI-assisted coding interview is.
Common mistakes
- "Managers never code in interviews." (wrong) Meta reportedly includes EMs in its AI-enabled round and Google reportedly runs a code review round. (right) "I will ask the recruiter which technical round applies to my loop and level."
- "I will comment on every style nit." (wrong) Google's guidance puts overall design first. (right) "I check design and correctness first and mention style last."
- "I will rewrite it my way." (wrong) The reviewer's job is to improve the code, not to replace it. (right) "I make the smallest fix that removes the defect."
- "I must finish all three phases." (wrong) Candidates report offers without finishing the last phase. (right) "I verify each phase before I start the next."
- "The AI assistant will find the bug, so I will accept its output." (wrong) Assistant output can contain bugs too. (right) "I read the suggested change and run a test before I keep it."
Follow-up questions
How long is a code review round?
IGotAnOffer states that the code review interview, like a regular coding interview, will last up to 45 minutes, and Meta's AI-enabled round is described as about 60 minutes. One Google candidate reported more than 200 lines of code, so budget time to read before you fix.
Should I comment on style in a code review interview?
Mention it last. Google's guidance puts overall design first, then correctness, complexity and tests, so spend your time there before any nit.
Do I need to finish every phase in Meta's AI-enabled coding round?
No. Hello Interview's report says "Not completing all phases is perfectly fine." It also says candidates who missed the last phase reportedly still received offers, so correctness and clear reasoning matter more than speed.
What if the recruiter offers a choice between coding and code review?
Ask which track the loop uses, because reports say some loops still offer a choice and others do not (Hello Interview; IGotAnOffer). If you choose, pick the one where you can reason aloud most clearly.
Can I use an AI assistant in a manager coding round?
Only where the format provides one. Meta's AI-enabled round is described as giving candidates an assistant, while the Google round one candidate described had none. Follow the rules the recruiter states, and see how AI-assisted coding interviews are graded. The Google loop described above also holds two system design rounds; see system design for managers.
- A coding interview for engineering managers is reported as code review at Google and AI-enabled coding at Meta; confirm your loop with the recruiter.
- Orient first: read the description and tests, then the most important part.
- Rank defects by severity, fix the worst with the smallest change, and name the test for each.
- End with a verdict: approve once the change improves the code, and defer the rest.
- Difficulty is reported as more basic than senior engineer rounds, but no employer states a bar.
Sources
- The Standard of Code Review — Google Engineering Practices documentation (accessed), 26 Oct 2026
- What to look for in a code review — Google Engineering Practices documentation (accessed), 26 Oct 2026
- Navigating a CL in review — Google Engineering Practices documentation (accessed), 26 Oct 2026
- Meta's AI-Enabled Coding Interview: How to Prepare — Hello Interview (accessed), 26 Oct 2026
- Meta Engineering Manager Interview — IGotAnOffer (accessed), 26 Oct 2026
- Google engineering manager interview guide — Hello Interview (accessed), 26 Oct 2026
- Google engineering manager interview — IGotAnOffer (accessed), 26 Oct 2026
- How to ace a code review interview — Aced, formerly Exponent (accessed), 26 Oct 2026
