5 exercises — reframe direct criticism into professional, actionable suggestions. Learn to critique the code, not the author, when reviewing in English.
Key phrases for constructive feedback
"Could we...?" / "What if we...?" — frame suggestions as questions
"I'm concerned that..." / "I'm worried this might..." — own the feedback with "I" statements
"One option might be..." — offer alternatives without commanding
"Nice job on [specific thing]" — acknowledge good work specifically
"I might be missing context, but..." — express uncertainty honestly
0 / 5 completed
1 / 5
You spot a function that is hard to read. Which comment gives constructive feedback that critiques the code, not the person?
Constructive feedback targets the code and offers a path forward. "This function is doing a lot — could we extract the validation..." names a specific issue (the function has multiple responsibilities) and proposes a concrete, optional improvement framed as a question.
The other options attack the author ("you always..."), express frustration ("makes no sense"), or issue a bare command ("rewrite this") without explaining what or why. A useful rule: describe the observation, then suggest, then invite a response. Phrases like "could we...", "what if we...", and "one option might be..." keep the door open for discussion rather than dictating.
2 / 5
A reviewer wants to suggest a different approach without sounding like they are giving orders. Which phrasing is best?
Framing a suggestion as a question — "Have you considered...?" — is softer and more collaborative than a command, while still clearly communicating the idea. Adding the rationale ("it might make the lookups clearer") helps the author understand the benefit and decide for themselves.
Bare imperatives ("Use a map here", "A map. Now.") can read as curt or authoritarian in writing, where tone is easily lost. And "I can't believe you used a loop" expresses judgement of the author rather than discussing the code. In asynchronous review, where there is no facial expression or vocal warmth, deliberately softening with questions and reasons prevents misread tone.
3 / 5
Which feedback uses an "I" statement to share a concern without accusing the author?
"I" statements own the feedback as the reviewer's perspective rather than asserting it as absolute fact or blaming the author. "I'm worried this might swallow errors silently" communicates the same technical concern as "You broke the error handling" but invites dialogue instead of triggering defensiveness.
It also hedges appropriately ("might") and pairs the concern with a concrete suggestion ("could we log the exception here?"). Compare with "You broke..." (accusatory), "This will definitely cause bugs" (overstated certainty), and "Everyone knows..." (condescending). The goal of code review is shared improvement, and "I" statements keep it a conversation between peers.
4 / 5
Before raising several issues in a PR, what is a good practice for constructive feedback?
Naming specific things that were done well ("Nice job splitting this into small functions — really easy to follow") does two things: it makes feedback feel balanced rather than purely negative, and it signals that you actually read and understood the work. This builds the trust that makes critical feedback land better.
The key is specificity — vague praise ("looks good!") feels hollow. Listing only problems can demoralise, especially for junior engineers; leading with the harshest point sets a combative tone; and silently approving to dodge conflict means real issues ship to production. Genuine, specific acknowledgement is a tool, not flattery.
5 / 5
You think a change is risky but you are not certain. How do you express that professionally?
When you are not certain, expressing uncertainty honestly is more professional and more effective than overstating. "I might be missing context, but I'm a little concerned... — what do you think?" raises the issue, leaves room for the author to explain something you may not know, and explicitly invites their view.
This phrasing models intellectual humility and keeps the exchange collaborative. "This is a terrible idea" and "No. Just no." are dismissive and offer nothing actionable. "Did you even test this?" is a loaded, accusatory question. Hedging language ("I might be missing context", "I'm a little concerned") is not weakness — it is precision about your confidence level and an invitation to dialogue.