Unblocking a Junior Without Taking the Keyboard

TL;DR — Taking the keyboard solves the ticket and costs the engineer. Diagnose the kind of stuck first: a missing fact (tell them immediately — the Socratic method here is just a quiz), an unrankable choice (shrink the option space, make them pick), a missing debugging method (narrate yours out loud, including the boring parts), missing permission (the most common and least recognised — say "do it, I'll back you"), or a genuinely hard problem (pair, at their keyboard). Set a stated timebox so asking is process rather than confession, and when you do drive, hand it back before the fix.

Why "let me just—" is expensive

You solve it in four minutes. The ticket moves. Everybody's happy, and three things quietly happened:

They didn't build the search path, so the next instance of this problem is also a four-minute interruption for you. They learned that being stuck ends when someone senior arrives, which makes asking earlier the rational strategy and independence irrational. And they watched you do something at a speed that looked like magic, which mostly teaches them how far behind they are.

None of that means "never help". It means the form of the help is the entire decision, and the form should follow the diagnosis.

The five kinds of stuck

1. Missing a fact

They don't know collectAsStateWithLifecycle exists, that Hilt needs @AndroidEntryPoint on the Activity, or that the emulator can't reach localhost.

Tell them. Straight away. Then, in one sentence, where you'd have found it: "the Compose lifecycle docs page, or grep the codebase for other collect sites."

Running a discovery exercise on a missing API name is not mentoring. It reads as a quiz, it wastes an hour, and — this is the part people underestimate — they can tell you already know the answer. That erodes trust in the times you genuinely don't know.

2. Stuck on a choice

Four viable approaches, no experience to rank them, so nothing gets picked. The failure here is silent: it looks like slow progress, not like being blocked.

Don't add a fifth option, and don't decide for them. Shrink the space and hand the decision back:

"It's the ViewModel or the repository. Pick one and tell me why. I'll tell you if it's a disaster — it probably isn't."

Then support the choice even when it's the one you wouldn't have made, if it's within tolerance. A reversible decision made by them beats an optimal decision made by you, because next time they'll decide without the meeting.

Two questions that make the ranking learnable: "which one is easier to undo?" and "which one would you rather debug at 2am?"

3. Missing a debugging method

The highest-value hour you can spend, because they're not missing an answer — they're missing a procedure, and a procedure transfers to every future bug.

Narrate yours out loud, including the parts that feel too obvious to say:

What did you expect to happen?
What actually happened?
What's the smallest difference between those two?
What's the cheapest experiment that halves the search space?

Say the boring steps. "I'm checking whether it's even reaching this function, because if it isn't, everything downstream is irrelevant." That sentence is the method. Experts skip it out loud because it's automatic, and skipping it is exactly why watching an expert debug teaches so little.

Do it at their keyboard, with them typing. You describe the next step; they execute it. Slower, and the only version that transfers.

4. Missing permission

The most common kind with juniors, and the one seniors misread most often. They already know the fix. They think it's too big, too invasive, or not their place: the function needs renaming, the abstraction needs deleting, the "temporary" workaround from 2023 needs to go.

They present it as a technical question. It isn't:

"Do it. I'll back you in review."

Watch for the tell — a solution described in a lowered-stakes voice, hedged with "this is probably stupid, but…". That sentence almost always precedes the correct answer, and if you hear it three times from the same person, the problem is the environment, not them.

5. Genuinely hard

Some problems are hard: a race condition in a legacy sync engine, an OEM-specific bug with no documentation, a build failure with three plausible causes.

Pair for real — an hour, blocked calendar, no laptop lid half-open. Still at their keyboard. Here your value is holding the state of the investigation ("we ruled out the cache at 2pm") while they do the mechanical work, which is exactly the part that's hard to do alone.

Three habits that beat all the technique

Ask what they expected. "What did you expect to happen, and what happened instead?" A third of problems dissolve while they're answering, because the question forces the comparison they'd been skipping. It also tells you instantly which of the five you're in.

State a timebox as team policy. "Stuck for 30 minutes with no new information? Ping someone." Say it publicly, apply it to yourself, and ask for help in the open channel yourself. Now asking is process rather than confession — and the reason juniors sit stuck for three days is never that they don't want help, it's that asking felt like a status event.

Never fix it overnight to be nice. The engineer who logs in to a solved ticket learns that they were too slow to matter. If you find the answer late, leave a comment with the lead, not the fix: "I think it's the interceptor ordering — have a look tomorrow." They still get the win.

And when you genuinely must drive: hand it back before the fix. Diagnose together, then let them type the change. Whoever types it is who learned it.

The follow-up nobody does

Two days later: "Can you explain that bug to me? I want to make sure I actually understood it."

You're not checking on them; you're making them reconstruct the reasoning, which is what moves it from recognition to recall. It takes five minutes and does more than the original session. It also gives you an honest measure of whether your help landed — if they can't reconstruct it, you solved it and they watched.

The rule

Your job is to make the next one solvable without you. A ticket unblocked in four minutes and an engineer who's still stuck is a bad trade you can make indefinitely without noticing, because the metric it damages — how often people need you — looks like importance.