Mentoring and Coaching Questions

Direct answer

Default to a diagnostic question or a hint first, since that's the cheapest intervention and preserves ownership of the solution. Escalate to pairing when hints aren't moving them or they're clearly missing a building block they can't discover alone in reasonable time. Reserve stepping in directly for cases bounded by a hard constraint: a real deadline, cost, safety issue, or someone else being blocked by their block.

Decision framework

Start with a diagnostic question, not a hint. "What have you tried, and what's your current hypothesis?" tells you whether they're missing information, missing a concept, or just haven't structured their attempts yet. This costs almost nothing and often unblocks people on its own.

Escalate to pairing when the pattern repeats. If they're cycling through the same failed approach without adjusting, or they're missing a conceptual piece they genuinely can't discover unaided in the time available, sit with them. Let them keep driving; you're there to redirect attention, not take over.

Escalate to stepping in directly only under a real constraint. A hard deadline, a cost or safety issue, someone else waiting on this to move, or clear signs of demoralization (not just frustration) are the legitimate triggers. "I could solve this faster myself" is not one of them; that's true of almost every delegation ever made.

Time-box the struggle explicitly. Instead of leaving it open-ended, agree on a checkpoint: "take another thirty minutes with this angle, then let's regroup regardless of where you land." This protects both their learning and the actual delivery timeline.

Debrief after any intervention, at any level. Even a small hint deserves a quick "here's the reasoning trap you were in" afterward, so the moment converts into a transferable lesson instead of just an unblock.

Worked example

Someone you're mentoring has been stuck for a while and comes to you for help. You ask what they've tried and what they currently believe is going wrong. Their answer reveals a specific reasoning gap, not a knowledge gap, so you give a pointed hint rather than the answer itself. They make progress but hit a second wall later, closer to a real deadline, and this time you sit down and pair with them directly, letting them stay at the keyboard while you ask redirecting questions. Once it's resolved, you debrief separately from the fix itself: what was the actual reasoning trap, and what's the general takeaway for the next similar problem, distinct from the specific bug.

Trade-offs and pitfalls

Defaulting to stepping in because it's faster erodes the person's own problem-solving muscle over time and can create a pattern where they escalate immediately instead of trying, because they've learned help arrives fast if they ask.

Refusing to intervene out of a rigid "let them struggle" stance burns real time and morale, and can backfire if they land on a fragile or outright wrong solution through persistence rather than understanding, and you didn't catch it.

The honest trade-off with hints: they preserve the person's ownership of the solution, but they slow things down and risk letting someone loop past the point where struggle is still productive into the point where it's just frustration with no learning attached.

A subtler failure mode worth naming: a "hint" that's actually the answer in disguise. It looks like coaching and feels generous, but the person doesn't actually earn the insight, and you won't be able to tell the difference from watching them succeed.

Direct answer
A stretch assignment only works as a growth tool if it's picked deliberately (real stakes, but survivable if it goes wrong), supported actively rather than handed off and hoped for, and evaluated by whether the person can now do something they genuinely couldn't before, not just whether the project shipped.

Picking the assignment

• Look for the specific gap between where someone is and where they want to go, and pick something that exercises exactly that gap: not a bigger version of what they already do well, but the thing they haven't had to do yet (leading ambiguity, owning a stakeholder relationship, making a judgment call without a clear right answer).
• Sanity-check the blast radius: a good stretch assignment has real consequences if it goes wrong, but not consequences the team or the person can't absorb. If failure would be catastrophic, it's not a stretch assignment, it's a bet you shouldn't be making on someone's first attempt.

Supporting through it

• Set explicit checkpoints rather than open-ended availability; someone stretching is often reluctant to ask for help exactly when they need it most, because asking feels like it undercuts the point of the assignment.
• Watch actively for the failure mode where the person becomes overwhelmed or delivery risk climbs mid-assignment. The fix isn't to quietly take it back (that undoes the growth and teaches them stretch assignments are a trap), it's to scope down the ask while keeping ownership intact: shrink the surface area, extend the timeline, or bring in narrow support on the hardest sub-piece, while the person still owns the outcome.

Knowing it worked

• The real signal isn't whether the deliverable shipped; plenty of stretch assignments succeed despite the person, propped up by others. The signal is whether they can now do a similar thing again with meaningfully less support than before.
• Ask them directly what they'd do differently next time; someone who's actually grown from it usually has a specific, concrete answer, not a vague "it was good experience."

Variants worth having ready

