Tell me about someone you mentored and how they grew.
answer
- name the mentee and their starting gap
- the plan you agreed, not improvised help
- your weekly moves: pairing, stretch work
- growth evidence they own, with a number
- one thing you would mentor differently
basics
~20 sProbes whether you grow other engineers or only answer their questions. Name one mentee, the gap you diagnosed, the deliberate moves you made — pairing, ramp plan, stretch work — and evidence that they ended up more capable.
how to answer
5 beats- who the mentee was and where they startedTwo or three sentences, no more: their level, the surface they were joining, and the specific capability they did not yet have. Keep the whole setup to roughly fifteen to twenty percent of your airtime, because this prompt tempts people into a long backstory.
- the gap you diagnosed and the plan you agreedSay how you worked out what was actually missing — knowledge, context, confidence, or feedback loop — and what you and they agreed to do about it. A plan with a cadence and a target beats an offer to be available.
- what you actually did, week to weekThis is the bulk of the answer, around sixty percent of your airtime. Be concrete about mechanics: pairing frequency and who drove, what you taught inside review, the stretch assignment you chose and why it was safe to get wrong.
- the evidence they grewLand a result the mentee owns: a component in their name, a rotation they joined, something they shipped without you, ideally with one number attached. Together with the reflection this should take twenty to twenty-five percent of your airtime.
- what you would do differently as a mentorOne honest line about your own mentoring, not theirs — answering too quickly, protecting them from useful difficulty, waiting too long to hand over ownership. Then say what you changed and what improved.
your answer
5 story prompts- Pick one person you mentored for at least three months, not a single pairing session.
- Write what they could not do at the start and could do at the end.
- Find one number their growth produced: a component owned, a rotation joined, a backlog cleared.
- Name one mentoring habit of yours that you changed partway through.
- This can be the same person as your difficult-feedback story, angled on growth instead.
draft and rehearse your own answer in a learn session
go deeper
This probes growing others: whether you can take responsibility for someone else's capability rather than only your own output. Interviewers want a designed intervention — diagnosis, plan, deliberate practice, transferred ownership — and evidence of change in the mentee. A strong answer proves you scale a team's ability instead of hoarding the interesting work.
A junior engineer joined our order-events platform about ten months ago. She had written services before but had never owned a message consumer, and I was the reviewer on her first three changes. The code was fine; what I noticed was that she was guessing about what happened when a message failed. So we agreed on something more structured than an open offer to help. Twice a week we paired for an hour on the settlement consumer and she drove — I only asked questions, and I made myself wait before answering. In parallel I gave her one surface of her own, the dead-letter replay tool, small enough that a mistake cost us a rerun rather than an outage. I wrote down three things I wanted her able to do by quarter end: read a consumer lag graph unaided, explain our retry policy out loud, and ship a consumer change without me on the review. By month four she was doing all three, and the replay tool was genuinely hers. She added batch replays after an upstream feed stalled and left peak queue depth at 37,400 messages; the next time that happened the backlog cleared in 26 minutes instead of most of a working day. What I would change is the first six weeks. I answered too fast. Once I started asking what she had already ruled out before I said anything, her questions got noticeably sharper inside a fortnight.
Strong at mid-level because the mechanics are copyable — pairing cadence, who drives, a deliberately low-stakes owned surface, three written readiness criteria. The result belongs to the mentee and carries a number. It would downlevel if the mentee never got work of her own or if the reflection were about her rather than the speaker's own habit.
When I took the tech lead seat on a fourteen-person platform group, one second-year engineer had been shipping tickets competently for a year and wanted on-call, but nobody trusted him with it. I decided the plan had to be ownership rather than lessons. I moved the ingestion consumer into his name in the service catalogue and told the team to route questions to him first, including mine. I sat in his first two incident reviews and deliberately said nothing in the room; we debriefed afterwards, privately. His stretch assignment was the autoscaling rules for the consumer pool — work I could have written in an afternoon and that took him three weeks. It cost us something real. His first version scaled on CPU rather than on backlog, and at quarter close the ingestion queue sat above 61,800 messages for roughly four hours before he caught it. I let that be his incident, wrote none of the review document myself, and we corrected the scaling signal together the week after. At the same load the following month, peak held under 8,400. He was primary on call within seven months and now runs the ramp for new joiners on that team. The measure I actually care about is that I left the path: I get maybe one question a month about a service I used to run end to end.
The senior signal is the paid cost — a real backlog incident allowed to stand as the mentee's own, with the lead absorbing the delivery risk rather than the credit. Transferred ownership is concrete: catalogue entry, routing of questions, silence in the review room. It would downlevel if the speaker had quietly fixed the scaling rules themselves.
You are not expected to have owned a mentee. Use peer scope honestly: you walked a newer teammate through the local setup, reviewed their first change, or wrote the note you wished had existed. Show you noticed what confused them and adjusted.
One named person over months, not one pairing session. Show the ramp you agreed, the teaching you did inside code review, and a stretch task inside your own feature area that you chose because it was safe to get wrong.
The bar is transferred ownership. Show that you handed a real service or rotation to the mentee, absorbed the delivery risk when their first version was worse than yours would have been, and can point to them operating without you.
Talk about the mechanism, not the individual: how mentors on your teams are chosen and coached, what growth you measure, and how you stopped mentoring quality from depending on which senior a joiner happened to sit next to.
saying these in an interview costs you the question
- Claiming the mentee's shipped work as your own accomplishment
- Generic helpfulness with no plan, no cadence and no stretch assignment
- No evidence of change beyond saying you were always available
- Describing the mentee as slow, needy or a drag on your velocity
- Doing the hard part yourself and calling it unblocking
- A mentee who ended the story on exactly the work they started with
- What was the hardest thing for them to learn?Answer with the specific capability, not a personality trait. Say what made it hard — missing mental model, low confidence, unfamiliar tooling — and the concrete thing you changed to get past it. Avoid anything that reads as a complaint about the person; the interviewer is checking whether you diagnose or judge.
- How did you know they were ready to own it alone?Name the readiness signal you actually used: they debugged something end to end without you, their questions changed shape, they caught a review issue you missed. Vague answers here undo the whole story. If you handed ownership before they were fully ready, say so and say what safety net you kept.
- What would you do differently as their mentor?Pick a real mentoring mistake, not a humblebrag about caring too much. Common honest answers: answered too fast, gave work that was too safe for too long, gave feedback in writing when it needed a conversation. Then say what you changed and what improved after.
- How did their role change after that?Give the concrete after-state — a rotation they joined, a component in their name, a promotion, mentoring someone else themselves. If you lost touch or they left, say that plainly and cite the evidence you did see. Never inflate an outcome you cannot describe.
## The variants all want the same evidence You will hear this as: - *Tell me about someone you mentored*, - *How have you helped other engineers grow?*, - *Who is the best engineer you have developed?* or, - in a lead loop, *How do you grow the people on your team?* Answer them all with **one concrete person and one arc**: where they started, what you did, where they ended. The plural framings tempt you into a philosophy answer, which is the weakest form of this response. Give the philosophy in one sentence and spend the rest on the case. ## Weak versus strong **What separates a weak answer from a strong one is almost never effort — it is specificity of the delta.** - A **weak answer** describes availability: I made time, I answered questions, I was patient. Every candidate says that, so it carries no signal. - A **strong answer** names a capability the person did not have and later had, and the deliberate mechanism that closed the gap. The interviewer is listening for whether you *designed* the growth or merely absorbed interruptions. ## Four kinds of evidence carry weight, roughly in ascending order 1. First, **teaching artefacts**: a ramp document, a review comment style, a runbook you wrote with them. 2. Second, **the stretch assignment** — work slightly beyond their current level that you chose because failure was recoverable. 3. Third, **transferred ownership**: their name on a component, a rotation, a design review they ran. 4. Fourth, and strongest, **second-order growth**: they now onboard or mentor someone else. If your story reaches the third or fourth kind, you are answering above your level in a good way. ## Guard against the credit trap The story is about them, but the interviewer is assessing you, and candidates over-correct in both directions: - Some narrate their own heroics with the mentee as scenery — that reads as taking credit for someone else's shipped work. - Others become so self-effacing that no decision of theirs appears at all, which reads as having been nearby while someone grew. The fix is a **clean split of verbs**: - the mentee ships, decides and learns; - you diagnose, structure, choose the work, protect the space, and absorb the risk. ## Airtime **Airtime discipline matters more here than in most behavioral prompts,** because mentoring stories run long. 1. Keep the setup to two or three sentences — who they were, what they could not do yet. 2. Spend the middle on your actual moves, in enough detail that a listener could copy them: how often you paired, who held the keyboard, what you deliberately did not answer, what you handed over and when. 3. Land the result in two sentences with something checkable, then one honest line of reflection. ## The bar shifts by level in a predictable way - At **mid-level**, one person, one quarter or two, teaching mostly through review and pairing inside work you already own. - At **senior**, the story should include a moment where you paid for their growth — a slower delivery, a rougher first version, an incident you let stand as theirs — because that cost is the proof that the ownership was genuine. - At **staff and above**, the interviewer stops caring about the individual case and starts listening for a repeatable mechanism and for how you know it is working across more people than you can personally sit with. ## One last calibration If the only mentee you have is an intern from years ago, use it, but say what you would do differently now with what you have since learned. Interviewers forgive a thin mentoring history far more readily than they forgive a polished story with no evidence in it.