Mentoring juniors has taught me as much as it’s taught them. Here’s what actually helps—and what doesn’t.
1. Explain the “Why,” Not Just the “How”
“We do it this way because…” sticks better than “just do it like this.” When you share context (e.g. “we use this pattern so we can test without the API”), they start to generalize and make better decisions on their own. One sentence of why can save a lot of repeated corrections.
2. Code Review as Teaching
PR feedback is a chance to teach. Instead of only “change this,” add “because…” or “an alternative is X, which is better when Y.” Point them to a doc or example when you have one. Over time, they’ll anticipate the same points and need fewer comments.
3. Pair When It’s Sticky
When someone’s stuck for a while, pair for 30–60 minutes. Share screen, talk through the problem, and debug together. You unblock them and see where they get confused—useful for docs or future onboarding. Don’t take over; guide so they drive.
4. Give Them Ownership of a Small Area
Assign a small feature, module, or bug area they own. They get to design, implement, and maintain it. They’ll ask questions and make mistakes—that’s how they learn. You stay available for review and unblocking, but they lead.
5. Normalize “I Don’t Know”
Make it clear that nobody knows everything. Saying “I’m not sure, let’s look it up” or “good question, I’ll find out” models that learning is ongoing. That reduces the pressure to pretend they know and encourages asking questions.
6. Set Clear Expectations
Spell out what “good” looks like: “We expect PRs to have tests for new logic,” “we comment complex bits,” “we update the README when we change setup.” When expectations are clear, they can self-check and improve without guessing.
7. Don’t Fix Everything Yourself
If you always jump in and fix their code, they don’t learn. Let them fix their bugs (with hints if needed). Step in when it’s blocking the team or when they’re truly stuck, but default to “what have you tried? what do you think we should do next?”
8. Check In Regularly
Short, regular check-ins (“how’s the task? any blockers?”) beat long, rare meetings. They get help when they need it, and you notice when they’re stuck or when scope is unclear.
Mentoring well takes time, but it pays off: the team gets stronger, and you get a clearer picture of how your systems and docs work for someone new. The goal isn’t to create clones of you—it’s to help them think and ship with confidence.
Saad Mehmood — Portfolio
Top comments (0)