• Succession-driven: when someone owning a critical piece of the system is leaving, a stretch assignment can double as a deliberate handoff, usually spread across two or three people rather than one, so the knowledge doesn't just move from one single point of failure to another.
• Developing a mentor, not just a mentee: a technically strong senior who's never mentored can be given a stretch assignment that's explicitly about teaching, not delivery, such as owning a junior's ramp-up plan with the growth of the junior, not the speed of the project, as the success measure.

Worked example
A strong individual contributor wanted to grow into leading larger, more ambiguous work but had only ever executed against fully-scoped tasks. Rather than a bigger version of the same kind of work, the assignment was to own a smaller, genuinely under-scoped project end to end: figure out the actual requirements from a vague ask, make the technical calls, and report progress upward directly instead of through a lead. Support looked like a standing short weekly check-in (not daily oversight) and an explicit agreement that they'd flag it early if they felt stuck, rather than waiting until a deadline made the risk visible.

Partway through, the scope turned out to be bigger than either of us expected, and the person started showing the classic overwhelmed signs: shrinking updates, slipping the weekly check-in. Rather than pulling the project back, the assignment was rescoped down to the highest-value piece, with the harder edge case handed to someone else, while they kept ownership of the core decision and the delivery. They finished a smaller version of the original ask, and more importantly, on the next ambiguous piece of work a few months later, they scoped it themselves without needing the same weekly check-in structure. That second instance, done with much less support, was the actual evidence the stretch assignment had worked, not the fact that the first project shipped.

Trade-offs and pitfalls

• Picking a stretch assignment that's really just "more of the same, but bigger" doesn't build a new skill; it just tests stamina.
• Quietly rescuing someone the moment they look overwhelmed (taking the assignment back rather than rescoping it) protects the deliverable but teaches the person that stretching is unsafe, which discourages them from taking the next one.
• Measuring success by whether the deliverable shipped, rather than by what the person can now do independently, rewards you propping the project up rather than the person actually growing.

Direct answer

Mentoring is voluntary, growth-oriented influence without formal accountability. Managing includes formal accountability, resourcing decisions, and real consequences. The line moves the moment a mentee becomes a direct report, because feedback that used to be optional advice now carries formal weight, and the relationship gains structural power (comp, promotion, performance record) it didn't have before.

Where the line actually is

What changes when a mentee becomes a direct report

Private growth conversations now double as input to a formal review, whether that's said out loud or not. Advice that was previously optional is now, in practice, expected to be acted on for role reasons. The relationship carries real structural power (comp, promotion, PIP, short for performance improvement plan: the formal HR process for addressing underperformance) that it didn't have as informal mentoring. The hardest part is that "helping you grow" and "evaluating you" now happen with the same person, often in the same conversation, and separating those framings requires being deliberately transparent about which one is active at a given moment, rather than assuming the mentee can tell.

Worked example

A mentee who'd been mentored informally for a while later became a direct report after a reorg. The explicit adjustment made on day one: naming that some future 1:1 time would now include performance topics, not only growth topics, and being upfront about which kind of conversation was happening in the moment, rather than letting the mentee guess which hat was on.

Trade-offs and pitfalls

A common mistake is continuing to run the relationship exactly as before once it becomes formal, without naming the shift, which reads as inconsistent or even manipulative once the mentee realizes "informal advice" now affects their review. A stronger approach names the shift explicitly rather than letting the mentee discover it the hard way. Another pitfall is using "I'm just mentoring you" framing to soften what is actually a directive, formal expectation, which blurs accountability for both sides.

Direct answer
My mentoring approach starts from diagnosing where someone actually is, not applying one fixed style, and it balances technical guidance with career development by treating them as two separate but connected tracks: technical guidance closes the gap between where they are and what the work in front of them needs right now, while career conversations look further out at where they're trying to go. The mix between the two shifts substantially depending on how experienced the person already is.

Structured elaboration

Diagnosing before applying a style

The first move with any new mentee is figuring out their actual starting point and goals, not assuming based on title or tenure. Two people at the same level can need very different things: one might need technical unblocking, another might already be technically strong but stuck on visibility or scope.

Balancing technical guidance and career development

• Technical guidance tends to dominate early in a relationship or when someone's working in genuinely new territory; it's concrete, has fast feedback loops, and builds the trust that makes career conversations land later.
• Career development becomes a larger share of the time as technical competence stabilizes; someone who's already reliable on the day-to-day work benefits more from conversations about scope, visibility, and where they're headed than from more line-by-line guidance.
• The two aren't fully separable in practice: a well-run technical conversation often surfaces the real career question underneath it (they're not struggling with the code, they're struggling with whether this kind of work is even what they want to be doing).

