Reviewing Someone Else's Code Live Without Sounding Pedantic

The problem

Reviewing someone else’s code live is a format that knocks a lot of people down for one simple reason:

it feels like the goal is to prove superiority.

When someone enters with that mindset, they start to:

• point out too many details
• use an absolute tone
• criticize without understanding intent
• confuse preference with error

That reduces the signal of the interview.

Mental model

Good review is not a parade of opinions.

It is risk reading with useful communication.

The evaluator wants to see whether you can look at a code snippet and answer:

• what is this code trying to do?
• where is the biggest risk?
• what would I comment on first?
• how would I say it without creating unnecessary friction?

If you want the shortest version:

In live review, technical judgment without collaborative tact usually looks like immaturity.

Breaking the problem down

Understand intent before giving an opinion

Before saying something is bad, it helps to understand:

• which problem the code solves
• which path it chose
• which assumption seems to sit behind it

Sometimes the problem is not the technique itself.

It is how that technique fits the context.

Separate the category of the comment

Not every comment has the same weight.

A simple split helps:

• bug or incorrect behavior
• maintenance risk
• performance risk
• clarity and readability
• style preference

That already improves prioritization a lot.

Comment through impact

Instead of saying “this is bad,” say something more useful:

• what worries you
• why that matters
• what you would do instead

That format shows reasoning.

Avoid unnecessary absolutism

Very rigid phrases usually sound bad.

It is better to say something like:

• “here I would be concerned about…”
• “this path may create…”
• “I would consider…”

That is not weakness.

It is precision.

Simple example

Imagine code that makes a database query inside a loop.

Bad comment:

• “this is terrible”

Better comment:

• “here I would be concerned about N+1, because each item in the loop triggers another query. If the list grows, this part may degrade a lot. I would try to fetch that data in one go or reorganize the read path.”

The second comment shows:

• that you identified the problem
• that you understood the impact
• that you can suggest a direction

Common mistakes

• Fixing style before looking at behavior.
• Wanting to comment on everything instead of prioritizing.
• Assuming context the code did not show.
• Using a teacher-like tone.
• Criticizing without suggesting a viable alternative.

How a senior thinks

People with more maturity tend to review code like risk triage.

The internal checklist looks more like:

• where is the biggest potential damage?
• what affects correctness, cost, or maintenance the most?
• what matters now and what can become a follow-up?
• how can I say this in a way the other person can actually use?

That posture creates less noise and more value.

What the interviewer wants to see

They want to see whether you:

• understand the goal before criticizing
• prioritize relevant risks
• distinguish technical fact from preference
• comment with context and a proposal
• can sound collaborative without losing firmness

Good live review does not sound like a sermon.

It sounds like organized technical reading.

A strong comment does not perform severity. It reduces uncertainty about risk and direction.

In live review, clarity and prioritization matter more than the volume of remarks.