Mentoring and Coaching Questions

Direct answer

I distinguish by pattern, not just output level. Burnout or disengagement usually shows up as a broad decline across previously strong areas, paired with a real change in energy or affect (a person's visible mood and emotional expression). A skill gap is usually narrower, tied to a specific type of task, and doesn't come with that affect change. Once burnout is suspected, the shift is from output-focused coaching to a wellbeing-first conversation and workload adjustment.

Distinguishing signals

The diagnostic move

Because the same output pattern (missed deadlines, lower-quality work) can come from either cause, guessing from behavior alone risks the wrong intervention. More skill-focused coaching aimed at someone who's actually burned out just adds pressure. The reliable move is to ask directly and non-accusatorially rather than only inferring, since it's the fastest way to tell the two apart.

What to do differently once suspected

Shift the conversation from task correction to workload and wellbeing. Reduce scope or redistribute urgent items in the short term rather than expecting normal output immediately. Check in more on process and how they're doing than on deliverables for a while. Point toward available support resources where they exist. Avoid escalating straight to a formal performance conversation while this is unresolved, but also avoid treating it as an indefinite excuse, set an actual review point to reassess rather than letting it run open-ended.

Worked example

A mentee whose work had been consistently strong started slipping across several unrelated tasks, not just one. The decline was recent and came with noticeably less participation in discussions, which pointed away from a narrow skill gap. A direct, private conversation surfaced an unsustainable workload building up over recent weeks. The short-term adjustment was reprioritizing their task list and explicitly deprioritizing anything non-urgent, with a check-in scheduled two weeks out to see whether things had actually improved rather than assuming they had.

Trade-offs and pitfalls

A common mistake is treating every dip in output as a skill or effort problem and escalating straight to a formal process. The stronger approach separates "can't" (skill), "won't" (motivation or disengagement), and "can't sustain right now" (burnout), because they call for different responses, while staying alert that a genuine performance issue can coexist with real burnout, one doesn't automatically rule out the other. It's also a pitfall to assume burnout excuses declining output indefinitely: there still needs to be a check-in cadence, and if it doesn't resolve, it may need to go beyond what a mentor alone can fix, involving a manager or people-ops rather than absorbing an open-ended situation solo.

Direct answer

Triage by urgency and impact first, protect your own deliverables with an explicit, communicated time-box, and convert repeat-pattern questions into reusable artifacts so future requests don't all cost you 1:1 time. Prioritization alone doesn't scale past a certain number of mentees; reusable resources are what let personalized-feeling mentoring keep up as the queue grows.

Triage and scaling approach

Triage each request on three axes. Is it blocking (them or someone downstream) versus a growth request with slack. How long would it actually take to unblock: a quick answer versus a real session. Is this a shape of question you've answered before, which is a signal to build something reusable rather than repeat yourself.

Route, don't just prioritize. Not everything needs to be you specifically. A growth-oriented question might be better answered by a peer with more direct expertise, freeing your time for things only you can unblock.

Time-box and communicate the SLA out loud. "I can give you twenty minutes now on the blocking piece; let's put the design question on tomorrow's slot" sets expectations honestly instead of leaving people guessing whether they've been deprioritized.

Build reusable async artifacts for repeat patterns. When you notice you've answered a variant of the same question more than once, that's the signal to invest in a recorded walkthrough, a short playbook, or an FAQ instead of repeating the synchronous session a third and fourth time. This is a genuinely different lever from prioritization: it lets you scale personalized-feeling help without your 1:1 time growing linearly with the number of people asking.

Maintain the artifacts deliberately. A playbook or recording that goes stale is worse than not having one, because people trust it and get misled. Whoever owns it, you or a rotating owner, needs a cadence to revisit and refresh it, not a one-time write-and-forget.

Worked example

You're juggling your own deliverable alongside three mentees asking for time at once: one is genuinely blocked, one has a growth-oriented design question with no real time pressure, and one is asking a version of a question you've now answered several times before. You give the blocked person a focused twenty minutes to unblock them. You schedule the design question for a defined slot the next day rather than squeezing it in now. And instead of walking the third person through it live again, you point them to an existing recorded walkthrough, or if one doesn't exist yet, you record a short one this time specifically because you can already tell it'll come up again.

Trade-offs and pitfalls

Treating every request as equally urgent burns you out and, worse, under-serves the person with the actually urgent need, because everyone gets a diluted amount of attention instead of the right amount going to the right place.

Over-investing in artifacts nobody maintains creates a different failure: a stale playbook actively misleads people and erodes trust faster than simply not having documentation and telling people to ask.

Prioritizing strictly by who's loudest or most urgent can systematically starve quieter mentees who don't escalate assertively. It's worth periodically checking who you haven't heard from, not just responding to who's asking.

If you find yourself using "I'll make you a doc" as a polite way to avoid ever giving someone real synchronous time, that's usually a sign the mentee queue has outgrown what one person can reasonably carry, and it's a resourcing conversation to raise with your own manager, not something to keep absorbing indefinitely.

Direct answer

Mentoring someone you rarely see combines deliberate async artifacts with narrow, well-prepared live time, but the shape of that changes further when the gap isn't just distance or time zone. Culture, hands-on skills that need physical access, and group settings each introduce their own specific friction that a generic "be more async" answer misses.

Baseline async toolkit

• Recorded walkthroughs instead of live explanations, so the reasoning survives the time-zone gap.
• Written runbooks and checklists instead of verbal context that only exists once.
• Threaded async status updates instead of live stand-ups.
• Infrequent, scheduled live time used for judgment calls and open questions, not status updates that could have been written down.

Culture, not just the clock

Mentoring across different cultural norms changes communication and feedback style, not only cadence. Direct, pointed critique that reads as normal in one context can read as harsh or face-threatening in another, and in some cultures a mentee may not push back or admit confusion even when they have it, because that would read as disrespectful. Adjustments: ask the mentee to restate feedback back in their own words to check it landed as intended, prefer written feedback they can process privately over being put on the spot verbally, and actively invite disagreement rather than assuming silence means agreement.

When the skill is physical or hands-on

If the mentee can't access the same lab, hardware, or physical setup the mentor has, a video call alone doesn't transfer the skill, no matter how much conversation happens. Workarounds: remote access into shared real hardware or a virtual lab where one exists, high-fidelity recordings of the technique from multiple angles, and having the mentee submit their own attempt as recorded evidence (video, logs, output) for asynchronous review as a substitute for watching over their shoulder. The honest answer names this as a real limitation rather than pretending remote conversation is equivalent.

Facilitating a remote group, not just a 1:1

Running a remote group critique is a different skill from managing 1:1 async cadence. It needs explicit turn-taking since silence reads very differently on a call than in a room, a written artifact everyone reviews beforehand so live time goes to discussion instead of a first read, and deliberately calling on quieter participants, since remote settings tend to amplify whoever is already most comfortable speaking up.

Worked example

Mentoring someone with only a narrow daily overlap window involved recorded walkthroughs for anything routine, and reserving the one live weekly slot purely for judgment calls that didn't compress well into writing. Early feedback delivered directly and pointedly in that format landed harder than intended, since it read as more severe without the in-person context to soften it. Shifting to written feedback they could sit with, followed by an open question in the next live slot, got a much more honest back-and-forth than direct verbal critique had.

Trade-offs and pitfalls

A common mistake is treating "remote" as one problem solved by one toolkit, more meetings or better docs, regardless of what's actually causing the friction. The stronger answer separates distance, time zone, culture, physical access, and group dynamics, and picks a fix matched to the actual friction rather than a generic one. Assuming a video call is a full substitute for hands-on access is a specific version of this mistake worth naming explicitly.

Direct answer
The strongest mentoring story names a concrete starting point (not "they were new," but what specifically they didn't yet know or couldn't yet do), describes what you actually did differently because of that starting point, and points to a real change in what the person could do independently afterward as the evidence of growth, not just that time passed or that they were nice about it.

Structured elaboration

What "starting from" should actually specify

Vague ("they were junior") is weak. Specific ("they could write correct code but always needed help scoping the actual problem before writing it") is strong, because it sets up a real before and after.

What "what you did" should show

The interesting part isn't a list of activities (pairing, reviews, 1:1s); it's the judgment behind them: why you chose that particular intervention for that particular gap, and what you adjusted when the first approach didn't fully work.

What "how you know they grew" should show

This is the part candidates under-answer. Two things separate a senior answer here:

• Independence as the real signal, not sentiment. The strongest evidence isn't "they thanked me," it's a concrete example of them handling something on their own that they previously couldn't, ideally something you didn't have to prompt.
• Reframing your own impact as leverage, not personal output. A senior candidate can articulate that developing someone else who can now independently do the work is a multiplier on team capacity, arguably more valuable than the same hours spent on your own individual output, because it compounds. That's a different, and stronger, claim than "I helped someone and it felt good."

The real tension: mentoring time vs. delivery

Mentoring genuinely competes with your own delivery time, especially early in a relationship when the payoff hasn't materialized yet. A senior answer is honest about this rather than pretending mentoring is free: it names a moment where mentoring time actually cost something (a deadline got tighter, you did more of the work yourself that cycle) and explains the judgment call for when it's right to deliberately scale mentoring back temporarily to protect a real deadline, versus when protecting the mentoring time is the higher-leverage call even under pressure.

Worked example

Situation

I mentored someone who was technically capable but consistently needed help before they'd start: given an ambiguous problem, they'd wait for someone to scope it into clear steps rather than attempting that themselves.

Action

Instead of continuing to scope tasks for them, I deliberately started handing over problems one level more ambiguous than they were comfortable with, then worked through their proposed scoping with them afterward rather than before, so the struggle happened on their side first. Early on this slowed things down, and I redid some of their scoping myself before it went further, which cost real time on a couple of deadlines.

Result

Over time the gap between their first attempt at scoping and a workable plan narrowed, until they were handling genuinely ambiguous problems without needing that step from me at all. The clearest evidence wasn't a compliment, it was a specific instance of them independently scoping and delivering something ambiguous while I was out, without anyone asking them to check with me first.

The trade-off moment

Partway through, we had a hard deadline where I made a deliberate call to scope their next task myself rather than continuing the hands-off approach, because the team couldn't absorb the risk of a slower first pass that cycle. I was explicit with them about why, so it didn't read as a loss of confidence in them, just a temporary trade-off.

Trade-offs & pitfalls

• Confusing activity with growth. Listing pairing sessions and 1:1s isn't evidence of anything; a senior answer points to a specific, observable change in independent capability.
• Never naming the cost. A story where mentoring never competed with anything else usually isn't a very real story. Naming a moment you scaled it back, and why, is more credible than claiming it was free.
• Missing the leverage framing entirely. Describing mentoring purely as "helping a nice person" misses the stronger claim: that growing someone else's independent capability is a real multiplier on what the team can deliver.

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.