The habits that actually shape reliable engineers happen quietly, and none of them are on a mentoring checklist.
Years ago where into working with one of the juniors on my team, I noticed something had shifted. His pull requests were different. Not just the code quality, though that had improved. The way he reasoned about problems had changed. He was asking different questions before he started building. He was flagging risks I hadn’t yet spotted. He was uncomfortable in exactly the right places, the kind of uncomfortable that comes from knowing enough to see what could go wrong.
I tried to pinpoint what had caused it. We hadn’t sent him on a course. Nobody had sat him down for a structured mentoring session. What had changed was the environment he’d been operating in, and specifically, the way a few senior engineers around him had been working.
The things that shaped him most weren’t explanations. They were situations he’d been placed in, and how people around him had behaved when those situations got hard.
That observation has stayed with me. Senior developers talk a lot about mentoring. Pair programming, code reviews, one-on-ones. All of it matters, and I’m not dismissing any of it. But the things that actually change how a junior engineer thinks are quieter and harder to schedule. They happen in the margins of normal work, when nobody is performing the role of mentor.
Here are five of them.
1. They Give Work That Stings Just a Little
The instinct when you have a junior on the team is to protect them from the hard stuff. Give them the isolated tickets. The UI tweaks. The documentation updates. Let them build confidence before you throw them into something complicated.
The instinct is understandable, and it is wrong.
Work that is too easy teaches a junior exactly one thing: that they can coast. Work that is crushing teaches them to wait for rescue. The work that actually develops a junior engineer sits just past the edge of what they can comfortably handle. Hard enough to require real thinking. Contained enough that if they struggle, the whole project doesn’t sink. Not so ambiguous that they have no idea where to start.
Finding that edge for a specific person on a specific ticket is harder than just assigning them the safe ones. Most seniors don’t do it because it takes judgment and time, and fixing the hard ticket yourself is faster in the short run.
I’ve watched this done well. A senior picks something with real design decisions embedded in it, something where the obvious approach has a problem that only shows up when you think it through, and assigns it with context but without the answer. Not “here’s what to do” but “here’s what we’re trying to achieve and here’s why it’s harder than it looks. Come back when you’re stuck.”
The junior returns stuck. That is the point. Being stuck is not a failure state. It’s where the actual learning happens, and a senior who understands that will resist the urge to hand over the solution before the junior has spent real time in the discomfort of not knowing.
2. They Ask “Why” in Code Review, Not “Change This to That”
There are two types of code review comments. They produce entirely different engineers.
The first type says: “Use this pattern instead.” Or: “Move this to a service class.” Or: “This should be wrapped in a transaction.” Clean, efficient, immediately actionable.
The second type says: “Why did you structure it this way?” Or: “Walk me through what happens if this call fails halfway through.” Or just: “What were you trying to protect against here?”
The first type produces a junior who learns the preference. The second produces a junior who learns to reason.
This matters because code review comments don’t stay in the pull request. They become the internal monologue a developer uses before they write code. A junior who has been asked “what happens if this fails?” fifty times starts asking it themselves before the PR is open. The review becomes internalized.
That only happens if the review was ever a question rather than just a correction. The senior who only corrects produces a junior dependent on correction. The one who asks produces a junior who self-corrects. The difference is invisible at six months and obvious at eighteen.
One practical note: asking “why” only works if the senior is genuinely curious about the answer and willing to update if the reasoning is sound. If “why” is just a gentler version of “wrong answer, try again,” juniors pick that up immediately, and it stops working.
There is also a timing element most people miss. The best “why” questions come before the PR is merged, not after the code has been in production for a month. The further away the feedback is from the decision, the weaker the connection. A question about a live architectural choice, while the junior is still thinking inside that problem, lands differently from a retrospective “you know, looking back at that service…” The question needs to be close enough to the moment that the junior can still feel the reasoning they were using when they made it.
3. They Let the Junior Be Wrong in the Meeting
This is the counterintuitive one, and it requires a kind of restraint that feels unkind while you’re exercising it.
A junior comes into a planning meeting and defends a technical approach that has a real problem. The senior sees the problem. The room might not yet, but someone is going to push back, and when they do, the junior’s position is going to come apart.
The natural move is to step in before that happens. Offer a redirect. Soften it. Spare the junior the experience of being wrong in public.
That intervention is a theft.
The junior who has to defend their own idea under real scrutiny, not aggressive, not personal, just the ordinary skepticism of a competent team, learns something no tutorial delivers: what it feels like when your reasoning is being tested by people who are not trying to be kind about it. They learn where their logic was thin. They learn how to hold ground on the parts that are right and concede the parts that are wrong without losing composure. They learn, crucially, that being wrong in a meeting is survivable, and that surviving it is how you get taken more seriously.
The senior’s job in that moment is to stay quiet until the thing resolves, then follow up after. Not a critique of what they missed. Just “how are you thinking about it now?” That question is enough. The junior usually already knows what happened.
4. They Say “I Don’t Know” Out Loud
This one is underrated to the point of being nearly invisible.
When a senior engineer says “I’m not sure, I’ll check” in front of the team, they’re not just modeling intellectual honesty. They’re giving the junior explicit permission to not know things. That permission is not trivial.
A lot of juniors carry around a constant, quiet anxiety that they should already know more than they do. That their gaps are a kind of shame they need to manage. That admitting uncertainty is the same as admitting they’re not good enough for the role. When the senior openly says they don’t know, that anxiety gets smaller.
The alternative is more damaging than it looks. When seniors perform certainty they don’t actually have, and it happens more than people admit, the pressure to sound authoritative is real, juniors watch and learn that faking it is required. That projecting confidence regardless of what you actually know is part of the job.
That lesson has a downstream cost. The junior who learned that faking confidence is normal will someday make a call they weren’t sure about without flagging the uncertainty to anyone. Something will break that did not have to break.
The senior who openly said “I need to look that up” in front of the team, who treated uncertainty as a normal engineering state rather than a weakness to conceal, gave that junior a different model of how good work actually gets done.
Checking things is not a sign of weakness. It is how correct decisions get made. It just doesn’t look as smooth as confidence.
There’s a related habit that compounds this: seniors who narrate their investigation out loud. Not explaining, narrating. “I’m not sure why this is slow, let me look at the query plan first” is different from “the issue is the missing index on that join.” One of those is a demonstration of process. The other is a demonstration of outcome. Juniors watching the process learn how to debug. Juniors watching the outcome learn what the answer was. Of the two, only one transfers.
5. They Hand Over the Incident
Production is broken. The senior could fix it in ten minutes. The junior either caused the issue or is the one who most understands the change that went out.
This is where it matters most who the senior is.
The senior who takes the keyboard, resolves it quickly, and debriefs afterward is efficient. The junior learns what went wrong. They follow along, take notes, maybe understand it. They probably also feel a mix of relief and mild shame.
The senior who steps back, asks questions, and guides the junior through finding and fixing it themselves gives them something that cannot be conveyed any other way: the actual experience of tracing a live production issue under pressure.
Holding the context of what changed and what the system is doing now. Forming a hypothesis. Making a call. Deploying it. Watching the metrics. Knowing whether it worked or whether you’re still looking.
That experience does not transfer through explanation. It cannot be taught. You can only create the conditions for someone to do it, and a production incident with a senior nearby but not intervening is one of the fastest ways a junior gains a year’s worth of judgment in a few hours.
The instinct to rescue is strong, and resisting it when someone you’re responsible for is clearly under pressure takes deliberate effort. The senior who manages it is doing something harder and more useful than the one who swoops in.
None of these five things appear on mentoring checklists because, from the outside, they look like ordinary work. Assigning a ticket. Leaving a review comment. Staying quiet in a meeting. Admitting uncertainty. Stepping back from the keyboard.
The junior who works in that environment long enough will look like they grew unusually fast. They did. They were placed in the right conditions for it, by someone who understood that the conditions are the mentorship.
The environment doesn’t happen by accident.
