Mentoring Someone

The question — "Tell me about a time you mentored or coached someone." Variants: "Describe a situation where you helped a junior engineer grow.", "Tell me about a time you developed someone on your team."

What they're assessing — Developing others intentionally rather than accidentally; tailoring your approach to the individual's needs and learning style; patience — letting people struggle productively rather than rescuing them; multiplying your impact through the people you grow; measurable evidence that the mentee actually improved.

STAR-L scaffold

Fill in your own story:

• Situation — Describe the mentee (role, experience level, the gap you identified) and the context. Was this formal (onboarding, structured mentorship) or informal? What prompted you to invest in this person?
• Task — What growth goal did you set together? Were you trying to get them to a specific capability threshold (e.g., shipping independently, conducting code reviews, owning an on-call rotation)?
• Action — What did you do to structure the mentorship? How did you adjust your approach when the first method wasn't working — use "I" and name specifics (e.g., moved from code walk-throughs to Socratic questioning, set up weekly 1:1s with a written agenda, gave stretch assignments with safety nets, celebrated early wins to build confidence)?
• Result — What measurable growth happened? Quantify where possible (e.g., went from needing review on every PR to shipping features end-to-end independently within 3 months, promoted within 6 months, took on on-call within 8 weeks).
• Learned — What did this teach you about developing others? What do you do differently now (e.g., assess learning style first, set explicit goals, resist the urge to hand over answers)?

Pitfalls / red flags

• Doing the work for them instead of teaching — describing how you fixed their bugs or wrote their code signals you confused mentoring with helping.
• Taking credit for their growth: "I made them successful" rather than "they grew and here's the evidence."
• No evidence the mentee actually improved — the story ends at effort, not outcome.
• One-size-fits-all approach — no mention of adapting to how this particular person learns best.

Example (generic — replace with your own)

Situation: A new graduate joined our team mid-quarter. She had strong CS fundamentals but had never shipped production code — she was unsure about our code review process, deployment pipeline, and how to scope tasks independently.

Task: I set a goal with her: be able to own a small feature end-to-end — from ticket to production — within 10 weeks without needing me to co-pilot each step.

Action: For the first two weeks I paired with her on one task, narrating my decision-making out loud. Then I deliberately stepped back: I assigned her a small, isolated feature and told her to come to me with questions after she'd first spent 15 minutes trying to answer them herself. When she got stuck on a design decision, instead of answering I asked "what are the two options you're weighing and what does each cost you?" — I shifted from giving answers to asking questions. I checked in during our weekly 1:1 using a written agenda we maintained together, which helped her track her own progress rather than waiting for my evaluation.

Result: By week 9 she had shipped two features independently with no production incidents. By week 14 she was reviewing other engineers' PRs. Six months later she was onboarding the next new hire.

Learned: I learned that the urge to give the answer is the enemy of teaching. Holding back and asking "what have you tried?" is uncomfortable for about 30 seconds and invaluable for the next six months. Now I use that question as my default first response whenever a mentee brings me a problem.