4 exercises — how to agree, push back respectfully, ask for clarification, and confirm your fixes to reviewers.
0 / 17 completed
1 / 17
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 / 17
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 / 17
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 / 17
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.
5 / 17
During a code review of your new API endpoint, Sarah points out that the response doesn't include any information about potential rate limits. She says: 'It's important for users to understand if they're being throttled so they can adjust their requests.' What is the most professional and constructive response you should provide?
This scenario tests your ability to engage in productive discussion during code review. Simply agreeing with the reviewer shows you understand their point and are open to further explanation. Option 'A' is inappropriate as technical constraints shouldn't be presented as dismissive comments. Option 'C' seeks clarification – a good approach - but option 'B' demonstrates a better understanding of user needs and suggests a proactive solution. Dismissing the concern (option 'D') would be unhelpful and ignore valuable feedback.
6 / 17
John: 'This function is a bit complex. I'm not entirely sure I understand the logic behind calculating the discount percentage.'
As the original author, how should you respond to this comment during a code review? Choose the most appropriate option.
The key here is to *actively* solicit clarification rather than dismissing John's concern or offering a superficial solution. Option A is dismissive and doesn't address the root of the problem. Option B is overly defensive and avoids genuine engagement. While option D shuts down discussion, option C demonstrates willingness to help and guides the conversation toward understanding. It moves beyond simply saying 'no problem' to actually resolving the issue by getting John to articulate *exactly* what's unclear.
7 / 17
During a code review of your new API endpoint, Sarah points out that the response doesn't include any information about potential rate limits. She says: 'It's important for users to understand if they're being throttled so they can adjust their requests.' What is the most professional and constructive response you should provide?
This scenario tests your ability to engage in productive discussion during code review. Simply agreeing with the reviewer shows you understand their point and are open to further explanation. Option 'A' is inappropriate as technical constraints shouldn't be presented as dismissive comments. Option 'C' seeks clarification – a good approach - but option 'B' demonstrates a better understanding of user needs and suggests a proactive solution. Dismissing the concern (option 'D') would be unhelpful and ignore valuable feedback.
8 / 17
John: 'This function is a bit complex. I'm not entirely sure I understand the logic behind calculating the discount percentage.'
As the original author, how should you respond to this comment during a code review? Choose the most appropriate option.
The key here is to *actively* solicit clarification rather than dismissing John's concern or offering a superficial solution. Option A is dismissive and doesn't address the root of the problem. Option B is overly defensive and avoids genuine engagement. While option D shuts down discussion, option C demonstrates willingness to help and guides the conversation toward understanding. It moves beyond simply saying 'no problem' to actually resolving the issue by getting John to articulate *exactly* what's unclear.
9 / 17
During a code review of your new API endpoint, Sarah points out that the response doesn't include any information about potential rate limits. She says: 'It's important for users to understand if they're being throttled so they can adjust their requests.' What is the most professional and constructive response you should provide?
This scenario tests your ability to engage in productive discussion during code review. Simply agreeing with the reviewer shows you understand their point and are open to further explanation. Option 'A' is inappropriate as technical constraints shouldn't be presented as dismissive comments. Option 'C' seeks clarification – a good approach - but option 'B' demonstrates a better understanding of user needs and suggests a proactive solution. Dismissing the concern (option 'D') would be unhelpful and ignore valuable feedback.
10 / 17
John: 'This function is a bit complex. I'm not entirely sure I understand the logic behind calculating the discount percentage.'
As the original author, how should you respond to this comment during a code review? Choose the most appropriate option.
The key here is to *actively* solicit clarification rather than dismissing John's concern or offering a superficial solution. Option A is dismissive and doesn't address the root of the problem. Option B is overly defensive and avoids genuine engagement. While option D shuts down discussion, option C demonstrates willingness to help and guides the conversation toward understanding. It moves beyond simply saying 'no problem' to actually resolving the issue by getting John to articulate *exactly* what's unclear.
11 / 17
During a code review of your new API endpoint, Sarah points out that the response doesn't include any information about potential rate limits. She says: 'It's important for users to understand if they're being throttled so they can adjust their requests.' What is the most professional and constructive response you should provide?
This scenario tests your ability to engage in productive discussion during code review. Simply agreeing with the reviewer shows you understand their point and are open to further explanation. Option 'A' is inappropriate as technical constraints shouldn't be presented as dismissive comments. Option 'C' seeks clarification – a good approach - but option 'B' demonstrates a better understanding of user needs and suggests a proactive solution. Dismissing the concern (option 'D') would be unhelpful and ignore valuable feedback.
12 / 17
John: 'This function is a bit complex. I'm not entirely sure I understand the logic behind calculating the discount percentage.'
As the original author, how should you respond to this comment during a code review? Choose the most appropriate option.
The key here is to *actively* solicit clarification rather than dismissing John's concern or offering a superficial solution. Option A is dismissive and doesn't address the root of the problem. Option B is overly defensive and avoids genuine engagement. While option D shuts down discussion, option C demonstrates willingness to help and guides the conversation toward understanding. It moves beyond simply saying 'no problem' to actually resolving the issue by getting John to articulate *exactly* what's unclear.
13 / 17
Mark is reviewing your PR for a new user authentication service. He comments: 'I'm concerned about the lack of input validation on this field. What's the best way to respond?'
// User signup form
String username = request.getParameter("username");
Which response demonstrates a professional and constructive approach?
The best response acknowledges the reviewer's concern (option 1) and proposes a concrete action to address it – adding validation checks. Options 2 and 3 are dismissive or offer explanations that don't directly engage with the feedback. Option 4 is simply an apology without any commitment to improvement.
14 / 17
During a Slack discussion about a bug report regarding intermittent database connection errors, another developer writes: 'This seems like a race condition. We should add some retry logic.' What is the most appropriate response to this suggestion?
Option 1 demonstrates a collaborative approach by agreeing with the suggestion while requesting further information – crucial for understanding the root cause. Options 2, 3, and 4 are either overly prescriptive, lacking in investigation, or dismissive of the problem.
15 / 17
You've written a detailed PR description explaining your approach to refactoring a legacy module. A reviewer comments: 'This is much cleaner now, but I'm still not entirely clear on why you chose this particular algorithm. Could you elaborate?' What should you do?
Option 2 is the most professional response. Adding a comment to explain the reasoning directly addresses the reviewer's question and provides clarity without escalating the discussion. The other options are dismissive or avoid addressing the underlying need for explanation.
16 / 17
After receiving several detailed comments on a new microservice API design, you've made significant changes and addressed every concern. You're now requesting a re-review. What should your commit message include?
Option 2 is the most effective. It clearly states that the re-review addresses the feedback received. The other options are vague or don't convey the value of the changes made.
17 / 17
During a standup update on your progress with a new feature, a senior developer asks: 'Can you explain how you're handling potential timeouts in this service?' You respond: 'I'm just using try/catch blocks.' What is the most appropriate follow-up to your response?
Option 1 demonstrates a willingness to learn and improve. While try/catch blocks can handle exceptions, they don't address timeouts effectively. The other options are either dismissive or indicate a lack of consideration for potential issues.
What does the "Responding to Feedback" exercise practise?
Practice responding professionally to code review comments: agree, push back, ask for clarification, and close the review loop. 4 exercises.
How many questions are in this exercise?
This exercise has 17 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Code Review Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Responding to Feedback" part of a larger series?
Yes — it's one exercise in the Code Review Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Review Language category page for related exercises, or browse the main Exercises hub for other IT English topics.