TL;DR: Diagnose before prescribing: struggle is usually unclear expectations, missing context, low confidence or workload, not raw ability. Contract on one owned deliverable with tight checkpoints, give same-day specific feedback, and measure success by what they ship alone, not by how clean your edits made it.
How to approach it
Name the trap out loud: rescuing. Interviewers use this question to see whether you optimise for the deadline or for building an engineer, and the strong answer refuses the false choice by re-scoping work instead of absorbing it. Structure: diagnose, contract, coach, escalate only on evidence.
A strong answer
Diagnosis first, because the intervention differs completely by cause. Observe specifics instead of labels: pull requests sitting unread for days, silent standups, confusion repeated about the same service, work started but never pushed. Then ask, in private and without accusation: "Where are you spending most of your time, and what feels slowest?" The answer reshapes the plan. Unclear expectations need a written definition of done. Missing context needs architecture walkthroughs and a designated person for questions. Low confidence needs smaller, guaranteed-win tasks stacked deliberately. Genuine skill gaps need paired sessions on one topic at a time, not advice to read documentation.
The contract prevents both failure modes, neglect and rescue:
- One deliverable that is entirely theirs, scoped to about a week, with a definition of done written down by both of you.
- A fifteen-minute daily checkpoint, which replaces hovering: they keep moving between checkpoints and you catch drift early.
- An explicit rule: "Get stuck for up to half a day, then bring me the specific blocker." That kills both silent drowning and instant hand-raising.
Feedback discipline carries the middle weeks. Same day, in private, one theme at a time, always behavioural: "The migration PR sat three days and blocked release; what happened on Wednesday?" rather than "you seem disengaged". Review their pull requests with teaching comments and questions ("what happens when the queue is empty?") instead of rewritten commits. A rewritten commit teaches nothing except that corrections arrive from above.
Track the honest metric: slices shipped end to end without your edits. Bring in the manager early when expectations, workload or support need their help; explain that involvement to the junior. Two weekly cycles can identify a blocker but cannot establish general role fit. Explain what support you are requesting and why; avoid a surprise performance discussion at calibration.
What interviewers probe next
"The deadline could not move. What then?" Re-scope, do not absorb: take the riskiest unknown piece yourself, leave the junior a coherent completable slice, and say openly that you split it that way for speed, not judgment.
"Give me an example of hard feedback you actually delivered." Prepare one concrete sentence: the behaviour, the impact, the question back. Vague kindness ("keep going, you are improving") reads as avoidance.
"When do you conclude someone is not right for the role?" Use the organization's fair performance process with the line manager, adequate support and a context-appropriate review period. A mentor should provide specific evidence, not infer poor role fit from two short tasks.
Common mistakes
Telling the rescue story proudly: "the module was due so I built it over the weekend." That answers a different question, the one where you failed.
Skipping diagnosis and prescribing pairing for a motivation problem, or motivation talks for a skill gap.
Blaming the junior throughout the story. Interviewers hear exactly how you will speak about your next team member who struggles.
Feedback softened until it disappears. Direct and kind beats polite and useless.