Mentoring and Growing Engineers
Mentoring on an infrastructure team happens mostly under pressure, during incidents and reviews, where the instinct to take the keyboard resolves the problem faster and teaches nothing. The method that works is the mentee driving while the mentor asks questions, with a takeover condition agreed in advance so nobody negotiates it at two in the morning. It costs time, and choosing which situations can absorb that cost is the judgment being assessed.
TL;DR: The mentee drives and the mentor asks questions, and the difficulty is entirely that your instinct under pressure is to fix it yourself. Agree the arrangement before it is needed, including who takes over and when, so the handover is a rule rather than a negotiation during an incident. Take communication off the mentee, because doing the technical work while explaining it to an audience is the hardest part of a first incident and the least educational. Ask questions that do not contain the answer, narrate any takeover so it is a demonstration rather than a rescue, and debrief with the mentee writing the record. Then choose which situations can afford the slowdown, because a novel, customer-facing, expensive incident is the wrong place to practise and admitting that is part of the skill.
The arrangement, agreed before it is needed
| Element | What it says |
|---|---|
| Roles | The mentee runs the work and types; the mentor asks questions and handles communication |
| Takeover conditions | Growing impact, an irreversible next step, or the mentee asks. Stated in those words |
| Communication | The mentor posts updates, so the mentee is not context-switching between doing and explaining |
| Afterwards | The mentee writes the record; the mentor reviews before it circulates |
Splitting communication away from the mentee matters more than it sounds. The hardest part of a first serious incident is not the technical problem but doing the technical problem while people ask for updates, and removing that is what lets the learning happen at all.
Questions that do not contain the answer
Four carry most of the value, and none of them tells the mentee what to do.
- What does that tell you? Asked after they look at something and before they look at the next thing, which trains reading evidence rather than collecting it.
- What would you expect to see if that were true? Trains making a hypothesis falsifiable, and it is the question that catches a theory nobody tested.
- What is the cheapest thing that would rule that out? Trains ordering the investigation by cost rather than by curiosity, and it shows the two-minute check they were about to skip.
- What is this costing per minute? Trains the judgment about when to stop investigating and start mitigating, and on a GPU fleet it has a real answer in idled capacity.
Sustaining these when you can see the answer is the discipline. A useful constraint is to give yourself a budget: questions for ten minutes, shortened if the cost per minute is high.
On-Call Narratives That Land covers how the mentee should later tell the story of the incident they just ran, and reading it together during the debrief gives them a frame for what they did.
Taking over without undoing the lesson
Say it out loud and say why. "I am taking over because the next step drains nodes and we cannot undo that quickly, watch what I check and I will explain after" makes the takeover a demonstration. Taking the keyboard silently teaches that competence looks like being fast and unexplained, which is the opposite of what the team needs, and taking over without a debrief leaves the takeover as the only thing the mentee remembers.
Choosing the situation
Not every incident is a teaching opportunity, and choosing wrong damages both the outcome and the person. A first drive belongs on a known failure class with an existing runbook and a cost per minute the team can absorb. A novel, customer-facing, expensive incident should be run by the mentor with their reasoning narrated aloud, which is a different and also valuable form of teaching. Being explicit about that choice is what separates mentoring from delegating under pressure.
What interviewers are listening for
The keyboard. Whether the candidate can describe holding back when they knew the answer, and what it cost, is most of the signal. After that, whether they took communication off the mentee, which almost nobody mentions and which does more for the outcome than any other part of the arrangement. Then whether growth was observed rather than asserted: the mentee ran the next one alone, or their questions changed from what to why, or they wrote a runbook nobody asked for.
Key takeaways
- The mentee drives and types; the mentor asks questions and owns communication.
- Agree the takeover conditions in words before the shift: growing impact, an irreversible next step, or the mentee asks.
- Four questions that contain no answers: what does that tell you, what would you expect if true, what is the cheapest way to rule it out, what is this costing per minute.
- Narrate any takeover so it is a demonstration, and debrief with the mentee writing the record.
- Choose the situation deliberately; a novel customer-facing incident is the wrong place for a first drive.