How do you word a code review comment when you think the author's approach is wrong?
answer
- label severity: blocking or nit
- ask, don't command
- cite the standard, not my taste
- quote one comment I actually wrote
- when I stop typing and talk
basics
~20 sProbes whether you can be direct without making it personal. Strong answers label severity first, state the objection as a question with the reason attached, cite a shared standard rather than taste, and quote one comment you actually wrote.
how to answer
5 beats- the principle I open withOne sentence on what your comments are for: routing attention, not scoring points. Keep it to a line — the interviewer is waiting for evidence, not philosophy.
- how I label blocking versus nitState your actual convention and where it lives, whether that is a prefix, a label, or a sentence at the top of the review. The point is that the author never has to guess which comments they must act on.
- the wording move: question plus reasonExplain how you attach a consequence the author can verify and leave a genuine opening to be wrong. Say why: an objection with evidence is arguable, an objection with authority is only obeyable.
- a comment I actually wrote, quotedRecite one real comment word for word, ideally one whose first draft you deleted. This is the beat that separates you from every candidate who describes being respectful in the abstract.
- when I stop commenting and talkGive your trigger for leaving the thread — a round count, a rising temperature, a disagreement about design rather than detail — and what you do in that conversation. Close by saying where the decision got written back down.
your answer
4 story prompts- Copy two comments you wrote last month, one blocking and one purely optional.
- Find a comment you nearly sent, then rewrote, and keep both versions.
- Name one team standard you can cite instead of your own preference.
- Recall a review where your question turned out to be a misread.
draft and rehearse your own answer in a learn session
go deeper
Code review is where most engineers give hard feedback most often, so this is a cheap read on how you handle disagreement in writing, where tone has no body language to soften it. Interviewers listen for whether you separate severity from preference, whether your objection carries a reason the author can independently check, and whether you can be blunt about risk while leaving the author's ownership intact.
I'm the newest person on the test-infrastructure side of a small startup, so I write comments that are easy to disagree with. My rule is that a comment says how much it matters before it says what I think. Last quarter a teammate's change fixed a flaky end-to-end spec by wrapping it in a two-second sleep and a retry. My instinct was that this hid the bug instead of fixing it, but I'd been there seven weeks and could easily have been missing context. So I checked before I typed: I pulled the branch, ran that spec forty times locally, and it still failed four of those runs even with the retry. Then I left one comment. 'Blocking, I think — I ran this locally 40 times and it still failed 4, so the retry may be hiding a race rather than removing it. The fixture load order looks non-deterministic to me. Am I reading that right?' Everything else I had was formatting, and I prefixed those 'nit, take it or leave it' so he knew he could ignore them. He came back agreeing about the fixture order, pushed a real fix, and I approved the same afternoon. What I took from it is that evidence plus a genuine question does the arguing for you. If I'd written 'don't use sleeps', it would have been my opinion against his, and as the junior person in that thread I'd have lost.
The signal is in the checking before the commenting, and in the quoted comment: severity first, a number the author can reproduce, and a real question. The formatting notes explicitly marked ignorable is a small move that reads as calibrated. Delivering only the principle, with no comment quoted, would flatten this to advice.
At this point I treat comment wording as routing rather than politeness. I review most of what touches the nightly suite at my company, so a badly phrased comment costs me a day of ping-pong I don't have. Two habits. Every comment opens with blocking, question, or nit, and I hold myself to at most two blocking comments in a review — if I have five, the design is the problem and a comment thread is the wrong venue for it. And a blocking comment carries the standard, not me: the rule we agreed on, not the way I'd have done it. The one I remember came after a bad week where our nightly signal had gone dark. Someone put up a change deleting three assertions that had been failing intermittently. My first draft said 'we don't delete assertions.' I didn't send it — that's a rule with a wagging finger and no reason in it. What I sent was: 'Blocking, though I think we want the same outcome here. Deleting these takes them out of the flake count, so the number improves while coverage gets worse. Can we quarantine with an expiry instead? Happy to pair on it after standup.' He took the pairing. The nightly suite's flaky share fell from 14.2% to 6.3% over the following month, once quarantined specs were being tracked instead of quietly removed. The comment I deleted is the reason that conversation stayed technical.
The deleted first draft does the work: the candidate shows the bad version and names why it was bad. The two-blocking-comments ceiling is a calibration rule an interviewer can probe. Dropping the standard-versus-preference distinction, or the pairing offer, would leave it sounding like tone advice with a metric attached.
Show that you check before you comment: pull the branch, reproduce, read the surrounding code. At your level a question that turns out to be a misread still reads well; a confident wrong command does not.
Own the phrasing. Name your severity convention, then read out one comment you rewrote before sending and say what the first draft would have cost you.
Talk about calibration as much as tone: how many blocking comments a single review can carry before the design is the real problem, and how fast you pull a thread onto a call.
Speak to review culture rather than your own keyboard: a norm cheap enough that others follow it without you in the thread, and evidence that comment quality changed on reviews you never touched.
saying these in an interview costs you the question
- Claims you never have to give anyone hard feedback
- Softens so far the author cannot tell what must change
- Marks every comment blocking, including pure preferences
- Presents personal taste as though it were a team standard
- Sarcasm or public point-scoring inside the comment thread
- Offers no example of wording you have actually used
- Show me how you would rewrite a comment that just says 'this is wrong'.Rewrite it aloud, don't describe it. Aim for three parts: severity, the consequence you can point at, and a question that leaves room to be wrong. Something like: blocking, because this path retries on a failure we currently count as a pass, so we would lose the signal. Am I reading the failure handling right? Naming the consequence is what stops it being taste.
- What do you do when the author disagrees with your comment?Say that one more written exchange is your limit, and that it has to add information rather than restate the position. After that you move to a call or pull in a third reader. Make clear you distinguish a preference you will drop instantly from a risk you will keep holding, and that you tell the author which one it is.
- How do you avoid leaving thirty comments on a large change?Talk about triage before typing: read the whole diff first, decide the one or two things that actually matter, and let the rest go or batch them as explicit non-blocking notes. Volume reads as distrust even when every comment is correct, and it buries the comment you needed the author to see.