The toxic code reviewer

"Your strongest engineer leaves code review comments that are technically correct and demoralising. Two juniors have told you privately that they dread putting up a PR. Handle it."

What the question is actually testing

Not conflict aversion. Interviewers already know you will say "I'd have a conversation with them". The three things being scored are:

Whether you protect the standard while changing the delivery. A weak answer either defends the engineer ("they're right about the code") or sacrifices the bar ("I'd ask them to be nicer"), and both are wrong. The standard is not the problem; the delivery is.
Whether you fix the system as well as the person. A team where one person's review style can demoralise two others has a review culture problem, not just a Dave problem. A lead who only has the individual conversation has solved this instance and none of the next ones.
Whether you can be specific. "I'd give them feedback" is a non-answer. "I'd pull three comments from last week's PRs and read the wording back to them" is an answer.

Structure every role-play like this one as first move, information I would gather, line I would not cross. That three-part shape is what turns a vague answer concrete, and it is worth saying explicitly as you begin.

The answer

First move: read the actual comments

Before any conversation, spend twenty minutes in the PR history. Pull five to ten real comments from the last two weeks. This is not optional and it changes the conversation completely, because you move from "some people feel bad" (which any engineer can dismiss as feelings) to "here are four comments, and here is what each one does to the author".

You are sorting them into three piles:

Correct and well delivered. These are the ones you will praise, and you need them, because a conversation that contains only criticism gets heard as an attack on the standard.
Correct and badly delivered. "This is wrong." "Did you even run this?" "We don't do it that way." These are the target.
Not actually correct, or a matter of taste presented as a defect. These are the most damaging, because the author cannot tell them apart from the real findings, so they must treat every comment as blocking.

Also measure two things. Review latency: if their reviews arrive three days late, the harshness is landing on top of a delay, and the delay may be the larger problem. Rework: what fraction of their comments cause a change versus an argument. A reviewer whose comments cause change is effective; one whose comments cause debate is expensive.

Then: the private conversation, in SBI

Situation, Behaviour, Impact. Specific, timely, behavioural, and delivered as one conversation rather than dropped into a 1:1 alongside six other topics.

"On the payments PR on Tuesday, you commented 'this is obviously broken, did you test it at all'. You were right that the null case was unhandled. What happened next is that Priya spent two days rewriting a working implementation because she wasn't sure which parts of your review were blocking. That's the impact I want to change. Your technical judgment here is the best on the team and I am not asking you to lower the bar. I'm asking you to spend the extra ten seconds that makes the same finding actionable."

Then make the ask concrete rather than emotional, because "be kinder" is not something an engineer can act on:

Say what is blocking and what is not, explicitly, on every comment.
State the finding, not a judgment of the author. "This drops the null case at line 40, which will NPE for guest checkout" rather than "did you test this".
Where you would reject, offer the shape of the fix. A review that only closes doors costs the author a full design cycle.
Anything under two lines of disagreement: pick up the phone. Text is a bad medium for taste disputes, and a five-minute call resolves what a twelve-comment thread does not.

Then listen, because there is frequently a real grievance underneath. The two most common: "I am the only one who reviews carefully and I am tired" (a load problem you own), and "this code genuinely is not good enough and nobody backs me up" (a standards problem you own). If either is true, you have a second piece of work, and pretending otherwise makes the first conversation feel like a setup.

Then: change the system, without naming anyone

This is the part that separates a lead answer from an individual-contributor answer. Introduce these as team norms, in a team meeting, framed as improving review throughput. Nobody in the room needs to know they were prompted by one person.

A comment taxonomy. Prefix every comment with its severity:

blocking:   this must change before merge
suggestion: I would do it differently, your call
nit:        cosmetic, non-blocking, feel free to ignore
question:   I don't understand this, help me
praise:     this is good and I want to say so

This is cheap to adopt and disproportionately effective, because most of the harm comes from ambiguity rather than from tone. An author who cannot tell a nit from a blocker treats every comment as a blocker, which is exhausting. The convention is published as Conventional Comments if you want a spec to point at rather than inventing one.

Automate everything mechanical. Formatter, linter, import order, coverage threshold, all enforced in CI. Humans should never comment on style, because a style comment from a human reads as a judgment and the same rule from a linter reads as a rule. This single change removes a large fraction of the friction and nobody can object to it.

Publish a review order. Correctness, then design and boundaries, then tests, then readability, then nits. Stating the order in the team's review guide gives everyone permission to skip nits when the design is still wrong, and it gives you a shared language for "you are reviewing at the wrong level".

Rotate reviewers and pair-review. Nobody is the single gate for an area. Have the strong reviewer pair-review with a junior for two weeks: they narrate their reasoning, and the junior sees that the harsh comments come from a real model of the system rather than contempt. This converts a threat into a teacher, and it is the highest-leverage move available if the person is willing.

Instrument it. Time to first review, review queue depth and merge time, on a dashboard. Now the conversation is about numbers rather than feelings, and you will find out whether the problem got better.

Then: close the loop with the juniors

Go back to the two people who raised it. Tell them what changed (the taxonomy, the automation) without reporting on a private conversation. Tell them explicitly that a blocking: comment is a real requirement and everything else is genuinely optional, and that if they disagree with a blocking comment they should say so in the thread and you will back them. Then watch the next few PRs yourself, so you learn whether it worked rather than assuming.

Information I would gather

