Mentoring and Coaching Questions

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

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
Ramping someone from day one to their first shipped work is a deliberate sequence, not a single onboarding checklist: assess what they actually already know, give them small real tasks with tight review loops before a full feature, gradually widen the scope of ownership, and define upfront what "shipped" and "done" mean so the finish line is unambiguous. The plan should look different depending on who's arriving, not just be a fixed template applied to everyone.

Structured elaboration

The default arc

• First few days: orient and assess. Don't assume a blank slate; find out what they already know so you're not re-teaching things or, worse, skipping things they actually need.
• Early tasks: small, real, low-blast-radius work with fast, close review. The goal here is confidence and calibration to the team's standards, not speed.
• Middle stretch: progressively larger scope with more independence, review shifting from "check everything" to "check the risky parts."
• First real shipped piece: something end-to-end they own, with you available but not doing it alongside them, and a clear definition of "done" agreed before they start, so success isn't a moving target.

Adapting the plan to who's actually arriving

This is where a generic checklist breaks down, and it's the part that separates a senior answer:

• A contractor under least-privilege or compliance constraints: access is scoped down from day one, so the plan has to work around what they legitimately can't see or touch, and documentation often needs to be more explicit since they can't casually ask around as easily as a full-time hire embedded in the org.
• A career-changer from an adjacent discipline (a backend engineer moving into data engineering, a research scientist moving into production ML): they're not a blank slate, they have real transferable skills. The plan should explicitly identify what carries over and target ramp-up specifically at the actual new-domain gaps, not restart from zero the way you would for someone with no relevant background.
• A cohort of remote interns rather than one hire: 1:1 pairing time doesn't scale to a group. The plan shifts toward a shared structured curriculum, peer learning between the interns, and scheduled office hours, with 1:1 time reserved for the things that genuinely need it.
• A remote hire versus a senior IC joining: a remote hire needs more of everything written down explicitly, since the informal hallway learning that fills gaps for an in-person hire doesn't happen by accident. A senior IC's gap is usually organizational context and relationships, not raw skill, so their plan should be lighter on procedural scaffolding and heavier on introductions, context on how decisions get made, and where the landmines are.

Worked example

Situation

I mentored someone joining as an individual contributor with solid general skills but no exposure to our specific stack or codebase, with a goal of them shipping one real, complete piece of work within their first several weeks.

Action

Week one was mostly orientation and a short assessment task to see where they actually stood, not a generic reading list. From there, I gave them a small real bug fix with a tight review loop so they got fast, specific feedback on our conventions early, before those habits calcified the wrong way. Over the following weeks the scope widened: a small self-contained feature with me reviewing closely, then a larger piece with me available but stepping back from line-by-line review, focusing instead on the riskiest parts of the design.

Result

They shipped a real, complete piece of work end-to-end within the target window, with a review pass that looked much closer to how we review any other team member's work by that point, which was the actual signal of readiness, not just that the calendar had passed.

Trade-offs & pitfalls

• Treating every new hire's plan as the same template. A junior mentor runs the same onboarding for a contractor, a career-changer, an intern cohort, and a senior IC. A senior mentor adapts the shape of the plan to who's actually arriving, because the actual gap being closed is different in each case.
• Under-scoping early tasks out of excessive caution, or over-scoping out of impatience. Both undermine the confidence-building purpose of the early stretch: too small and it's condescending or boring; too large too soon and the first review becomes overwhelming and demoralizing.
• Not defining "done" up front. Ambiguity about what counts as finished either causes needless rework or lets something ship that isn't actually ready, and both erode trust in the mentoring relationship.
• Ignoring the constraints a nontraditional hire is actually operating under. Applying a full-access, in-person, junior-IC plan to a least-privilege contractor or a remote hire sets them up to fail on logistics that have nothing to do with their actual skill.

Direct answer

I track a mix of leading indicators I can observe soon and lagging outcome indicators that take months, and I treat any single outcome metric with real suspicion, because most of the obvious ones have confounders that have nothing to do with the mentoring itself. If it isn't working, the signal usually shows up in behavior long before it ever shows up in an outcome number.

Leading indicators (fast, but softer)

• The mentee proactively brings a problem before being asked, rather than only responding when prompted.
• They apply a technique from an earlier conversation without being reminded.
• They can articulate their own reasoning, not just repeat a conclusion.
• They start contributing to others, a strong late signal that something has actually been internalized rather than just followed along with.

Lagging indicators, and why they alone are not enough

Promotion, retention, and performance rating movement all matter, but none of them are clean measures of mentoring on their own. Promotion timing is affected by team budget, level-bar changes, and reviewer variance, not just capability growth. Retention is affected by pay, personal circumstances, and the direct manager relationship, often far more than by a mentoring relationship. Treating either as a dashboard number risks giving mentoring false credit when someone would have succeeded anyway, or false blame when the real cause was entirely outside the relationship. That's the reason to pair outcome numbers with direct, harder-to-fake behavioral signals rather than reporting them alone.

Telling it isn't working, and what to do

