My first attempt at mentoring was a disaster. I was assigned a new hire, bright but inexperienced, and I decided the fastest way to get them productive was to just give them the answers. They'd ask how something worked, and I'd rattle off a solution. Done. Next ticket. For about three weeks, it felt efficient. Then they came to me with a problem we'd already solved twice, and I realized they hadn't understood anything. They'd just been copying my steps like a recipe.
That was on me. I wasn't mentoring. I was being a human search engine. So I flipped my approach. Next time they asked, I asked back: what have you tried so far. The first few times, the silence was excruciating. They'd stare at the screen, and I'd want to jump in. But I forced myself to wait. After a minute, they'd hesitantly walk me through their thought process. It was usually wrong, but it was a real attempt. That's when the learning started.
There's a nervous energy a lot of senior people have. We want to prove our worth, show we can fix things instantly. But mentoring isn't about showcasing your own speed. It's about building someone else's confidence to be wrong and then figure out why. I started setting aside thirty minutes every afternoon just for questions. Not Slack pings, but actual face-to-face time. I'd pull up a chair and we'd dig into something they'd been stuck on. Not to hand them the answer, but to unravel it together. Sometimes I didn't know the immediate fix either, and that was even better. They got to see that senior doesn't mean omniscient.
One junior I worked with struggled with SQL queries. Every query took them an hour to write. They'd Google, find a snippet, tweak it, hope for the best. Instead of correcting their queries, I asked them to explain to me what a LEFT JOIN does like I'd never heard of databases. Their explanation was wordy and unsure. So I drew a Venn diagram on a whiteboard and we talked through a real data problem from our system. I made them write the query by hand on paper first, no copy-paste. The first few were ugly, full of syntax errors. But after two weeks, something clicked. They stopped guessing. They started thinking in sets.
The hardest part wasn't the technical stuff. It was learning when to push and when to back off. Early on, I'd push too hard and they'd burn out. I remember one Friday afternoon, I assigned a debugging exercise and told them to tackle it over the weekend. Monday morning, they looked exhausted. They'd spent twelve hours on it, barely slept, and were convinced they were failing. I hadn't set boundaries. Now I explicitly say: this is hard, it's okay if you don't finish, I want you to try for two hours max and then stop. The goal is to generate questions, not a perfect solution. That shift reduced anxiety noticeably.
I also learned to celebrate small, specific moments. Not just "good job" when they shipped a feature, but pointing out things like "the way you caught that edge case before I did—that's the instinct we're building." Juniors often can't see their own progress because they're always comparing themselves to people with a decade more experience. You have to reflect it back to them.
The truth is, effective mentoring is slower than doing it yourself. It demands patience I don't always have. But there's a moment, maybe six months in, when they solve something without you. They don't even think to ask. That's when you know it worked. And it's one of the few things in this job that feels like genuine, lasting accomplishment.