Mentoring and Coaching Questions
Growing individual engineers and teammates through one-on-ones, coaching conversations, and hands-on technical mentorship. Covers tailoring guidance to the person, coaching versus telling, unblocking and stretching people, and measuring the impact of mentorship on someone's growth. The single largest behavioral cluster in the category.
Explain a coaching framework you use, like the GROW model or Socratic questioning, and walk through how you'd apply it in a real one-on-one with someone who wants to grow a specific skill.
Sample Answer
Direct answer
GROW is a four-stage, question-led coaching structure: Goal (what success looks like), Reality (the current state), Options (possible paths forward), and Way forward (specific commitments). Applied to a 1:1 with someone who wants to grow a specific skill, it turns a vague aspiration into a concrete next step, and the same question-led habit also works inside a work review, not only a scheduled conversation.
Walking through the four stages
- Goal. Get specific: "What would 'better at this' actually look like, concretely, and how would you know it happened?"
- Reality. Surface the current state without judgment: "Tell me about a recent situation where this was hard, what made it hard?"
- Options. Generate paths rather than prescribing one: "What could you try next, and who or what could help?"
- Way forward. Get a specific, small commitment: "Which one thing will you actually do before we talk again, and what support do you need from me?"
Socratic questioning is the companion technique that runs through all four stages: instead of stating the answer, ask a question that leads the person to notice the gap themselves ("what did you expect to happen there, versus what actually happened?"). It works well when there's time to let someone arrive at the insight; it works poorly when someone is genuinely blocked and just needs the direct answer.
Extending this into reviewing someone's work
The same question-led approach makes a review of someone's work (code, a document, a design, an analysis) constructive rather than purely corrective. Concrete techniques: a review template that separates "must fix" from "worth considering" from "just for your awareness," so feedback doesn't read as one undifferentiated pile of criticism; annotated examples that show a better version alongside the original with a short reason, not just a comment naming the problem; and a Socratic question left in the review itself ("what happens here if this is empty?") instead of stating the bug outright, when the goal is teaching and there's no urgency forcing a direct fix.
Worked example
In a 1:1, a mentee said they wanted to get better at making structural decisions independently instead of always checking first. Goal: they described what "independent" would look like in practice (making a defined class of calls without asking). Reality: walking through a recent case, they could explain their reasoning but hadn't trusted it enough to act without confirmation. Options: they proposed trying it on a low-stakes decision first and reviewing the reasoning after the fact rather than before. Way forward: they committed to making the next reversible decision on their own and bringing the reasoning to the following session, with an explicit offer of support if it went wrong.
Trade-offs and pitfalls
A common mistake is treating GROW as a rigid script and marching through all four stages regardless of what the person actually needs that day. A stronger approach holds the structure loosely: skip Reality if it's already obvious, compress stages under time pressure, and know when the moment calls for direct answers instead of more questions, especially if something is safety-critical or urgent. Inside reviews specifically, overusing Socratic questions when someone is genuinely stuck can read as withholding rather than teaching, so it's worth pairing questions with a clear direct answer once the teaching moment has been made.
How do you decide what to delegate to someone you're growing versus what you keep for yourself? Walk through how you use delegation deliberately as a coaching tool.
Sample Answer
Direct answer
Decide what to delegate by looking at two things: where the task sits relative to the person's current skill level, and what happens if they get it wrong. Delegate work that stretches them but is reversible or cheap to fix. Keep for yourself work that needs context you can't hand off in time, decisions whose blast radius exceeds the trust you've built with this person so far, or one-off tasks where teaching would take longer than doing it. Treat each handoff as a deliberate intervention, not an offload: pick the task for the specific gap it targets, define what "done" looks like up front, and calibrate how much support comes with it.
Decision framework
Match difficulty to their zone of growth. Too easy and it's busywork with no development value. Too hard with no support and it's discouraging or risky. The sweet spot is a task just past what they've done independently before.
Weigh reversibility, not just difficulty. Prefer delegating decisions that are cheap to undo (a first draft, a component design, a low-stakes customer interaction) over ones that are hard to walk back (a commitment made externally, a change with security or compliance exposure). Trust for higher-stakes delegation gets built incrementally through the reversible tasks.
Compare time-to-teach against time-to-do. If explaining the task well would take meaningfully longer than doing it yourself, and it's a one-off with no repeat value, do it yourself. If it's a skill they'll use again, the teaching cost is an investment that pays back on the second and third time.
Define the support structure explicitly. Delegating isn't handing off and disappearing. Decide in advance: what checkpoints happen, what they can decide alone versus what needs a quick check-in, and what "stuck enough to escalate" looks like.
What you keep. Work that needs institutional context you can't transfer in the available time, early-relationship politically sensitive conversations, and anything where a mistake would damage a stakeholder's trust in the team broadly rather than just cost you some rework time.
Worked example
Say you're leading a project with three distinct pieces. One is well-scoped, reversible, and slightly above where this person has worked before: a strong candidate to delegate as a growth task, with a design check-in before they start building and a review before it ships. Another piece is customer-facing with real cost if it goes wrong: you either delegate it with heavy pairing so you catch problems before they land, or you keep it yourself this round and delegate the next similar piece once trust is established. The third is a one-off internal chore with no growth value: you delegate it purely for your own capacity, not as a coaching move, and you say so, because dressing up busywork as a growth opportunity erodes trust.
Trade-offs and pitfalls
Delegating only "safe" tasks because failure is expensive to you personally caps the person's growth. They never build judgment under real stakes if you only ever hand them things that can't go wrong.
Delegating and then vanishing looks like empowerment but is often abdication. The failure mode shows up late, when it's expensive to fix, because there was no checkpoint designed to catch it earlier.
Over-specifying the implementation defeats the purpose. If you hand someone a task but dictate every step, there's no room left for them to exercise judgment, which is the actual thing you're trying to develop.
The honest trade-off: delegating a stretch task usually costs you more short-term time, in reviewing and coaching, than doing it yourself would. That extra cost is the investment, and it's worth naming rather than pretending delegation is free.
Tell me about a time you sponsored someone, not just mentored them. Where you actively advocated for their promotion or a specific opportunity in a room they weren't in.
Sample Answer
Direct answer
Sponsorship means spending your own credibility to open a door someone couldn't open for themselves, which is different from mentoring, which is advice given directly to the person. The core act is advocating for them by name in a room they aren't in, backed by specific, evidence-based reasons they deserve the opportunity.
What sponsorship requires
Political capital and timing, not just advice. Mentoring can happen anywhere, anytime, one on one. Sponsorship requires actually being present, or having enough standing, in the room where a real decision gets made: a promotion committee, a staffing decision, an assignment to a high-visibility project.
An evidence-backed case, not a vague endorsement. "They're great" doesn't move a room. Specific, concrete contributions you can vouch for personally do. Building this case ahead of time, before the opportunity comes up, is part of the work.
Deciding when it's warranted. The right moment is when someone is already delivering at the target level but lacks the visibility or exposure to be considered for it, there's a real decision window open, and you have enough credibility in that specific room for your advocacy to actually carry weight.
Making the specific ask. Vouching in general terms is weaker than naming the specific opportunity and asking for the specific outcome: this person, for this role, on this team, now.
Aftercare. Sponsorship only compounds if the person knows it happened. Telling them what you did lets them lean into the opportunity and know someone is actively in their corner, not just quietly hoping things work out. Following up on the outcome, win or not, matters too.
Worked example
Someone you work closely with does excellent work but has almost no visibility outside their immediate team. A high-visibility opportunity, or a promotion cycle, comes up in a room they aren't part of. You go in with specific, concrete contributions you can personally back, not general praise, and explicitly vouch for their readiness for that specific opportunity. Afterward, they're included in the opportunity or the promotion conversation, and you tell them directly what you did and why, rather than letting them find out secondhand or not at all.
Trade-offs and pitfalls
Sponsoring someone whose work you can't concretely back with specifics spends your credibility on hope rather than evidence, and if it doesn't pan out, it costs you standing in that room for the next person you'd want to sponsor.
Sponsoring quietly and never telling the person defeats much of the point. They don't know to lean into the opportunity, and they don't know someone is actively advocating for them, which is often as valuable as the opportunity itself.
Sponsorship is finite. You have a limited amount of credibility to spend across your whole network, which means you genuinely cannot sponsor everyone equally, and who you choose to spend it on is a real, sometimes uncomfortable decision worth being honest with yourself about.
A common confusion is treating a glowing performance review comment as sponsorship. Real sponsorship requires actually being in the room, advocating for a specific decision, not just praising someone in the abstract where it doesn't reach the decision-maker.
You have a recurring 30-minute one-on-one with someone you mentor. Walk through how you'd structure the agenda to balance day-to-day blockers, skill development, and career conversation, and how that structure should evolve over a quarter.
Sample Answer
Direct answer
A recurring 30-minute 1:1 works best with a light, predictable structure (a quick check-in, blockers, a skill or growth item, and a career or forward-looking question), but the real skill is protecting the last two from being crowded out by whatever operational fire is loudest that week, and shifting the balance of the agenda as the relationship matures over the quarter.
Structured elaboration
A default structure for 30 minutes
| Segment | Rough time | Purpose |
|---|---|---|
| Check-in | 3-5 min | Surface anything urgent, gauge how they're actually doing |
| Blockers / operational | 8-10 min | Whatever's actively in their way right now |
| Skill or growth item | 8-10 min | One concrete thing they're building toward, not a status update |
| Forward-looking / career | 5-7 min | Where this is headed, not just what's happening this week |
Guarding against the common failure mode
A well-known failure pattern: the 1:1 happens reliably every week, on time, with all the segments technically present, but the career and growth segments become shallow ritual ("anything on your mind for growth?" "nope, all good") while blockers quietly eat the real time. The fix isn't just having a slot on the agenda, it's asking a specific, forward-looking question each cycle rather than an open-ended one, and being willing to occasionally protect that segment even when there's a real blocker competing for the time.
Diagnosing what's actually going on, not just tracking status
Part of the value of a recurring 1:1 is using it to figure out whether a struggle you're observing is a skill gap or a mindset or behavioral issue, because the two need different responses. Someone who's struggling because they don't yet know how needs teaching and practice; someone who's struggling because of avoidance, overconfidence, or a mismatch in how they're approaching the work needs a more direct conversation about the pattern itself, not more technical instruction. A 1:1 is a good place to probe for which one you're actually looking at before assuming.
An alternative structure for hands-on technical work
For roles where the most valuable use of the time is genuinely technical, a 1:1 doesn't have to follow the career-conversation template at all. Structuring it around live debugging together, walking through a real problem with explicit hypotheses ("I think it's X, here's how we'd check") and tracking which ones got ruled out, can be a more valuable use of 30 minutes than a generic status-and-goals agenda, especially early in a relationship when trust and technical credibility are still being built.
Evolving the structure over a quarter
- Early on, more of the time typically goes to blockers and establishing trust; the person needs to know the meeting is safe and useful before career conversations will be genuine rather than performative.
- As confidence builds, the balance should shift toward growth and forward-looking conversation, and the blockers segment should shrink because there's simply less friction to clear.
- If that shift isn't happening by mid-quarter, that's itself a signal worth naming directly rather than just continuing to run the same agenda.
Worked example
Situation
Early in a mentoring relationship, our 1:1s were almost entirely blockers: real, legitimate ones, but every week's slot filled up before we got near growth or career topics.
Action
I made an explicit change: reserved the last five minutes for a specific forward-looking question every time, stated as a fixed rule rather than something to get to if there was time, and moved lower-urgency blockers to async channels so they didn't have to consume the live time by default.
Result
By partway through the quarter, the ratio had genuinely shifted: blockers took less of the time because fewer new ones were coming up, and the growth and forward-looking segments started generating real, substantive conversation instead of the same shallow "all good" answer each week.
Trade-offs & pitfalls
- Mistaking a full agenda for a working one. Hitting every segment on the template doesn't mean the 1:1 is actually working if the career and growth segments are consistently shallow.
- Applying the same generic structure to a technical, debugging-heavy role. Forcing a career-conversation template onto a context where live technical problem-solving would be more valuable wastes the time on both sides.
- Not distinguishing skill gap from mindset issue. Responding to a mindset or behavioral pattern with more technical coaching, or the reverse, burns the time without addressing what's actually going on.
- Never revisiting the structure. A rigid agenda that never evolves as the mentee matures signals the relationship isn't actually progressing, even if the meeting keeps happening.
How does mentoring someone differ from managing them? Where's the line, and what changes about your role when a mentee becomes your direct report?
Sample Answer
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
| Mentoring | Managing | |
|---|---|---|
| Authority | None, purely voluntary | Formal, tied to the role |
| If advice is ignored | Mentee simply doesn't act on it | Employee generally can't ignore direction tied to the job |
| Stakes of feedback | Mentee opts to apply it or not | Feeds performance record, comp, promotion |
| Cadence purpose | Growth-focused, informal | Growth and accountability, often the same meeting |
| Consequence of a bad fit | Relationship quietly ends | Requires a formal process to resolve |
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.
Unlock Full Question Bank
Get access to all 40 Mentoring and Coaching interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.