4 exercises — stretch assignments, coaching with questions, unblocking without micromanaging, preserving enthusiasm.
0 / 19 completed
1 / 19
A junior engineer is about to implement a simple feature. You could write it in 30 minutes or you could help them do it. What approach develops them most effectively?
Option C demonstrates coaching-based task assignment for junior growth:
Key elements: 1. Full ownership framing — "own completely — implementation to PR to demo" — not just coding, but the whole delivery 2. Structured starting point — 20-minute approach mapping — scaffolds their thinking without taking over 3. Explicit step-back — "then I'll step back and let you build it" — makes your withdrawal from the process intentional, not abandonment 4. The 20-minute rule — "sit with hard problems for at least 20 minutes before reaching out" — builds productive struggle tolerance and debugging skills 5. Debrief planned — "after the PR is reviewed" — the learning loop isn't complete until you reflect together
Why "just write it yourself" stunts junior growth: Every time you take over a task, you deny a learning opportunity. The junior learns that they can't be trusted with it, or that the right response to difficulty is to escalate.
The "20-minute rule" rationale: Junior engineers often ask for help too quickly because they haven't yet learned what productive struggle feels like. Setting an explicit timer ("20 minutes of investigation before pinging me") gives them permission to be stuck, builds debugging muscle, and means that when they do ask, the question is much more specific and productive.
2 / 19
A junior engineer asks you: "Why do we use PostgreSQL instead of MongoDB for this project?" You know the answer. How do you respond in a way that develops their thinking?
Option C demonstrates the coaching question technique — asking before telling:
Why asking first is more effective than explaining first: 1. Activates their existing knowledge — they likely know more than they think; the question surfaces it 2. Reveals their mental model gaps — their answer shows you exactly what's missing, so you explain what's actually needed 3. Higher retention — explanations that build on what they already know stick better than explanations from scratch 4. Models intellectual curiosity — "I'm genuinely curious" is not rhetorical; if you treat their thinking as worth hearing, they learn to think out loud 5. Connects to their framework — "that's a good analysis; the specific factors in our case were..." — bridges their understanding to the real decision
The "does that change how you'd think about it?" close: This checks comprehension without a quiz. If they can articulate how their thinking shifted, the learning has occurred. If it didn't change their thinking, they might have missed the key point — and now you know.
When to just answer: Not every question needs the Socratic method. Time-sensitive questions, questions during incidents, and questions where the junior is clearly frustrated — just answer directly. Reserve the coaching approach for reflective moments where both of you have time.
3 / 19
A junior engineer is four weeks into working on a feature and seems to be circling without making progress. You suspect they're stuck but haven't asked for help. How do you intervene without micromanaging?
Option C is a non-micromanaging check-in for a junior who might be stuck:
What makes it effective: 1. States the reason for checking in — "not to review your work, but because we're at sprint end" — transparent motive removes the feeling of surveillance 2. Opens with "where are you at?" — gives them agency to disclose at whatever level they're comfortable 3. Asks about difficulty explicitly — "harder to figure out than expected?" — gives them permission to admit struggle without it feeling like failure 4. Normalizes asking for help — "useful to talk through before you've solved it" — reframes help-seeking as a technique, not an admission of incompetence 5. Makes the cost concrete — "15-minute debugging conversation can unblock a day of stuck" — gives them a compelling reason to ask
The "stuck but won't ask" pattern: Junior engineers often stay stuck for days because: (a) they think they should be able to figure it out alone, (b) they're worried asking will reveal incompetence, or (c) they don't yet know that 20 minutes with a senior can replace 2 days of struggling. This check-in addresses all three.
The anti-micromanagement principle: The difference between checking in and micromanaging is: are you checking what they did, or whether they have what they need? "How's your progress?" = micromanaging. "Do you have everything you need to move forward?" = support.
4 / 19
A junior engineer finishes a task and says proudly "I just figured it out on my own!" Later you review the code and see it works but uses an anti-pattern that will cause issues at scale. How do you give feedback without crushing their enthusiasm?
Option C is the constructive correction that preserves enthusiasm:
Structure breakdown: 1. Genuine acknowledgement first — "debugging that kind of thing solo is genuinely satisfying" — celebrates the actual achievement (independent problem-solving) 2. Separates the work from the feedback — "I want to give you some context on one part" — positions it as additional information, not a verdict 3. Acknowledges it works — "works for our current traffic" — doesn't deny what they accomplished 4. Explains why they made the choice — "docs examples show it" — demonstrates understanding of their reasoning, removes blame 5. Explains the future problem — "at scale it creates [X]" — gives them the context they needed 6. Normalizes the pattern — "senior engineers fall into it too" — removes shame 7. Offers to teach, not just correct — "show you the alternative pattern" with a clear reason ("so you have this in your toolkit") 8. Reframes the ask — "not to redo your work" — addresses the implicit fear that this is an attack on their solution 9. Time-boxes it — "10 minutes" — low-cost for a high-value skill gain
Why enthusiastic moments are teaching gold: When a junior is proud of what they built, they are maximally open to learning. Crushing that openness with "this is wrong" is the fastest way to make them defensive about code review feedback permanently.
5 / 19
Sarah, a junior developer, just submitted a PR with a complex regex. The code works but is difficult to read and maintain. You've spent an hour reviewing it. What's the most effective way to guide her towards improvement?
The key here is actionable feedback. Suggesting refactoring directly addresses the problem—complex code is hard to maintain. Option A is dismissive and unhelpful. Option C prioritizes speed over good practices, which isn't a mentoring goal. Option D assumes understanding without prompting critical thought; it's better to guide her thinking than simply demand an explanation.
6 / 19
David asks you: "Why are we using asynchronous HTTP requests with Node.js instead of synchronous calls?" You explain the benefits of non-blocking I/O for handling multiple concurrent requests efficiently. What's the best way to frame this explanation for a junior developer?
The junior developer needs to understand *why* something is better, not just a definition. Option A is too abstract; it doesn't connect the concept to real-world problems. Option C offers an opinion, not technical reasoning. Option D misses the core benefit – concurrency – and focusing only on latency isn't sufficient for understanding the broader impact.
7 / 19
Emily submits a PR with extensive unit tests. However, many of the tests are brittle and rely on specific data values that are unlikely to be encountered in production. You want to encourage her to write more robust tests without discouraging her efforts. What's your most constructive approach?
The most valuable feedback here is to understand *her* reasoning. Option A is overly critical. Option C ignores best practices for test design. Option D provides a starting point but doesn't address the core issue of brittle tests – focusing on understanding her thought process will help her develop better testing habits.
8 / 19
Mark has just finished a task and says, "I solved it myself!" You review the code and notice he's used an outdated API library that's nearing end-of-life. How do you address this feedback to maintain his confidence while guiding him towards best practices?
The key is balance. Acknowledging his success initially validates his effort. However, a simple 'That's great!' isn't enough – you need to provide constructive feedback and suggest an alternative. Option A is overly negative. Option D ignores the technical issue entirely. Option 3 is valuable for understanding *why*, but needs to be followed by guidance.
9 / 19
During a standup meeting, Lisa says, "I've made great progress on the user authentication module! I'm using OAuth2 for integration. It's going really well." You know that OAuth2 is currently being replaced by OpenID Connect due to security vulnerabilities. How do you respond in a way that gently guides her towards the updated standard without disrupting her momentum?
The goal here is to influence subtly. Directly correcting her in the standup could disrupt the flow and damage her confidence. Option A is too forceful. Option D is overly prescriptive and potentially confrontational. Offering a later discussion provides an opportunity for gentle guidance.
10 / 19
Sarah, a junior developer, just submitted a PR with a complex regex. The code works but is difficult to read and maintain. You've spent an hour reviewing it. What's the most effective way to guide her towards improvement?
The key here is actionable feedback. Suggesting refactoring directly addresses the problem—complex code is hard to maintain. Option A is dismissive and unhelpful. Option C prioritizes speed over good practices, which isn't a mentoring goal. Option D assumes understanding without prompting critical thought; it's better to guide her thinking than simply demand an explanation.
11 / 19
David asks you: "Why are we using asynchronous HTTP requests with Node.js instead of synchronous calls?" You explain the benefits of non-blocking I/O for handling multiple concurrent requests efficiently. What's the best way to frame this explanation for a junior developer?
The junior developer needs to understand *why* something is better, not just a definition. Option A is too abstract; it doesn't connect the concept to real-world problems. Option C offers an opinion, not technical reasoning. Option D misses the core benefit – concurrency – and focusing only on latency isn't sufficient for understanding the broader impact.
12 / 19
Emily submits a PR with extensive unit tests. However, many of the tests are brittle and rely on specific data values that are unlikely to be encountered in production. You want to encourage her to write more robust tests without discouraging her efforts. What's your most constructive approach?
The most valuable feedback here is to understand *her* reasoning. Option A is overly critical. Option C ignores best practices for test design. Option D provides a starting point but doesn't address the core issue of brittle tests – focusing on understanding her thought process will help her develop better testing habits.
13 / 19
Mark has just finished a task and says, "I solved it myself!" You review the code and notice he's used an outdated API library that's nearing end-of-life. How do you address this feedback to maintain his confidence while guiding him towards best practices?
The key is balance. Acknowledging his success initially validates his effort. However, a simple 'That's great!' isn't enough – you need to provide constructive feedback and suggest an alternative. Option A is overly negative. Option D ignores the technical issue entirely. Option 3 is valuable for understanding *why*, but needs to be followed by guidance.
14 / 19
During a standup meeting, Lisa says, "I've made great progress on the user authentication module! I'm using OAuth2 for integration. It's going really well." You know that OAuth2 is currently being replaced by OpenID Connect due to security vulnerabilities. How do you respond in a way that gently guides her towards the updated standard without disrupting her momentum?
The goal here is to influence subtly. Directly correcting her in the standup could disrupt the flow and damage her confidence. Option A is too forceful. Option D is overly prescriptive and potentially confrontational. Offering a later discussion provides an opportunity for gentle guidance.
15 / 19
Sarah, a junior developer, just submitted a PR with a complex regex. The code works but is difficult to read and maintain. You've spent an hour reviewing it. What's the most effective way to guide her towards improvement?
The key here is actionable feedback. Suggesting refactoring directly addresses the problem—complex code is hard to maintain. Option A is dismissive and unhelpful. Option C prioritizes speed over good practices, which isn't a mentoring goal. Option D assumes understanding without prompting critical thought; it's better to guide her thinking than simply demand an explanation.
16 / 19
David asks you: "Why are we using asynchronous HTTP requests with Node.js instead of synchronous calls?" You explain the benefits of non-blocking I/O for handling multiple concurrent requests efficiently. What's the best way to frame this explanation for a junior developer?
The junior developer needs to understand *why* something is better, not just a definition. Option A is too abstract; it doesn't connect the concept to real-world problems. Option C offers an opinion, not technical reasoning. Option D misses the core benefit – concurrency – and focusing only on latency isn't sufficient for understanding the broader impact.
17 / 19
Emily submits a PR with extensive unit tests. However, many of the tests are brittle and rely on specific data values that are unlikely to be encountered in production. You want to encourage her to write more robust tests without discouraging her efforts. What's your most constructive approach?
The most valuable feedback here is to understand *her* reasoning. Option A is overly critical. Option C ignores best practices for test design. Option D provides a starting point but doesn't address the core issue of brittle tests – focusing on understanding her thought process will help her develop better testing habits.
18 / 19
Mark has just finished a task and says, "I solved it myself!" You review the code and notice he's used an outdated API library that's nearing end-of-life. How do you address this feedback to maintain his confidence while guiding him towards best practices?
The key is balance. Acknowledging his success initially validates his effort. However, a simple 'That's great!' isn't enough – you need to provide constructive feedback and suggest an alternative. Option A is overly negative. Option D ignores the technical issue entirely. Option 3 is valuable for understanding *why*, but needs to be followed by guidance.
19 / 19
During a standup meeting, Lisa says, "I've made great progress on the user authentication module! I'm using OAuth2 for integration. It's going really well." You know that OAuth2 is currently being replaced by OpenID Connect due to security vulnerabilities. How do you respond in a way that gently guides her towards the updated standard without disrupting her momentum?
The goal here is to influence subtly. Directly correcting her in the standup could disrupt the flow and damage her confidence. Option A is too forceful. Option D is overly prescriptive and potentially confrontational. Offering a later discussion provides an opportunity for gentle guidance.
This module focuses on Mentoring & Feedback — real workplace phrasing you'll use on the job. It contains 19 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 19 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.