4 exercises — SBI framework, written performance reviews, code review pushback, and corrective conversations.
0 / 9 completed
1 / 9
A senior engineer on your team consistently interrupts others during technical discussions. You need to give them feedback. Which feedback delivery uses the SBI framework (Situation-Behaviour-Impact) correctly?
Option C correctly applies the SBI (Situation-Behaviour-Impact) feedback framework:
SBI breakdown: • S — Situation: "our architecture review on Tuesday, during the discussion about caching strategy" — specific, not vague "in meetings" • B — Behaviour: "spoke over @sarah three times before she could finish" and "same with @james" — observable actions, not personality judgments ("aggressive", "dominant") • I — Impact: "both stopped trying to contribute after that; potentially lost valuable perspectives in a decision that will affect the team for months" — connects the behaviour to a real consequence
What makes this excellent beyond SBI: 1. Intent acknowledgement — "I think it comes from enthusiasm" — separates the behaviour from malicious intent, lowers defensiveness 2. Stakes framing — "your voice carries weight; that makes inclusive discussion more important" — reframes the feedback as being about maximising their positive influence, not just correcting bad behaviour 3. Collaborative framing — "I'd like us to work on it" — shared ownership, not accusation
SBI vs vague feedback: • Vague: "You're too dominant" → triggers defensiveness, no actionable change • SBI: specific situation + observable behaviour + concrete impact → actionable, harder to dismiss
2 / 9
You need to give written performance review feedback for a junior engineer. They're technically strong but their written communication to stakeholders needs significant improvement. Which review excerpt is most professional?
Option C is a professional written performance review section:
What makes it effective: 1. Leads with strengths — specific work artifact ("PR #488"), specific skill demonstrated — not generic praise 2. Development area framing — "development area", not "weakness" — the framing affects how the person receives it 3. Specific incidents — "two client-facing status updates in Q3 required significant revision" — evidence, not impression 4. Specific pattern named — "technical details the audience didn't need; resolution/next steps not prominent enough" — tells them exactly what to change 5. Normalizes the gap — "common growth area at this career level" — reduces shame, contextualizes 6. Concrete goal with support — specific action (draft updates for next two incidents), specific mechanism (share with manager before sending), specific commitment (I'll provide coaching) — not "should improve"
The "specific artifact + pattern" rule: Every feedback item in a performance review should be traceable to at least one specific event, PR, meeting, or document. "Bad at emails" is unchallengeable and therefore often challenged. "These two updates needed revision for these specific reasons" is specific and actionable.
The goal quality test: A good review goal has: an action, a timeframe, a deliverable, and a support structure. "Needs to improve communication" passes zero tests. "Draft next two incident updates for manager review" passes all four.
3 / 9
A junior engineer pushes back on your code review feedback: "But the docs say this approach is fine." They're referring to an older version of the docs that recommends a pattern you know causes performance issues at scale. How do you respond?
Option C is the professional response to pushback on code review feedback:
Structure: 1. Validates their reference — "you're right that the docs describe that pattern" — acknowledges they weren't wrong to check 2. Explains the gap — "docs predate some scaling issues we ran into" — fills in context they couldn't have had 3. Gives specific evidence — N+1 at 10K req/s, specific incident reference, postmortem PR — makes the concern concrete and verifiable 4. States the motivation — "rather have this conversation now than discover in production" — frames it as looking out for them, not winning an argument 5. Stays genuinely open — "if you think the trade-off is different for this use case, walk me through your reasoning" — this is not rhetorical; they might have context you lack
Why "because I said so" damages junior growth: Junior engineers learn by understanding the "why". A senior who can't explain a review comment is either applying cargo cult patterns or doesn't have time to teach. The first is a problem; the second damages trust over time. Both result in juniors who comply without learning.
When the junior's pushback is right: Sometimes they know something you don't. "Walk me through your reasoning" is not just diplomatic — it's intellectually honest. Good feedback culture goes both directions.
4 / 9
You need to give "corrective" feedback to an engineer who missed a deadline without telling anyone. The sprint ended with an unfinished story marked done. How do you frame this conversation?
Option C is the professional corrective feedback conversation:
Structure: 1. Names the specific event — "the auth story last sprint, marked done before it was complete" — concrete, not general 2. Sets intent — "not to blame; to understand so we can prevent it" — lowers defensive response 3. Asks for their side first — understanding the engineer's experience might reveal something unknown (blocked? overwhelmed? unclear scope?) 4. Distinguishes the real issue — "the issue isn't the delay — it's the communication" — names the actual behavior that needs to change, not the symptom 5. Explains the business reason — "the earlier we know, the more options we have; marking done removes that optionality" — connects the behavior to real consequences 6. Makes a specific behavioral agreement — "if you're at risk by mid-sprint, flag it in standup" — concrete, observable, agreed 7. Changes the frame — "I'm interested in supporting you earlier" — positions the manager as a resource, not a guard
The "behaviour vs. person" distinction: Feedback about "marking a story done" (behaviour) is received very differently from "you're dishonest" (person). Always target the behaviour and its impact on the team's ability to work.
5 / 9
Sarah, a senior developer, just posted this comment on the team's Slack channel regarding a potential bug fix:
'This is easy, just add a check!'
You believe her solution might introduce unintended side effects and could be better addressed with a more robust approach. Which response best demonstrates constructive feedback while acknowledging Sarah's initial suggestion?
This question tests giving feedback in a common communication channel (Slack). Option A is too blunt; option B dismisses the suggestion entirely. Option C invites a discussion and focuses on the positive initial idea while gently introducing concerns about risk mitigation – perfectly aligned with mentoring. Option D is overly directive and lacks tact.
6 / 9
David, a junior developer, submits a pull request for a new feature in the authentication service. Your code review comment reads: 'This implementation is overly complex and difficult to understand.' Which of the following options provides the most effective feedback to David, aligning with best practices for constructive criticism?
Option A focuses solely on a superficial issue (comments). Option B is too vague. Option C offers specific feedback relating to design principles (maintainability, scalability) and invites a discussion—a key element of mentoring. Option D is purely negative and unhelpful.
7 / 9
Maria, the team lead, asks you to provide feedback on this PR description:
'Fixed a bug. Code works.'
She wants you to improve the description to be more informative for reviewers and future developers. Which of the following additions to the description would best fulfill Maria's request?
This scenario tests providing feedback on documentation. A good PR description should clearly state *what* problem was solved and *how*. Option A is pointless. Option C simply repeats the original inadequate statement. Option D only changes the title, not the content.
8 / 9
Ben, a developer, missed a sprint deadline and marked a story as 'done' in Jira without completing it. During a standup update, you observe this. How do you approach the conversation with Ben to address this situation constructively?
This tests handling a less severe but still problematic situation. Option A is overly aggressive. Option B avoids addressing the core issue. Option C demonstrates empathy, seeks understanding, and focuses on learning and improvement – crucial for mentoring. Option D is purely punitive.
9 / 9
Chloe, a developer, submits a code review comment: 'This is bad.'
You know she's frustrated with a particularly complex section of the codebase. Which response demonstrates effective feedback while acknowledging Chloe's emotional state?
This focuses on managing communication when emotions are involved. Option A is a non-committal response. Option B simply echoes the negative statement. Option C offers specific guidance, demonstrates empathy by acknowledging Chloe's experience, and proposes a collaborative approach – the most constructive and supportive action.
What will I practise in "Giving Structured Feedback"?
This module focuses on Mentoring & Feedback — real workplace phrasing you'll use on the job. It contains 9 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 9 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Mentoring & Feedback exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around mentoring & feedback — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Mentoring & Feedback exercises?
See the Mentoring & Feedback hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.