The actual comments, over at least two weeks. Review latency and queue depth per reviewer. Whether other people have the same experience or only these two, which distinguishes a pattern from a personality clash. Whether the strong reviewer is carrying a disproportionate review load. And whether the juniors' code is genuinely below the bar, because if it is, there is a coaching problem sitting underneath the review problem and fixing only the reviews leaves it in place.

The line I would not cross

I will not lower the technical bar to make the interaction pleasant. The bar is the reason the reviewer is valuable, and trading it away buys peace and costs the codebase.

I will not have this conversation in public, and I will not relay it to the juniors. Correction is private; that is not negotiable.

And I will not let it run indefinitely. If the behaviour has not changed after a direct conversation with a specific ask and a follow-up, it stops being feedback and becomes a performance conversation, documented, with my manager informed. Tolerating behaviour that drives people out is a decision to lose the people it drives out, and I would rather lose one strong engineer than three good ones.

Where this goes wrong

The lead softens it. "Some folks have mentioned the tone in reviews, maybe we could all be a bit more positive." The person does not recognise themselves in that sentence and nothing changes, and the juniors conclude you did not act.

The lead escalates too fast. Going straight to a performance conversation over review tone, with no direct feedback first, is unfair and gets you a justified complaint. The sequence matters: specific feedback, a concrete ask, a follow-up, and only then a formal process.

The lead solves it structurally and skips the person. Introducing the taxonomy without the conversation means the strong engineer keeps writing blocking: did you even test this, which is worse, because it now carries an official severity label.

The lead protects the juniors from the reviewer. Routing their PRs around the strong reviewer removes the friction and also removes the mentoring, and it tells everyone that the team has two tiers. Route around a person only as a last resort before a formal process, never as the fix.

Interviewer follow-ups

"What if the reviewer is right about the quality and the juniors really are shipping weak code?" Then I have two problems and I should say so. The review problem is about delivery and I handle it as above. The capability problem is mine: it means I have assigned work above someone's current level without support, or hired without a plan for ramping. The fix is pairing, a smaller scope with a clear stretch component, and design review before implementation rather than after, so the correction happens at the cheap stage. What I will not do is use "but the code is bad" as a reason to leave the review behaviour alone, because the two are independent.

"They say 'I'm just direct, this is a culture thing, I'm not changing'." I would separate directness from ambiguity and hold the line on the second. Directness is fine and I would defend it. What I am asking for is that a comment distinguishes a requirement from a preference and states the finding rather than a judgment of the author, and neither of those is about being soft. If they still refuse, the conversation changes: the team's ability to function is a job requirement, not a preference, and I would say that plainly, once, and then document it.

"They are your highest performer and they threaten to leave." I would take that seriously and not be held hostage by it. My honest read: an engineer who will quit over being asked to label their comments was likely to leave anyway, and the cost of two juniors leaving plus a team that avoids the codebase exceeds the cost of one departure. I would also check whether the threat points at a real grievance I have been ignoring, because it often does, and fixing that is the better outcome for everyone.

"How would you know it worked?" Time to first review and merge time, tracked before and after. The fraction of comments prefixed blocking: versus the rest, which tells you whether the ambiguity actually fell. Whether the two juniors are putting up PRs at their previous rate, since the tell for this problem is people batching work into fewer, larger PRs to reduce their exposure to review. And I would ask them directly in a 1:1 six weeks later, because the metric can improve while the experience does not.

"How does this change when a lot of the code is AI-generated?" It gets worse before it gets better, and this is worth raising unprompted. When generation speeds up, the bottleneck moves from writing to reviewing, and review queues back up within a couple of months of adoption. More volume through the same reviewer means more terse comments and more rubber-stamping at the same time. The counters are concrete: require the author to be able to explain generated code as their own, label AI-assisted PRs so reviewers calibrate, hold review queue depth and merge time as first-class metrics rather than anecdotes, and raise test requirements on generated code, because that is the check that scales when volume rises.

Production evidence

Google's publicly published engineering practices documentation includes a section on how to write code review comments, and its core guidance matches the advice above: be kind, comment on the code rather than the person, explain the reasoning, and balance giving explicit directions with pointing out problems and letting the author decide. It also publishes an explicit standard for what a reviewer should approve, which is the artifact that lets a team argue about the bar in the abstract rather than in a PR thread.

Conventional Comments (conventionalcomments.org) is the published specification for the blocking: / suggestion: / nit: labelling convention, which means you can adopt it by linking to a spec rather than by asking one person to change.

The 400-line threshold that shows up in review guidance across the industry traces to SmartBear's study of a Cisco code review programme, which reported that review effectiveness drops sharply beyond a few hundred lines. It is worth citing as a reason to cap PR size, because "review quality collapses past 400 lines" is a much stronger argument for small PRs than "small PRs are nicer".

Interview delivery note

Open with the structure and it will carry the whole answer: "First move, information I'd gather, line I wouldn't cross."

Then say this: "My first move is to read the actual comments, because 'people feel bad' is not actionable and 'here are four comments and what each one costs the author' is. Then a private SBI conversation with a specific behavioural ask, not 'be nicer'. Then I change the system, framed for the whole team rather than aimed at one person: a comment taxonomy so blocking and nit are distinguishable, automation of everything mechanical so humans never comment on style, and reviewer rotation so nobody is a single gate. The line I won't cross is lowering the bar. Their standard is why they're valuable; it's the delivery I'm changing."

The depth signal is the system change plus the measurement. Most candidates produce the conversation. Fewer produce the taxonomy and the automation. Almost nobody says how they would know whether it worked, and adding review latency and queue depth as the check is what makes it sound like something you have actually run.

The Staff & Team Lead Interview Reference