4 exercises — stretch assignments, coaching with questions, unblocking without micromanaging, preserving enthusiasm.
0 / 4 completed
1 / 4
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 / 4
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 / 4
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 / 4
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.