How to Explain Decisions in a PR During a Code Review Interview

The problem

A lot of people enter code review interviews thinking they need to prove they are sharp.

Then two bad behaviors appear:

• hunting for any detail just to show volume
• giving opinions in the tone of a final verdict

That usually sounds worse, not better.

Because mature review is not a collection of hot takes.

It is risk reading with useful communication.

Mental model

A good code review comment usually answers three questions:

1. what worries me here?
2. why does that matter?
3. what would I do instead?

If you want the shortest version:

In review, the quality of the reasoning matters more than the number of comments.

You are not there to perform severity.

You are there to show judgment.

Breaking the problem down

First distinguish the type of comment

Not everything carries the same weight.

Some observations are:

• probable bug
• future behavior risk
• readability problem
• style preference

Mixing everything in the same tone weakens the review.

If preference and bug sound equally important, the interviewer loses the signal about your prioritization.

Then explain impact

Saying “this is wrong” helps very little.

It is better to say something like:

• this may break when the list comes back empty
• this duplicates logic and makes maintenance harder
• this creates risk of redundant calls

Clear impact makes the comment sound technical and useful.

Propose a viable direction

You do not always need to write the whole solution.

But it helps to point to a direction:

• move validation closer to the input
• separate responsibility
• avoid side effects inside render
• cover the edge case with a test

That shows you do not only detect the problem.

You help solve it.

Prioritize before detailing

In a live review, it is usually better to talk first about the most serious points.

Something like:

• one functional problem
• one maintenance risk
• one smaller optional detail

That order usually sounds more mature than dumping observations in the random order you read them.

Simple example

Imagine a PR where:

• the function performs a fetch without handling error
• it mixes data transformation with render
• it has a bad variable name

A weak review may spend too much time on the variable name.

A good review would probably start like this:

1. “My main concern is that there is no error handling here, and that can leave the screen in an inconsistent state.”
2. “I also noticed the transformation is coupled to render, which tends to make testing and maintenance harder.”
3. “Finally, I might rename this variable to make the intent clearer.”

Notice the difference:

it is not only pointing.

It is ranking.

Common mistakes

• Giving the same weight to a serious bug and a personal preference.
• Commenting a lot and prioritizing little.
• Sounding aggressive or absolute instead of collaborative.
• Pointing out the problem without explaining impact.
• Talking only about style when there is a more important functional risk first.

How a senior thinks

People who review well usually read with questions like:

• can this break behavior?
• can this create future cost?
• is this important now or only a preference?
• which comment actually improves the PR?

That filter makes a huge difference.

Seniority in review is not finding more defects.

It is finding the right defect, explaining it well, and keeping the conversation useful.

What the interviewer wants to see

They want to see whether you:

• know how to prioritize observations
• distinguish real risk from personal taste
• communicate impact clearly
• keep a collaborative tone

If your comments sound like “this point worries me because of this, I would suggest that,” you are already showing the kind of review that helps a real team.

Strong code review is not the sharpest one. It is the most useful one.

In interviews, your collaborative tone says as much about you as the technical quality of the observation.