I used to think mentoring a junior developer meant being available for questions and catching mistakes in code review. That worked okay for the eager ones who asked a lot. Then I got paired with a new hire named Sam, who barely said a word in our first month. I figured no news was good news. He shipped a small feature and I gave it a quick approval because the code looked clean enough.
Two weeks later the feature broke in staging. The root cause was a timeout he hadn't accounted for, and when I walked back through his commits, I realized he'd been struggling with the API layer for days. He didn't tell anyone because he didn't want to look incompetent. That was my failure, not his. I'd mistaken silence for understanding and assumed that if someone needed help they'd ask for it. In an enterprise environment with senior people moving fast, juniors often won't interrupt unless you make it clear that interrupting is part of the job.
After that I changed how I approach mentoring. Instead of waiting for questions, I started doing short daily check-ins with juniors. Not status meetings, just five minutes of 'what's the hardest thing you touched yesterday and what would you do differently.' It forced them to reflect and gave me a window into where they were actually stuck. Sometimes the answer was technical, like not knowing how to trace a failed message through a service bus. Other times it was about confidence, like being afraid to ask a DBA for read access because they thought it would annoy someone. Both are real blockers.
I also started pairing on tasks more often, but with a twist. I'd let the junior drive the keyboard while I sat beside them and asked questions rather than giving answers. When they hit a wall, I'd say something like 'what have you tried' and then wait through the awkward silence. That silence is uncomfortable but necessary. If I jump in too fast, they never build the muscle of debugging their own assumptions. The first few times Sam would just stare at the screen and shrug. After a couple of weeks he started talking through his thought process out loud, and that's when I knew he was progressing.
One thing I learned the hard way is that code review feedback has to be calibrated. Early on I'd leave a dozen comments on a junior's pull request, thinking I was being thorough. They'd get overwhelmed and fix the easy stuff while missing the architectural issue. Now I split feedback into two buckets: things that will cause a bug if left alone, and things that are style or preference. We discuss the first bucket immediately. The second bucket I mention once and let go. Nobody learns much from twenty comments about variable naming on their first real task.
Mentoring is not a side quest you do when you have spare time. It's the actual work of building a team that can operate without you. I tell my managers now that if a junior developer fails, the senior who signed off on their onboarding shares that failure. Looking back at Sam's first month, I can see exactly where I should have probed deeper. He's a solid engineer now, but he shouldn't have had to learn the hard way that asking for help was allowed. I should have modeled it from day one.