How the approach changes: newer teammate vs. experienced one

• A newer teammate typically needs a tighter structure: explicit expectations, closer review, and a higher ratio of technical to career conversation, because there usually isn't yet a track record to have a grounded career conversation about.
• A more experienced teammate usually needs the opposite ratio: less hands-on technical guidance (often none at all on execution, more on judgment calls and trade-offs), and more time spent on career and scope, sometimes including the expectation that they take on some mentoring of their own, since that's often the actual next step in their growth.

Worked example

Applying the philosophy

With a newer teammate, most of an early 1:1 might genuinely be spent walking through a specific technical decision they made, only pivoting to career topics once they'd built enough of a track record to have something concrete to talk about. With a more experienced teammate on the same team, the same 1:1 slot might be spent almost entirely on a scope or visibility question, with technical guidance limited to a quick sanity check on a hard trade-off they'd already mostly worked out themselves.

Signal of it working

The clearest sign the ratio was right in either case wasn't a specific number, it was whether the conversation actually used the full time productively: a newer teammate's 1:1 running long on technical questions because they had real ones was a good sign; the same happening with an experienced teammate, repeatedly, usually meant something else was being avoided, often a harder career conversation neither of us had opened yet.

Trade-offs & pitfalls

• Applying the same ratio to everyone regardless of experience. A fixed philosophy that doesn't flex by seniority isn't really a philosophy, it's a script, and it under-serves experienced mentees while potentially overwhelming newer ones.
• Letting technical conversations become a permanent default because they're easier. Technical questions have clear right answers and fast feedback; career conversations are ambiguous and can feel uncomfortable. A senior mentor notices when technical talk has become an avoidance pattern rather than what's actually needed.
• Treating career conversations as an occasional add-on rather than a real track. If career development only comes up during formal review cycles, it usually means the day-to-day mentoring relationship isn't actually addressing it.

Direct answer
A mentoring relationship going badly is rarely one big failure; it's usually a slow accumulation of choices, like taking on too much of the work yourself to protect the outcome, that quietly undercut the mentee's growth. The honest answer names a specific relationship, is candid about what you did (not just what the mentee did), and shows what changed in how you mentor afterward.

What "went badly" usually looks like

• Common patterns: being too directive and doing the hard parts yourself to protect delivery; giving feedback too infrequently or too late to be actionable; misjudging the mentee's actual gap (treating a confidence problem as a skill problem, or the reverse); or disengaging when the relationship got effortful.
• A strong answer picks one specific pattern and owns your part in it, rather than a vague "they weren't a good fit."

What separates a senior answer from a junior one

• Junior answers blame the mentee ("they just weren't receptive") or stay abstract ("communication could have been better"). Senior answers identify a decision you made and trace its actual effect: what you did, what it produced, and why it made sense to you at the time even though it was wrong.
• Senior answers also show what changed structurally afterward, not just an apology or a resolution to "communicate better." Concrete changes: an explicit mentoring agreement up front, checkpoints instead of open-ended availability, deliberately handing over ownership even when it's slower.

How to close it out

• End on what you'd do differently now, stated specifically enough that it's clear you'd actually behave differently in the next relationship, not just that you feel bad about the last one.

Worked example
During a stretch project with a hard deadline, I mentored a junior engineer by taking over the riskiest parts myself rather than coaching them through it, to keep the timeline safe. That worked in the short term, but it meant they never built confidence handling ambiguity or incidents on their own, and toward the end of the project they told me directly that they felt sidelined rather than developed. That was the moment it became clear the relationship hadn't done what I'd intended, even though the project itself shipped fine.

What I changed afterward: instead of stepping in when something got risky, I started requiring myself to narrate my reasoning out loud and have the mentee drive, only taking over if there was a genuine, immediate risk. I also set an explicit checkpoint (a short regular sync, not just "come find me") so growth stalls would surface early instead of only becoming visible at the end of a project. The relationship after that wasn't measured by how smoothly the project went; it was measured by whether the mentee could handle the next similar situation without me in the room, which is a slower thing to build but the actual point of mentoring.

Trade-offs and pitfalls

• The tempting failure mode is optimizing for the deliverable (visible and rewarded) at the expense of the mentee's growth (slower and less visible), especially under deadline pressure.
• Being self-critical is necessary but insufficient; an answer that's all remorse with no concrete process change reads as unreflective in a different way.
• Watch for over-correcting into never stepping in, which just replaces one failure mode (too directive) with another (abandoning someone to a mistake they can't yet recover from alone).