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.
How do you adapt your mentoring approach to someone whose personality, background, or way of learning is different from your own?
Sample Answer
Direct answer
Adapting mentoring to someone different from yourself means adjusting the mechanism (how directive vs. how hands-off you are, how direct the feedback is, how much structure you provide) while keeping the underlying goal the same, and it requires actively noticing when your default style is a poor fit rather than assuming your own preferences are universal.
Structured elaboration
Adapting by competence and confidence: situational leadership
A useful framework here is thinking in terms of directing, coaching, supporting, and delegating, mapped to how much competence and confidence the person currently has for the specific task at hand (not their seniority in general, since someone senior can still be low-confidence on something genuinely new to them):
- Directing: low competence, needs clear instruction on what to do.
- Coaching: some competence but still needs explanation and encouragement, not just instruction.
- Supporting: solid competence, mainly needs encouragement and a sounding board, not instruction.
- Delegating: high competence and confidence, needs autonomy more than involvement.
The same person can sit in different quadrants for different tasks at the same time, so this is applied per-skill, not as a single label for the whole relationship.
Adapting to feedback-culture differences
How directly to give feedback isn't purely a personal style preference; it's shaped by cultural norms the mentee brings, and treating it as pure style risks an equity failure, not just a communication mismatch. Someone from a background where direct, blunt feedback is the norm may find indirect feedback confusing or even read it as a lack of respect for their ability to handle it; someone from a background where direct public correction is genuinely unacceptable may experience the same blunt feedback as disrespectful or even shaming, regardless of intent. Noticing which context someone is bringing, and adjusting delivery accordingly while keeping the substance intact, is part of doing this well rather than an optional nicety.
Adapting by seniority of the mentee
A junior mentee usually needs more structure, more explicit scaffolding, and more frequent checkpoints. A senior mentee needs something different: less procedural guidance, more of a thinking partner, and often an explicit expectation that they take on some mentoring of others themselves, since developing that skill is frequently the actual next step in their own growth, not something to route around.
Worked example
Situation
I mentored someone who worked best from a fully worked-out plan before starting anything ambiguous, while my own instinct is to start acting and figure out the plan as I go. Early on, my default approach (throw them a loosely scoped problem and let them work it out) was clearly causing more anxiety than growth; they'd stall rather than experiment.
Action
Instead of pushing them toward my own style, I adjusted the mechanism while keeping the goal (building comfort with ambiguity) the same: gave them explicit structure up front for the first few tasks (a rough plan to react to and revise, rather than a blank page), and deliberately widened the ambiguity only gradually as their confidence grew, checking in on how it felt rather than assuming.
Result
Over time they needed less upfront structure and became noticeably more willing to start from a loosely scoped problem on their own, which was the real signal of the adaptation working: not that they'd adopted my style, but that they'd built their own comfort with ambiguity at a pace that actually worked for them.
Trade-offs & pitfalls
- Assuming your own learning style is the default. The single most common failure here is mentoring the way you'd want to be mentored, rather than the way the specific person in front of you actually learns.
- Treating feedback-culture adaptation as optional politeness rather than an equity issue. Delivering feedback the same blunt way to everyone regardless of their background isn't neutral, it systematically disadvantages people for whom that style reads as disrespect rather than directness.
- Over-adapting to the point of never stretching the person. Adapting to someone's current style is different from leaving them there permanently; part of growth is gradually building comfort outside their comfort zone, not just permanently accommodating it.
- Forgetting that senior mentees need a different kind of adaptation, not just less attention. Assuming a senior mentee needs nothing from you, rather than a different kind of engagement (including expecting them to mentor others), under-invests in someone who still has real room to grow.
A mentee becomes defensive, or pushes back hard, whenever you give them feedback, and stops acting on your suggestions. How do you handle it?
Sample Answer
Direct answer
When a mentee gets defensive and stops acting on feedback, the fastest way to make it worse is to double down with more direct feedback. Slow down, diagnose why the message isn't landing (the content, the delivery, or something the mentee brings into the room), then rebuild the conversation as a two-way one instead of a one-way correction. If the pattern doesn't shift after a genuine attempt at that, it needs to be named and escalated, not quietly tolerated.
Diagnose before you re-deliver
- Separate "defensive because of how I said it" from "defensive because of what's underneath it." Workload, unclear expectations, a confidence hit, or feedback that reads as a character judgment rather than a specific behavior all produce the same surface symptom (pushback, non-action) for different reasons.
- Ask, don't assume: open with a genuinely curious question rather than a repeat of the critique. "Walk me through how that landed for you" gets you information; "you need to stop being defensive" gets you more defensiveness.
Use motivational interviewing instead of more direct pressure
- Motivational interviewing is built for exactly this: someone who may intellectually agree but is resisting behaviorally. Instead of arguing for the change, reflect their own stated goals back to them and let them articulate the gap ("You mentioned you want to lead the next project. How does this pattern affect that?"). People act on reasons they generate themselves far more than reasons handed to them.
- Keep the ratio of affirmation to correction visible. If every interaction is corrective, the mentee starts hearing footsteps before you speak, which is what produces reflexive defensiveness.
Rebuild the mechanism, not just the next conversation
- Shrink the ask: instead of a broad critique, propose one small, concrete, reversible change and a short check-in window.
- Make feedback bidirectional: ask what kind of feedback has landed well for them before, and adjust format (written vs. verbal, immediate vs. batched) accordingly.
Know when coaching has run its course
- If, after two or three honest attempts using the above, the pattern is unchanged (commitments still not acted on, same defensiveness), that's a signal the issue may be outside what coaching alone fixes: a skill gap being misread as attitude, a values or fit mismatch, or a factor you're not positioned to see.
- At that point, loop in the mentee's manager, or HR if the dynamic has become adversarial, rather than continuing to privately absorb it. Frame it factually: what you tried, what changed, what didn't. This isn't giving up on the mentee; it's recognizing some situations need authority or context you don't have.
Worked example
A mentee kept missing agreed follow-ups on code review comments and would get visibly short in Slack whenever it came up. The instinct was to restate the same feedback more firmly. Instead, the better move: open the next 1:1 with "I want to understand how the review feedback has been landing for you, not go through it again," and listen first. It turned out the mentee had inherited a legacy module nobody had explained well, and every review comment felt like it was pointing out someone else's mess. The fix wasn't more feedback, it was pairing on the module once and shrinking the ask to one file at a time. If that hadn't worked, the next honest step would have been raising the pattern with the mentee's manager, not repeating the same conversation a fourth time.
Trade-offs and pitfalls
- The junior mistake is treating defensiveness as a discipline problem and pushing harder; that reliably produces more resistance, not less.
- Over-correcting the other way (going silent on real issues to avoid triggering defensiveness) just delays the same conversation and lets performance drift.
- Escalating too early, before you've tried adjusting your own approach, reads as offloading a coaching problem; escalating too late lets a stalled dynamic damage trust or delivery. The senior move is trying a genuine adaptation first, timeboxing it, and being honest about whether it moved anything.
Someone you're mentoring keeps missing commitments and blames unclear requirements. Walk through how you'd figure out what's actually going on and what you'd do about it.
Sample Answer
Direct answer
"Unclear requirements" is a real cause sometimes and a convenient explanation other times, so the first job is figuring out which, using evidence rather than taking the explanation at face value. Look at the pattern across several instances, not just the latest miss, separate estimation problems from execution problems from actual requirement gaps, then fix the specific mechanism, not the person's attitude.
Diagnose using the pattern, not the excuse
- Pull several recent examples, not just the most recent miss. Was the requirement genuinely ambiguous every time, or does "unclear requirements" get invoked even when the ticket had clear acceptance criteria? The former is a process problem; the latter is a signal something else is going on (confidence, avoidance, poor estimation).
- Look for where in the workflow it breaks down: did they ask clarifying questions before starting and get bad answers, or did they not ask and guess? Did the requirement change mid-task without being re-scoped? Did they commit to something they didn't actually understand, to avoid looking behind?
Separate the possible root causes
- Genuine ambiguity: the requirement really was underspecified and nobody caught it before work started.
- Estimation or planning gap: the requirement was clear but the person didn't break it down enough to notice the ambiguous parts until they hit them.
- Avoidance: asking clarifying questions feels risky (looks like not knowing), so they guess and then have a ready explanation when it goes wrong.
- Skill gap under a different name: they may not yet have the judgment to know what "clear enough to start" looks like.
Fix the mechanism that matches the cause
- Genuine ambiguity: introduce a lightweight definition-of-ready check before work starts, owned jointly, not something you police alone.
- Estimation or planning: practice breaking a ticket into sub-tasks together and flag the ambiguous piece explicitly before committing to a date.
- Avoidance: make asking clarifying questions cheap and normal, model it yourself, and separate "I don't know yet" from an evaluation of competence.
- Skill gap: pair on a couple of tickets so they see what "clear enough" actually looks like in practice, rather than being told about it abstractly.
Worked example
A mentee on a team I supported kept missing sprint commitments, and the stated reason was always some version of unclear requirements. Looking at the last four tickets together, not just the most recent one, a pattern showed up: on three of the four, the acceptance criteria were actually written clearly, but the mentee hadn't asked any clarifying questions before starting, then hit an edge case mid-task and treated the whole ticket as ambiguous from the start. On the fourth, the ticket genuinely was underspecified.
The fix wasn't "communicate more clearly" in the abstract. It was two things: a short pre-work check where we'd both look at a ticket before it was picked up and flag anything genuinely unclear (catching the real ambiguity case), and a habit of the mentee sending one clarifying question per ticket before starting, even a small one, to break the avoidance pattern. The signal it was working wasn't a single metric; it was that "unclear requirements" stopped being the explanation for misses, because the real ambiguity was being caught earlier and the avoidance pattern had a lower-stakes outlet.
Trade-offs and pitfalls
- Taking "unclear requirements" at face value every time lets a deeper issue (avoidance, skill gap) hide behind a plausible-sounding excuse indefinitely.
- Assuming it's never true is just as wrong; requirements genuinely are underspecified sometimes, and treating every instance as a character problem erodes trust.
- The fix has to match the actual cause. A definition-of-ready checklist won't help someone avoiding asking questions, and coaching someone to "just ask more" won't help if the requirements really were bad.
Two people you mentor are in conflict with each other, and it's starting to affect the team's work. How do you handle it?
Sample Answer
Direct answer
Talk to each person privately before bringing them together, so you understand the facts and stakes from each side without an audience. Then classify the conflict as substantive (a genuine disagreement about the right call) versus interpersonal (friction dressed up as a substantive disagreement), because each needs a different resolution path. Bring them together around a shared goal and concrete evidence, not around who's right, and if it's genuinely undecidable in the room, use a time-boxed way to get more evidence rather than let the standoff continue to block the team.
Resolution framework
Never mediate cold in a group. Talk to each person separately first. You're listening for their read of the facts, what they think is at stake, and what "winning" would actually look like to them. This also surfaces things people won't say in front of the other person.
Classify before you intervene. A disagreement that looks technical or process-based on the surface is sometimes substantive and sometimes really about communication style or unresolved friction. Treating an interpersonal conflict as if it just needs more evidence wastes everyone's time; treating a real substantive disagreement as if it just needs better feelings management does too.
Reframe the joint conversation around the shared goal. Ask both people directly what evidence would change their mind. This shifts the conversation from defending a position to examining what's actually true, and it's a useful tell: someone who can't answer that question may be more attached to being right than to the outcome.
Use a time-boxed way to break a genuine deadlock. If the disagreement is real and evidence-based but neither side has enough information to concede, propose a small, bounded experiment or spike to settle it rather than let the argument continue indefinitely. If there's no time for that, make the call yourself and say plainly that you're doing so.
Follow through explicitly. Name who owns the resulting decision, document it somewhere durable, and check back in later to make sure the resolution actually held rather than just went quiet.
Worked example
Two people you mentor are at an impasse over a decision, and delivery is now stalled because of it. Separate conversations reveal the disagreement is mostly substantive, but there's real interpersonal friction layered on top, one of them has started talking over the other in shared meetings. You facilitate a joint session with explicit ground rules, focused on what evidence would resolve the substantive question, and propose a short timeboxed way to get that evidence rather than debate it further. Separately, and privately, you have a direct conversation with the person who'd been talking over the other about how that was landing on the team, independent of who turns out to be right on the substance.
Trade-offs and pitfalls
Mediating in a group before talking to each person privately risks blindsiding someone and getting performative, professional-sounding answers that hide what's actually going on.
Always pushing for consensus wastes time on disagreements that genuinely don't have a consensus answer. Sometimes the right move is a clean, owned decision, not more discussion.
Making the call yourself resolves the immediate block but has a cost: it can create resentment, or teach people to escalate disagreements to you instead of learning to resolve them with each other, so it's worth being deliberate about when you step in to decide versus when you keep facilitating.
A conflict that keeps recurring in slightly different forms is often a signal of a structural problem, unclear ownership boundaries between the two people, rather than a personality clash, and treating the symptom each time without noticing the pattern means you'll be back here again.
How do you recognize when someone you're mentoring is burned out or disengaged, as opposed to just underperforming, and what do you do differently once you suspect that's what's happening?
Sample Answer
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
| Signal | Skill gap | Burnout or disengagement |
|---|---|---|
| Scope of decline | Narrow, specific task type | Broad, across previously strong work |
| Timing | May have always been at this level | Recent, a change from baseline |
| Engagement | Still seeks help, asks questions | Withdraws from discussion and meetings |
| Affect (visible mood/expression) | Stable | Flattened, or newly irritable |
| Context | No obvious life or workload trigger | Often coincides with sustained overload or a life event |
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.
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.