Teaching junior developers: a guide for seniors who have never mentored

Most senior developers become mentors without anyone telling them how. A junior joins the team, you are the person who knows the codebase, and the job lands on you. The first instinct is to fix their problems quickly. It is also the instinct that teaches them the least.

Teaching a skill is different from having it. The habits below are the ones I would give a senior developer who is mentoring for the first time. None of them needs a training budget.

1. Decide what you are teaching

“Help them improve” is too vague to act on. Pick two or three concrete things for the next quarter, and agree on them with the junior. They usually fall into three kinds:

• Skills: writing tests, using the debugger, reading a stack trace, writing a clear commit message.
• Knowledge: how the system fits together, why the data model looks like it does, how deployment works.
• Decision-making: when to ask for help, when a shortcut is acceptable, how to split a task.

Skills can be practised, knowledge can be explained, and decision-making can only be demonstrated and discussed. Mentors who treat decisions like facts (“always do it this way”) produce juniors who follow rules without understanding them.

2. Explain the reason, not only the fix

Compare two review comments on the same line:

Use Promise.all here.

These two requests don’t depend on each other, so they could run in parallel. Promise.all would cut the wait to the slower of the two. Would that help on this screen?

The first gets the code fixed. The second gets the next hundred similar cases fixed without you. It costs one more sentence.

A few habits make review comments teach:

• Prefix small matters with nit: and say clearly which comments block the merge. Juniors tend to treat every comment as an order.
• Ask a question when you are not sure, and state a fact when you are. Mixing the two (“maybe you could possibly…”) hides which one you mean.
• Say what is good. Naming one thing that works well tells them what to repeat.
• Let the formatter and linter argue about style, so your comments are about design.

3. Let them struggle, with a time limit

You learn debugging by debugging. If you hand over the answer within a minute, they learn that you are the debugger.

At the same time, someone who is stuck for a whole afternoon without saying so learns nothing and loses a day. A rule that works for both sides: try on your own for 30 to 45 minutes, then ask, and bring what you tried. Say it out loud on the first day, and tell them that asking after that is expected, not a weakness.

When they do ask, go up a ladder instead of straight to the answer:

1. Ask what they have tried and what they expected to happen.
2. Point at the area: “Look at what the response contains before this line.”
3. Show a technique: “Add a breakpoint here and inspect the value.”
4. Only then show the solution, and have them explain it back.

4. Pair on the hard parts, with them at the keyboard

Pairing is the fastest way to transfer how you work: how you navigate code, what you search for, how you decide what to try next. It also tires both people, so use it where it pays off: the first task in a new area, a tricky bug, a design that is not clear yet.

The most common mistake is taking the keyboard. If you cannot stand watching them type slowly, that is exactly the part to practise. Ask them to think aloud, and keep your hands off unless they ask.

5. Give real work with a safety net

A junior who only gets exercises stays a junior. Give them a small slice of real work: a bug in production code, a small feature behind a flag, a refactoring with good tests around it. Review it carefully, and make sure a mistake cannot hurt customers.

Be clear about who owns the result. If it is theirs, then you do not quietly rewrite it at night. A review comment is the correct channel.

6. Make mistakes safe to report

The most expensive thing a junior can do is hide a mistake for two days. They will do it if the last time went badly. When something breaks, ask what the system allowed to happen, not who did it. And tell them about your own mistakes, including the unglamorous ones. It shows that making them is part of the job.

7. Meet regularly and give specific feedback

A weekly 30-minute conversation beats an annual review. Use it for three things: what went well, where they got stuck, and what they want to learn next. Feedback works when it is specific and close to the event: “In yesterday’s pull request you split the work into three small commits. That made it easy to review.” is useful. “Good job” is not.

For criticism, describe the situation, what you saw, and the effect: “In the standup you said the task was almost done, and on Thursday it turned out to be two days of work. I’d like to know earlier when something is bigger than expected.”

What seniors often get wrong

Habit	Why it hurts	Instead
Rewriting their code	They never see what was wrong or why	Comment, let them change it
Teaching your preferences as rules	They cannot tell taste from correctness	Say “I prefer” and give the reason
Being unreachable	They sit stuck and hide it	Fix a daily time for questions
Taking silence as understanding	Juniors rarely say “I don’t get it”	Ask them to explain it back
Explaining everything up front	Too much to remember	Teach what the next task needs

How you know it is working

The measure is not how much code the junior writes. It is how often they need you for the same kind of problem. After three months, they should ask different questions, ones that are closer to design than to syntax. When that happens, give them harder work and step back a little further. Your job is to become less necessary, on purpose.