Mentoring junior engineers — what actually works.

01What good mentoring actually produces

The mentor's job is not to make the junior more efficient at the current task. It's to make them independent over time. The measure is: in 6 months, can they handle situations like this on their own?

That goal changes the moment-to-moment behavior significantly:

• You don't just answer the question. You teach them how to find the answer themselves.
• You don't fix their PR. You point out what to look for and let them fix it.
• You don't make the design decision. You ask the questions that surface the trade-offs and let them decide.

This is slower in the short term and much faster over time. The junior who got 50 answers handed to them is the same junior 6 months later. The junior who learned how to find 50 answers can find the 51st without you.

02Practice 1 — Ask before you tell

Default behavior when a junior asks a question: tell them the answer. Better behavior: ask what they've already considered.

Junior: "Should I use Redux or Context for this?"
Senior: "Context. Redux is overkill for what you described."

Junior: "Should I use Redux or Context for this?"
Senior: "What's pulling you toward one or the other? What's the
        state you're managing?"
Junior: "Just two pieces of UI state — sidebar open, theme."
Senior: "What questions would you ask to decide between them?"
Junior: "...how much state? Whether it changes often? How many
        components need it?"
Senior: "Right. So given the answers, what's your lean?"
Junior: "Context, I guess."
Senior: "Yeah. Go with that."

Same outcome, but the junior now has the decision framework. The next time they face this question — and they will — they'll apply the same questions independently.

03Practice 2 — Let them struggle (productively)

There's a temptation to rescue. The junior is stuck on a bug for an hour; you can see the issue in 10 seconds; you want to point it out and move on. Don't.

Struggle is how skills develop. The junior who debugs a hard problem alone — taking longer than you would — learns more than the junior who got the answer immediately. They build the debugging instincts that compound over their career.

That said, struggle has a productive zone. Two hours stuck is learning. Six hours stuck is suffering. The mentor's job is to notice the difference and intervene at the right time.

Useful intervention sequence:

1. "How long have you been stuck on this?" — establishes timing.
2. "What have you tried so far?" — they often realize they've barely tried.
3. "Where do you think the bug is?" — narrows their attention.
4. "What information would help you find it?" — points toward tools (logs, debugger, etc.) without giving the answer.
5. Only if still stuck: a small hint that opens up the path without solving the problem.

04Practice 3 — Code reviews are the primary teaching tool

For most junior engineers, code review is where they learn 80% of what they learn from you. Use it deliberately.

Make your comments educational, not just corrective. Instead of "use map here," try "this loop is collecting into a new array — what's the more idiomatic way to express that?"

For repeated patterns, point out the pattern, not just the specific instance. "I've noticed this pattern in your last three PRs — let's talk about it" is more useful than the fourth identical comment.

Approve when the PR is good enough to ship, even if it's not how you'd have written it. The junior needs to see that "good enough" is a real bar — perfectionism teaches them to over-engineer everything, which is worse than the original imperfection.

05Practice 4 — Pair on hard things, not on routine things

Pair programming is high-bandwidth and tiring. Use it for moments that justify the cost:

• The first time they touch a new system, to give them the mental model.
• Debugging a difficult issue, where seeing your debugging process is the lesson.
• Design discussions for non-trivial features, where the back-and-forth shapes the design.
• Stuck on something they've been struggling with for hours.

Don't pair on routine work. It's expensive (two engineers for one ticket), tiring, and doesn't teach anything they couldn't learn alone. Save the pairing capital for high-leverage moments.

06Practice 5 — Give specific, immediate feedback

Feedback held until 1-on-1 is feedback diluted. Feedback delivered three months later in a performance review is feedback wasted.

Specific, immediate feedback:

• "That question you asked in standup just now was great — it surfaced the assumption everyone else had missed."
• "The way you wrote that error message — really clear, kept that style."
• "In the meeting, you cut [name] off twice. Be careful with that. They had something to add."

Positive feedback is harder than negative feedback for most seniors. Get over it. The junior needs to know what to keep doing, not just what to stop doing.

07Failure mode 1 — being too senior

You forget what it was like to not know things. You assume the junior has context they don't. You explain at a level that flies over their head, then get frustrated when they don't follow.

Calibration tools:

• Ask them to explain back what you said. If they can, you communicated. If they can't, you didn't.
• Watch their face during explanations. Confusion is a signal; address it immediately.
• When in doubt, start with foundational context. They can fast-forward if they have it; they can't recover if they don't.

08Failure mode 2 — rescuing instead of mentoring

You see the junior struggling. You jump in and fix it. They thank you. You feel good. Both of you are worse off long-term.

Rescuing teaches dependence. The junior learns "when I'm stuck, the senior solves it." They never develop the skill of working through hard problems alone, because the senior always intervenes.

The cure: notice the rescue urge and resist it. Replace immediate help with prompts that develop their thinking. It feels worse in the moment — they're still stuck, you could solve it in 30 seconds — but it builds the skill they need.

09Failure mode 3 — vague feedback

"Good job!" tells them nothing they can replicate. "You need to be more careful" tells them nothing they can change.

Specific feedback names the action, the context, and the impact. "When you asked about the database migration in the design review, you saved us from a six-hour outage. That kind of catch is exactly what senior engineers do — keep doing it."

Specific feedback is harder to give. It requires you to have actually paid attention. But it's the only kind that develops people.

10Tracking trajectory, not snapshots

A junior engineer's quality varies week to week. Some weeks they ship great work. Other weeks they're stuck and frustrated. Snapshots mislead — if you evaluate based on the last two weeks, you'll miss the trend.

Track trajectory over months. Are they faster than 3 months ago? Asking better questions? Catching more in their own code review? Going to fewer people for help? Picking up new systems faster?

That trajectory is the real measure. A junior on an upward trajectory is succeeding even if this week was tough. A junior who's plateaued — same questions, same mistakes, same speed as 6 months ago — has a problem that needs addressing, regardless of how this week went.

∞The compound

Mentoring well is one of the most leveraged things a senior engineer can do. Every junior you help develop becomes someone who can develop the next batch. The compounding effect on the team is enormous — far larger than any individual contribution you could make.

It also makes you a better engineer. Explaining things forces clarity. Watching others struggle reveals the assumptions you'd forgotten you were making. Some of the deepest learning happens when you teach.

Done well, mentoring is the multiplier that turns senior engineers into team-shapers. Done badly, it's a tax that makes everyone slower. The difference is in the patterns above.