Mentoring and Multiplying

The question is usually "tell me about someone you mentored" or "how do you level up the people around you", and the common answer is a description of availability — "I'm always happy to pair, I do thorough code reviews". That's a disposition, not evidence.

Make it one person and one change. "A junior engineer joined and was scared of our deploy pipeline. We paired on two releases, then I had them run the third while I watched and said nothing, then I wrote the runbook with them. Within a month they were doing releases alone and they later took over the on-call rotation for that service." Named capability, method, outcome, and a clear end state where you're no longer needed.

Show the method, not just the outcome. The interesting part is how you calibrated: giving work slightly above someone's current level, resisting taking the keyboard, letting a reversible mistake happen because the lesson was worth more than the hour, asking questions instead of supplying answers. "I stopped answering in code review and started asking what they expected to happen" is a specific, teachable technique and it reads much better than "I gave good feedback."

Multiplying is broader than mentoring. Work that raises everyone's floor counts and is often stronger: the test harness that made a scary area safe to change, the template that ended the same three review comments, the onboarding doc that cut time-to-first-PR, the decision to break a project into pieces junior people could own. Say what changed for the team, and how you know.

Sponsorship is the senior version. Mentoring is advice; sponsorship is spending your own credibility — putting someone's name forward for the visible project, letting them present the design you helped shape, arguing for their promotion. Interviewers who know the distinction listen for it specifically.

Companies hire seniors partly to raise the floor of everyone around them, and it's most of the difference between a productive individual and a senior engineer. It's also the question where an honest small answer works well: one person, well told, beats a claim of having mentored a whole team.

• Name one person and one specific capability they gained; general availability is not evidence.
• Include the end state — they do it without you now — which is the actual goal of mentoring.
• Describe the technique: stretch work, not taking the keyboard, questions rather than answers.
• Allow reversible mistakes; the recovery is where the learning is, and saying so signals confidence.
• Force multipliers count: harnesses, templates, docs, and splitting work so others can own a piece.
• Sponsorship — spending your credibility on someone's visibility — outranks mentoring, and few candidates mention it.
• One well-told example beats a claim about levelling up a whole team.