Signs it's not working: no observable change in independence over a reasonable window, the mentee still routes every decision through you, flat or disengaged body language in 1:1s, or the mentee saying directly that it isn't useful. Once suspected: ask directly rather than only inferring from behavior, check for a format mismatch (wrong cadence, wrong topics, or the mentee not feeling safe raising what's actually going on), adjust before assuming failure, and if the mismatch is genuinely personal rather than fixable, consider a different pairing without treating that as anyone's fault.

Worked example

After several weeks, a mentee was still checking in before making small, reversible decisions that should have been theirs to make. Rather than assuming a skill gap, a direct conversation surfaced that the actual blocker was fear of being wrong, not lack of ability. The adjustment was explicit permission to make a defined class of reversible decisions without approval, plus a standing offer to review the reasoning after the fact rather than before. Over the following sessions, they started making more of those calls on their own and explaining the reasoning unprompted.

Trade-offs and pitfalls

A junior answer to this question is usually a list of KPIs and stops there. A stronger answer explains why the obvious outcome metrics can lie, and pairs them with behavioral signals that are harder to fake. A common pitfall is over-attributing outcome metrics to the mentoring relationship (selection bias: motivated people who get assigned strong mentors were often already on a good trajectory). Another is waiting too long to check in because outcome metrics take a quarter or more to move, by which point a struggling relationship may have already quietly failed.

Direct answer
Coaching a genuine underperformer starts with diagnosing why (skill gap, unclear expectations, motivation, or something outside work like a health or personal issue) before assuming it's a will problem, then moving to a private, honest conversation with specific examples, a written and time-bound improvement plan with objective checkpoints, and a clear, stated understanding of what happens if the bar still isn't met. The hard part isn't the first conversation, it's staying honest and consistent through every checkpoint after it.

Structured elaboration

Diagnose before you coach

Below-the-bar performance has different root causes that call for different responses:

• Skill gap: they don't yet know how to do the thing. Response: targeted teaching, pairing, smaller scoped tasks.
• Unclear expectations: they don't know what "good" looks like here. Response: make the bar explicit and concrete, with examples.
• Motivation or engagement: they can do it but aren't. Response: a more direct conversation about what's changed and why.
• Something outside work: a health issue, a personal crisis, burnout. A private, non-judgmental check-in on wellbeing belongs early in this process, both because it's the right thing to do and because it changes what the right intervention is (support and possibly a formal accommodation, not a performance plan).

Getting this wrong (coaching a skill gap like it's a motivation problem, or the reverse) wastes the improvement window on the wrong intervention.

The conversation and the plan

• Deliver the message privately, plainly, and with specific examples: what's below the bar, what the bar actually is, and why it matters.
• Put the plan in writing: two or three concrete, observable goals, a defined timeframe, and what evidence would count as "met."
• Set a regular check-in cadence shorter than your normal 1:1 rhythm; below-the-bar performance needs tighter feedback loops, not the same cadence as everyone else.

When to involve HR formally

This is a judgment call many candidates get wrong by either never mentioning HR (naive) or looping HR in immediately (overcautious, and it can undermine trust). A reasonable line: loop in HR or your manager as soon as the conversation could plausibly lead to a formal employment outcome (a documented warning, or separation), even if you're optimistic it won't get there, because that's exactly when documentation and process need to be right from the start rather than reconstructed after the fact.

Protecting the team

The rest of the team usually already knows something is off; silence reads as either denial or unfairness. Without disclosing private performance details, it's reasonable to acknowledge you're aware of the gap and are addressing it, and to be transparent about redistributing work if needed, so the team doesn't quietly conclude the issue is being ignored.

Worked example

Situation

An engineer on a team I was supporting had been reliably strong for over a year, then their output quality and delivery reliability dropped off sharply over a couple of months: reviews were taking longer, deadlines were slipping, and the pattern didn't match a normal bad sprint.

Diagnosis

Before assuming a motivation problem, I had a private, low-pressure conversation focused on checking in rather than accusing. That surfaced that part of the issue was a skill gap on a newer part of the codebase they'd been assigned to without much ramp-up, but there was also something going on outside work affecting their focus.

Action

We set a short, explicit improvement plan: two concrete, observable goals tied to real upcoming work, a shorter check-in cadence, and pairing time on the unfamiliar codebase area. I also made sure they knew about the option to talk to HR about support resources for the personal situation, kept separate from the performance conversation so the two didn't get conflated.

Result

Performance recovered within the plan's window once the skill gap closed and the external situation stabilized. Because the conversation started from genuine diagnosis rather than an assumption, the plan addressed the actual cause instead of just adding pressure, and the person stayed on the team and rebuilt trust with the group.

The other branch (when it doesn't turn around)

Not every case ends this way. When someone doesn't meet a documented plan's criteria despite real support, the path is a harder, well-documented conversation, formal HR involvement, and eventually separation if there's no path forward. The mentor's job at that point shifts from "close the gap" to making sure the process is fair, well-documented, and handled with dignity, and to being honest with the rest of the team (without violating privacy) that a change is coming so it doesn't land as a surprise.

Trade-offs & pitfalls

• Treating every case as a motivation problem. The single biggest junior mistake here is skipping diagnosis and going straight to "try harder" messaging, which fails skill-gap and external-cause cases and can be actively harmful if there's something like burnout or a health issue underneath.
• Involving HR too late (or too early). Too late, and you've lost the documentation trail that protects everyone, including the underperformer, if it does become formal. Too early or too visibly, and it can read as punitive before the person's had a real chance, damaging trust unnecessarily.
• Optimizing for the individual at the team's expense, or the reverse. A senior answer holds both: real support for the person, and honesty with the team about workload and timeline impact, rather than pretending nothing's happening.
• No exit criteria stated up front. A plan without a clear "what does not-met look like, and what happens then" isn't actually a plan, it's a delay, and it's unfair to the person because they don't know what they're actually being measured against.