When I started mentoring junior developers, I thought my job was to transfer everything I knew into their heads as fast as possible. I'd write detailed docs, do pair programming sessions that turned into me typing, and give them laundry lists of books to read. It didn't work. They'd nod along, but then they'd freeze on simple tasks or make the same mistakes I'd just explained. I was frustrated. They were frustrated. Something had to change.
What I finally realized is that mentoring isn't about cloning yourself. It's about helping someone build their own mental model, not just copy yours. The shift happened when I stopped explaining everything upfront and started asking questions instead. When a junior dev came to me with a problem, I'd say "what do you think we should do?" instead of jumping straight to the answer. Most times they were wrong, but sometimes they surprised me with a solution I hadn't considered. That moment was a wake-up call.
The hardest part for me was letting them make mistakes. I'd watch them write code that was clearly going to break in production, and my instinct was to grab the keyboard and fix it. But I learned to bite my tongue and let it happen, within reason. One junior spent three days building a feature that had a fundamental design flaw. When it failed in staging, he came to me devastated. I talked him through what went wrong, and he never made that error again. If I had corrected him on day one, he would have learned the fix, not the lesson.
Another thing that helped was scheduling dedicated one-on-one time and actually protecting it. Not the kind where you're half-checking Slack or answering emails. I block an hour every week, no meetings, no emergencies. We talk about code, sure, but also about career goals, imposter syndrome, and the weird politics of our team. That trust pays off when they feel safe enough to admit they don't understand something before they've spent a week going down the wrong path.
I also had to unlearn the habit of giving too much context too early. Junior devs don't need to know about the legacy system from 2008 that caused that weird edge case. They need to know what they're building right now and why it matters. I try to frame tasks in terms of business value, not technical debt. The architecture lessons come later, when they've shipped something and felt the pain of a bad abstraction themselves.
What I still struggle with is measuring success. It's easy to count lines of code or tickets closed, but that misses the point. The real win is when a junior developer comes to me with a proposal, not a question. When they say "I think we should refactor this module because of X reason" and they're actually right. Those moments are rare but worth every hour of patience.
Mentoring has taught me more about my own blind spots than any certification ever did. If you're thinking about taking on a junior dev, don't do it because you want to be the wise sensei. Do it because you're willing to learn alongside them. Their fresh eyes will catch things you've stopped seeing. And honestly, that's the best part of the whole deal.