Mentoring Junior Engineers — A Tech Lead's Playbook

When I stepped into the Tech Lead role at Evoke, I went from owning code to owning people's growth. It took me six months to figure out that mentoring is a skill — not a vibe. Here are the rituals that actually move the needle for the engineers on my team.

Weekly 1:1s with a real structure

Most 1:1s default to 'how's the work going?' That's a wasted half hour. I run a three-part format on a shared doc:

• 5 min — Wins since last week. What did they ship or learn? Write it down — it becomes their promo evidence later.
• 15 min — Blockers and tactical help. PR feedback, design questions, anything in their way.
• 10 min — Growth. One area we agreed they're working on (writing tests, system design, code review). Same topic for ~6 weeks until it sticks.

If you can't articulate the one thing this person is getting better at, you're not mentoring — you're status-checking.

Code reviews as a teaching tool

Code review is the highest-leverage place to mentor. A junior writes ~20 PRs a month. That's 20 chances to teach. But the way you comment matters more than what you comment.

• Always say why. 'Use useMemo here' is noise. 'This recomputes on every render because the prop is a new array each time — useMemo will help' is a lesson.
• Use prefixes: nit: (cosmetic), suggest: (your preference, not required), q: (genuine question), blocker: (must change before merge). Removes ambiguity.
• Praise the good code, not just flag the bad. 'Nice use of discriminated union here' costs nothing and builds confidence.
• If a comment thread hits 3 round-trips, get on a call. Async code review is for clear feedback, not debates.

Pairing — but the right kind

I used to pair by sitting next to a junior while they drove. That makes them anxious and doesn't teach much. Now I run two styles, picked by what's needed:

• Driver/Navigator on hard problems. I narrate; they type. Best for new architectural patterns.
• Silent pairing on debugging. They drive end-to-end, I stay quiet unless they're stuck for 5+ minutes. Best for confidence-building.

Growth roadmaps that the engineer owns

Every engineer on the team has a one-page roadmap doc that THEY write and update. It has three sections:

# Bharath — Growth Plan (Q1 2026)

## Where I am
- 2 years React, just started writing tests
- Strong on UI, weak on backend

## Where I want to be in 6 months
- Comfortable owning a full feature end to end
- Confident leading a small project

## How I'll get there (Q1 focus)
- [ ] Ship 1 feature with backend changes (PR by Feb 14)
- [ ] Write a system design doc for the notifications service
- [ ] Lead 2 PR reviews where I'm the primary reviewer

The magic is they own the plan. I help them sharpen it during 1:1s, but the document is theirs. When promo time comes, the evidence trail writes itself.

The 'I'll just do it' trap

The fastest way to stop being a mentor is to start being a doer. I catch myself wanting to grab a Jira ticket because it would take me 2 hours and 'help the sprint.' But the cost is the engineer who was supposed to do it loses a learning opportunity. Now I write a 5-minute Loom of how I'd approach it and hand the ticket back.

What success looks like

I judge my own mentoring by one metric: can the engineer make decisions I'd make, when I'm not there? Two of the 10+ engineers I've mentored have been promoted to Senior in the last year. Three have started leading projects. That's the only KPI that matters.