I Learned More From Mentoring Than My Mentee Did

I Was Assigned as a Mentor

In my fourth year, I was assigned to mentor a new developer. My first reaction was "am I really qualified to teach anyone?" This is the same person who accidentally wiped the team branch with a bad rebase 2 years ago — and now I'm a mentor. But the team said "give it a try," and I had no reason to refuse.

In the first 1:1, my mentee asked "what's hoisting in JavaScript?" I started with "well... var gets hoisted up..." and then froze. I'd used it plenty of times, but trying to explain it accurately? The words wouldn't come.

(I told them "hang on, let me organize my thoughts and explain tomorrow." Honestly, it was embarrassing.)

You Need to Know 3x What You Teach

To answer my mentee's questions, I needed precise understanding. "Kinda knowing" isn't enough to explain something. So I started studying topics my mentee might ask about each week. Closures, prototype chains, the event loop, how async/await actually works.

I'd used these things successfully in production for 3 years, but when asked to explain the underlying principles, I stumbled constantly. The difference between Promise.all and Promise.allSettled? I could use them, but I couldn't explain the internal logic of why they behave differently. Mentoring forced me to dig into all of these one by one.

The Power of "Why?"

Every time my mentee asked "why?" I found myself thinking harder too. "Why does our team use Zustand instead of Redux?" — I'd actually never thought about the reason properly. I'd just followed what my senior decided. Thanks to my mentee's question, I went back and documented the rationale behind our tech choices.

Questions like "why did you split this component this way?" were great too. They made me examine the reasoning behind things I'd been doing on autopilot.

Mistake: I Gave Answers Too Quickly

At first, whenever my mentee got stuck, I immediately gave them the answer. Watching them struggle for 15 minutes was hard. The urge to say "just do it like this" kept bubbling up. But doing that meant my mentee never got the experience of solving problems on their own.

Around month 3, I started asking questions instead of giving answers. "What does the error message say?" "What have you tried so far?" "There's similar code in another file — can you find it?" This approach dramatically increased the rate at which my mentee found solutions independently.

What Changed After a Year

My mentee was independently developing features by month 6. By their first anniversary, they were giving solid feedback in code reviews. I was genuinely impressed by their growth speed.

But the surprising part was my own growth. My fundamentals became much stronger than before mentoring. As my ability to explain improved, writing technical docs and giving team presentations became easier. In code reviews, instead of saying "this is bad because..." I could say "if you change it like this, it'd be better because..." — and actually explain why.

Mentoring Is a Learning Investment, Not a Time Investment

Every week: 1 hour for 1:1s, 30 minutes for fielding questions, 1 hour for code reviews. That's about 2-3 hours per week on mentoring. At first I thought "I could be writing code during this time." Now I know these are my most efficient learning hours.

"Teaching is the best form of learning" sounds like a cliche, but having actually done it, it's true. That said, good mentoring depends on the relationship with your mentee, and chemistry varies — so it doesn't always produce great results.