When a junior you mentor is stuck, how do you decide whether to step in?
answer
- your signal for stuck versus learning
- timebox agreed out loud beforehand
- intervene with questions, not the keyboard
- hard overrides: customer impact, real deadline
- debrief so the lesson lands
basics
~20 sProbes judgment about productive struggle versus wasted flailing. Answer with the signal you read, the timebox you agree up front, an intervention that adds information instead of taking the keyboard, and the conditions under which you override all of it.
how to answer
5 beats- the signal you read for stuck versus learningOpen with something observable rather than intuition: whether their questions are narrowing or looping, whether they can say what they have ruled out, whether they are still forming hypotheses or guessing at random.
- the timebox you set with them up frontSay that the limit is agreed before the struggle starts, in their words as well as yours, so that coming back is expected rather than an admission. Give the rough duration you use and what triggers the check-in.
- how you intervene without taking overDescribe the ladder: ask what they ruled out, narrow the search space with them, pair with them driving. Say what you deliberately do not say, and what you would only demonstrate once.
- the conditions where you override all of itName the hard triggers out loud — customer impact, a commitment that will actually slip, a mentee whose confidence is draining rather than building. This beat proves the judgment is calibrated rather than ideological.
- what you do afterwards so the lesson sticksWhether they solved it or you did, close the loop: a short walkthrough of what the answer turned out to be, and where that knowledge now lives so the next person is not stuck the same way.
your answer
4 story prompts- Recall one time you let someone stay stuck and it clearly paid off.
- Recall one time you stepped in too early or too late, and name the cost.
- Write the exact words you use to set a timebox with a mentee.
- Pick a case where a real deadline forced you to cut a struggle short.
draft and rehearse your own answer in a learn session
go deeper
This probes coaching judgment and risk ownership at once. Interviewers want to know whether you can leave someone in difficulty long enough to learn without letting the cost land on customers or the schedule, and whether your intervention builds capability rather than replacing it. A strong answer names an explicit signal and an explicit override.
The signal I use is the shape of the questions. If they are getting narrower — from why is this slow to why does this consumer only stall after a rebalance — the struggle is doing its job and I stay out. When the same question comes back in three different costumes, that is not learning any more, it is a loop. I set the limit before it starts. With a mentee working a bug in the pipeline last quarter I said: take it to end of day tomorrow, come to me at any point, and if you are still circling at that point we do it together. That sentence matters more than the duration, because it makes coming back the plan rather than a confession. He found it with about two hours left — a poison record being redelivered forever and quietly holding the consumer group behind it. I would not have got there faster in any way that mattered, and he now owns that whole area. I do override. During a month-end close a different mentee was two days into a stall while the backlog climbed past 43,600 records and finance was waiting. I took the debugging myself, narrated every step out loud, and we walked it again the next morning when nothing was on fire. The struggle is worth protecting; it is not worth other people's month end.
Strong because both halves are present and concrete: an observable signal, a timebox spoken aloud with the return made safe, and a named override where the cost had moved onto other people. The narration during the takeover keeps the teaching alive. It would downlevel if the override had no trigger or the intervention were only encouragement.
Personal instinct does not scale past the people you sit near, so I turned mine into a norm the group could run without me. Two things were going wrong at once: joiners sat stuck for days out of embarrassment, and seniors rescued them in ninety seconds because it was faster than teaching. What we adopted was simple and stated in every ramp document. Anyone stuck for more than an hour posts what they are trying and what they have ruled out, in the open channel — not a request for rescue, a status. And whoever answers first replies with a question before a solution. I asked the senior engineers to hold that second rule harder than the first, because it was the one that protected the learning, and I made a point of doing it visibly on my own threads when I was the one who was stuck. The effect I watched was not resolution time. It was that stuck posts stopped clustering on the same three people, and the median gap between someone getting stuck and saying so went from roughly a day and a half to under two hours. I also said out loud when we suspend it: during a live incident with a growing backlog, the norm is off and the fastest hand takes the work. Teaching resumes at the review.
The principal move is converting a judgment into a norm others can execute, with a deliberate suspension condition named. Modelling the behaviour on their own threads and measuring time-to-ask rather than resolution time both show system-level thinking. It would downlevel if it described only how the speaker personally handles a stuck mentee.
You will mostly be on the other side of this, and that is a fine answer: say what kind of help actually worked for you and what left you more lost. If you have helped a peer, show you asked what they had already tried before offering anything.
Show a working heuristic on your own feature scope: a rough time limit, a check on whether their questions are getting sharper or looping, and the habit of asking what they have ruled out before you answer.
Own the delivery risk in your answer. Say how you protect a mentee's struggle from schedule pressure, what you tell the people waiting on the work, and the case where you cut the struggle short because the cost had shifted onto customers.
Make it a norm rather than a personal instinct: an escalation convention people can follow without you, a stated struggle budget, and how you keep it alive when the group is under load. Say what the norm costs and when you suspend it deliberately.
saying these in an interview costs you the question
- Letting people struggle as a rite of passage rather than a judgment
- Taking the keyboard as the default intervention
- No stated signal, only a claim of reading the room
- Never overriding, even with customer impact on the line
- Framing the choice as tough love without naming any cost
- Rescuing so early the mentee never debugs anything alone
- Tell me about a time you got that call wrong.Have one ready in both directions if you can, but at minimum one honest miss: you rescued too early and they never learned the system, or you waited so long the work slipped and they lost confidence. Say what the miss cost and what signal you now watch that you were ignoring then.
- How do you explain the delay to whoever is waiting on that work?Show that you absorb the pressure rather than passing it to the mentee. Say you keep the commitment yours, flag risk early to the people downstream, and never frame the delay as the junior being slow. If the schedule genuinely cannot take it, that is a reason to change the assignment, not to hover.
- What do you do when they come back still stuck?Describe an escalation ladder rather than a switch: first ask what they ruled out, then narrow the problem with them, then pair with them driving, and only then take over — and if you take over, explain your reasoning aloud as you go so the session still teaches something.