Code Review Interviews

How To Review Code In Interviews

A practical checklist for reviewing interview code: correctness, edge cases, readability, complexity, maintainability, and testing.

Code ReviewInterview StrategyDebuggingMaintainability

The Main Idea

In a code review interview, your job is not only to say whether the code compiles. Your job is to read unfamiliar code, identify risk, explain the impact, and suggest practical improvements.

A strong review sounds like this: “This may work for the happy path, but I am worried about null input, shared mutable state, and whether this behavior is covered by tests.”

A Simple Review Checklist

Correctness

Does the code return the right result? Are there obvious logic bugs?

Edge Cases

What happens for null, empty input, duplicates, negative values, or very large input?

Complexity

Is the code accidentally O(n²)? Is there a simpler data structure?

Readability

Are names clear? Is the control flow easy to follow? Is the code doing too much?

Maintainability

Would this be easy to change later? Are there magic numbers or hidden assumptions?

Testing

What tests would prove this works? What failure cases should be covered?

Example Review Prompt

Suppose an interviewer shows you this Python code:

python
def add_user(user, users=[]):
    users.append(user)
    return users

A beginner answer might only say that the function is short and readable.

A stronger review catches the hidden bug: the default list is shared across calls.

python
print(add_user("A"))  # ['A']
print(add_user("B"))  # ['A', 'B'] unexpected

How To Speak During The Interview

Start broad, then get specific. Do not immediately nitpick spacing or minor style choices. First talk about correctness, failure modes, and whether the code is safe to maintain.

Useful phrase: “I would review this in layers: first correctness, then edge cases, then readability and maintainability.”

Good Things To Mention

  • What the code is trying to do.
  • The highest-risk correctness issue.
  • One or two edge cases.
  • Whether the data structure choice is reasonable.
  • How you would simplify the code.
  • What tests you would add.

What Not To Do

  • Do not only comment on formatting.
  • Do not rewrite everything just because it is not your style.
  • Do not ignore edge cases.
  • Do not say “looks good” without explaining what you checked.

Final Takeaway

In code review interviews, the goal is to show engineering judgment: identify the real risks, explain why they matter, and suggest a clean fix without overcomplicating the code.