4 exercises — how to agree, push back respectfully, ask for clarification, and confirm your fixes to reviewers.
0 / 4 completed
1 / 4
A reviewer left this comment on your PR: "The error handling here seems fragile." What is the best response?
Option B is professional because it: (1) acknowledges the feedback positively ("Thanks for flagging"); (2) asks for clarification before changing code — which prevents unnecessary rework; (3) signals collaboration ("I want to make sure I understand").
When a review comment is vague, it's always better to ask for specifics than to guess what the reviewer means. This also helps the reviewer articulate their concern more precisely, which makes the discussion more productive.
Option A is defensive. Option C commits to a fix without understanding what needs fixing. Option D flat-out disagrees — there are better ways to push back.
2 / 4
You agree with a reviewer's comment about a missing null check. How should you respond? Complete the sentence: "_____ — I missed that edge case. I'll add a guard clause and update the unit tests before requesting re-review."
"You're right" is direct, professional, and confident. There's no need to hedge when the reviewer has correctly identified an issue. The full response models three key elements: (1) clear agreement ("You're right"); (2) acknowledgement of the specific issue ("I missed that edge case"); (3) concrete next steps with a timeline ("I'll add… before requesting re-review").
Avoid "Maybe you're right" — it sounds uncertain and slightly passive-aggressive. "I suppose" has a similar problem. "Yes sure" is too informal for a professional code review context.
3 / 4
A reviewer asks you to use a completely different approach to solve the problem. You implemented it the current way for a specific reason. What is the best response?
Option B is the model response for a professional technical disagreement. It: (1) shows you considered alternatives ("I considered that approach"); (2) explains your reasoning ("The reason I went with… is"); (3) remains open to the reviewer's view ("happy to discuss the trade-offs"); (4) doesn't make it personal ("open to going either way").
This is sometimes called the "disagree and commit" pattern — you explain your position clearly, then defer to team consensus. Option A is a flat refusal. Option C commits without defending your reasoning (which may have been sound). Option D avoids the discussion rather than resolving it.
4 / 4
You've fixed all the reviewer's comments and pushed new commits. What is the best "re-review request" comment?
Option C closes the review loop professionally. It: (1) confirms all comments were addressed; (2) references the commits (gives the reviewer an anchor point); (3) summarises the main change (reduces the reviewer's cognitive load); (4) invites final review without being demanding.
Compare: "Done." and "Fixed." tell the reviewer nothing — where is the fix? What was changed? Option D uses "Please approve now" which sounds like pressure.
Proactively summarising changes is a mark of a senior developer — it shows you understand that reviewers have limited time and you're helping them review efficiently.