# Mentoring Junior Developers: What Actually Works?

I've mentored developers on nearly every team I've led, and I've made most of the mistakes you can make while doing it. The biggest one, early on, was thinking mentorship meant having the answer ready whenever someone got stuck. It doesn't. It means building someone's ability to get unstuck without you.

### Answering less than you think you should

When a junior developer comes to me with a bug, my instinct used to be to look at the code and just tell them the fix. It's faster in the moment. It also teaches them nothing except that the fastest path to a solution runs through me.

Now I ask questions instead. What have you tried? What did you expect to happen, and what actually happened? Where do you think the problem might be? Most of the time, they find the bug themselves halfway through explaining it to me. The ones who don't still walk away having practiced the actual skill of debugging, not just watched me do it.

### Code review as a teaching tool, not a gate

A code review that just says "change this" transfers nothing. A code review that explains why transfers something every time. I try to make every comment carry a reason, even a short one: "this will fire a query per item in the loop, worth using `.Include()` here to batch it." Over time, people stop needing that specific comment because they've internalized the reasoning, not just the rule.

I'm also deliberate about what I don't comment on. Not every stylistic preference needs to become someone else's problem in a review. I save the feedback for things that actually matter: correctness, maintainability, and patterns that will bite them later, not whether they'd have named a variable slightly differently than I would have.

### Pairing on the hard problems, not just the easy ones

There's a tendency to hand junior developers the simple tickets and keep the interesting architectural problems for senior engineers. I understand the instinct, deadlines are real, but it quietly caps how fast someone grows. I try to pull junior developers into at least some of the harder design conversations, even if they're mostly listening at first. Watching how a senior engineer reasons through a tradeoff teaches things a ticket never will.

### Letting people fail safely

Some of the fastest growth I've watched happen came from someone making a mistake in a low-stakes environment and working through the consequences themselves, not from someone preventing every mistake before it happened. Part of mentoring is knowing which mistakes are safe to let happen and which ones genuinely need to be caught before they ship. A bad naming choice, let it go and revisit later. A change that could take down a payment flow, that gets caught before merge, every time.

### Consistency matters more than any single conversation

The developers I've watched grow the most weren't the ones who had one great mentoring conversation. They were the ones who had a steady stream of small, honest feedback over months, delivered consistently enough that it became normal rather than a big event. Mentorship isn't a program you run for a quarter. It's a habit you build into how you already work with people.

### The return on this isn't just their growth

Every developer I've helped grow into someone who needs less of my time has freed me up for the problems only I can solve. That's not a cynical read on mentorship, it's just true, and it's part of why I keep doing it deliberately instead of treating it as something that happens automatically when people work near each other.