Pairing on a real ticket while letting them drive, resisting the urge to take over the keyboard, asking 'what have you tried' before offering the answer, and checking whether the concept actually landed rather than just the ticket closing.
Published September 23, 2026
The highest-value mentoring setup isn't explaining a concept in the abstract — it's pairing on an ACTUAL ticket, with the LESS-EXPERIENCED person at the keyboard, actually writing and running the code, while the mentor guides. This matters because real tickets have real, messy edge cases that a clean teaching example never captures — debugging an actual failing test, reading an actual unfamiliar error message, navigating an actual unfamiliar part of the codebase. The learning that happens from working through genuine friction, with someone available to unblock, sticks in a way that watching someone else demo the same thing rarely does.
The moment: they're stuck, visibly frustrated, and you can see the fix immediately
The instinct: "here, let me just..." [reaches for keyboard]
The better move: describe what to look at, or ask a guiding question, and WAIT
This is the single hardest habit to build as a mentor, and the most consequential one to get right: when someone's stuck and you can see the answer, taking over the keyboard FEELS helpful (the ticket moves forward faster) but actually removes the exact struggle that would have built their own understanding. The discomfort of watching someone work through something slowly, when you could resolve it in seconds yourself, is the actual cost of mentoring well — and it's a cost worth explicitly paying, distinct from just wanting the ticket done.
This single question, asked genuinely (not as a gatekeeping ritual before you'll deign to help), does real diagnostic work: it reveals WHERE their understanding actually is, which tells you what kind of help is actually needed — sometimes they've tried the right thing and just need a small nudge; sometimes they're stuck on a fundamentally wrong assumption that needs to be surfaced and corrected before anything else will make sense. Jumping straight to the answer without this step means guessing at what kind of help to give, often answering a question they didn't actually have.
Ticket closes ≠ concept understood
— they could have followed your instructions step-by-step without
building a transferable mental model of WHY those steps worked
A closed ticket is a weak signal of actual learning — someone can follow explicit step-by-step guidance to a working solution without genuinely internalizing the underlying reasoning, meaning the NEXT similar problem finds them just as stuck as before. A brief, genuine follow-up later (not immediately, which reads as a pop quiz — but a few days later, in context: "remember that connection-pool exhaustion issue — why do you think it happened again if we hadn't fixed the root cause?") checks whether the concept actually transferred, not just whether the specific ticket got closed.
Q: How long should you let someone struggle before stepping in, if you're deliberately resisting taking over? A: This is exactly Unblock, Don't Solve's core question — the answer depends on distinguishing PRODUCTIVE struggle (genuinely working through the problem, making incremental progress) from UNPRODUCTIVE struggle (spinning on the same wrong approach, visibly frustrated with no progress), with a rough time-box as a backstop even for productive struggle so it doesn't consume an entire day.
Q: Does 'let them drive' mean never demonstrating anything yourself? A: No — sometimes briefly demonstrating one small technique (how to read a specific kind of stack trace, a debugger feature they haven't used) is the right move, then handing control back immediately; the principle is about who does the actual PROBLEM-SOLVING work, not an absolute rule against ever touching the keyboard for a quick, bounded demonstration.
Q: How do you mentor well when you're also under real delivery pressure yourself? A: Being explicit about the trade-off, rather than silently resenting the extra time, tends to work better in practice — naming it directly ('this ticket will take longer paired than if I just did it myself, and that's the right call because you'll be faster on the NEXT three similar tickets') keeps the investment framing visible to both people, rather than mentoring feeling like an unstated tax on your own velocity.
Q: Is this mentoring approach the same regardless of the person's seniority level? A: The core principles (letting them drive, diagnostic questioning, checking real understanding) hold generally, but the CALIBRATION shifts — a brand-new engineer needs more frequent check-ins and a shorter struggle time-box than someone with a few years of experience learning an unfamiliar part of the codebase, where longer independent struggle is often more appropriate and more respectful of their existing competence.