TL;DR: Identify the specific blocker with the engineer, agree on a coherent task they can own and give feedback that teaches the missing reasoning. Adjust scope or support as evidence changes, and distinguish mentoring from the manager's performance responsibilities.
How to approach it
Choose a real example you can discuss without exposing private performance details. Describe an observed behavior and its effect rather than assigning a motive such as laziness or lack of confidence. Explain what the engineer owned and what you contributed.
A strong answer
Begin with the work. A pull request may sit unfinished because the task is unclear, the engineer lacks access, reviewers are unavailable or a technical concept is unfamiliar. Ask where progress stops and inspect the work together. Pairing on code does little for a request blocked by an approval nobody has answered.
In this fictional mentoring exercise, an engineer is adding retry handling to a small deployment-status client. The initial patch retries every response and has no total deadline. During review, they can describe a loop but cannot explain which failures might represent an operation that already completed. The missing topic is retry semantics, not an overall verdict about their ability. The idempotency concept explains why repeated operations need an explicit contract; use it to prepare the review question about an ambiguous timeout.
Reduce the assignment to reading status from a local fixture with a bounded number of attempts and a total time allowance. Leave production writes outside this first task. Agree on observable acceptance cases: immediate success, a temporary failure followed by success, a permanent rejection, and exhaustion of the time allowance. Ask the engineer to explain why each case belongs in the test set before implementing it.
Use review questions that expose the reasoning: “If the remote side completed the action but the response was lost, what would a retry do?” Give a short explanation of the concept, then let them change the implementation and tests. Writing every correction yourself can produce a working patch while leaving you unsure what they understood.
Set checkpoints appropriate to the risk and their familiarity. For this exercise, a brief review of the test plan before coding and a later review of the first implementation may be sufficient. Do not require someone to wait half a day before asking about a missing permission or a potentially destructive operation. Agree that ordinary debugging can continue independently while safety or access blockers are raised promptly.
If the delivery date cannot move, split the work openly. A senior engineer can own the production integration while the junior owns the complete fixture-backed client behavior. Explain how the pieces connect and retain a real end-to-end responsibility for the junior. Calling a token edit “ownership” after taking every consequential decision away would misrepresent the assignment.
Follow with a related but different task. For example, ask the engineer to review a client whose per-attempt timeout fits but whose cumulative attempts exceed the caller's deadline. Their explanation gives more evidence of learning than repeating the same patch from memory. Independent work still includes normal code review; success does not require never asking a question or receiving an edit.
Involve the line manager when workload, expectations or sustained support need a management decision. Be clear with the engineer about that involvement. A short mentoring exercise cannot establish general role fit, and a mentor should not create a surprise performance judgment from a few tasks.
What interviewers probe next
“What difficult feedback did you give?” Use the behavior and consequence: “The loop retries permanent rejections, so a caller waits without a possible recovery. Walk me through how you chose the retry condition.” Follow with the missing concept and an agreed next step.
“How did you avoid taking over?” Name the decisions the engineer made, the checkpoints you used and the coherent deliverable they completed. Be honest about any integration you handled yourself.
“What if progress remains slow?” Revisit the blocker and the adequacy of support with the engineer and manager. Use specific evidence over an appropriate review period; two tasks do not justify a broad diagnosis.
Common mistakes
A rescue story that describes only your weekend implementation does not explain mentoring. Include what the engineer learned and later applied.
Counting unaided commits can punish healthy collaboration. Assess understanding and ownership of an outcome, including appropriate escalation when the work exceeds the agreed boundary.