How To Train A Junior
One of the fastest ways for a senior to show real value isn’t cranking out tickets. It’s building a repeatable system to bring juniors up to speed. Tell me if this sounds familiar:
- You’re buried in work.
- There’s nobody junior you can safely hand stuff to.
- The junior isn’t leveling up because they don’t get enough time with people ahead of them.
- You feel frustrated and underappreciated.
- They feel abandoned and confused.
That setup is a lose-lose. In the long run, it burns everyone out.
Yeah, management should handle training, but let’s be real: if you leave it all to them, it usually turns into a mess. Seniors can do a lot to smooth the path. What I’m sharing here isn’t “the right way” (if there even is such a thing), but it’s a system I’ve used that lets me actually mentor juniors and still get my own work done.
Onboarding
How you kick things off with a junior sets the tone. Some may call it hand-holding, but in engineering we don’t leave things to chance. If you want clean code, fewer repeated questions, and a teammate who isn’t lost on day three, onboarding matters way more than people give it credit for.
Here’s the checklist I run through:
- Make sure all the boring stuff (tech + admin access) is already handled.
- Walk through their IDE setup. Plugins, configs, this saves hours later.
- Give them a test ticket that forces two commits: one doc update and one small code/test change.
- Share a short list of “who to bug” for infra, design, QA, etc.
By the end of this, you’ve knocked out most of the obvious blockers and they’ve already shipped code. They know who to talk to, how the pipeline works, and what “good” looks like. That’s huge for their confidence. From there, you can focus on teaching the why behind decisions instead of answering “how do I push again?”
Goal Setting
Do you know why your junior took the job? You should. Their answer is going to change how you coach them, how often you check in, and even what you measure.
Example: if a junior says, “I just want to get paid well and go home on time,” Cool. Then frame everything around three things:
- writing solid, maintainable code,
- finishing tickets consistently,
- and hitting bonuses.
They don’t need pep talks about “craft” or “innovation.” They just want stability. So you show them how quality + volume = peace and money.
Now, if another junior says, “I want to be a tech lead in a couple years,” that’s a totally different conversation. You’d lean more into design reviews, mentoring opportunities, and building their visibility.
The point: goals aren’t one-size-fits-all. You’ve got to ask, and you’ve got to keep asking, because life changes.
Here’s the system I use:
-
One-on-ones: Set up bi-weekly or monthly sessions. First two meetings = roadmap building. After that, you’re tracking progress.
-
Quarterly check-ins: Ask what they want out of the job now. Priorities shift when people move, have kids, or just get bored.
-
Document everything: Wins and roadblocks. When it’s time for reviews, you’ll have a paper trail that shows growth, and where they got blocked by other teams.
This makes career growth feel less random. Juniors know you’re paying attention, managers have receipts, and you’ve got a clear framework instead of winging it every sprint.
Day to Day (Sprint To Sprint)
Onboarding gives them the how. Goal setting gives them the why. Day to day is where you work on the what.
By this point, your junior should have a decent map of the codebase. Now it’s time to give them something they can actually own, not just endless random tickets.
I like to give each junior an area of ownership on top of their sprint work. It doesn’t have to be huge just something that makes them “the person” for it. For example:
- Good writer? Have them own documentation quality or summarize sprint reviews.
- Sharp eye for design issues? Make them the dev rep in design reviews.
The goal is simple: build confidence through autonomy. Once they feel like they own something, you can layer in more learning opportunities without babysitting every step.
Some tools that help along the way:
- Office hours for deeper walkthroughs.
- “Best times to contact” windows so they’re not Slacking you every 10 minutes.
- Shadow days where they follow you through a complex feature build.
- Code reviews that teach, not just approve/deny.
- Encourage them to review others’ code early. It speeds up their learning and lightens your load.
This balance keeps juniors moving forward without slowing you down. They get real experience, you get fewer interruptions, and the team grows stronger overall.
Performance Review Prep
This is the part most seniors skip, but it’s where you can make a real difference. Performance reviews suck for everyone: managers hate writing them, juniors panic about underselling themselves. You can step in and fix both.
Here’s what I usually do:
- Pull up the goals you set earlier and remind them of the wins they’ve had.
- Translate vague stuff (“I closed a bunch of bugs”) into something concrete (“Closed 23 tickets, including reducing API errors by 14%”).
- Call out teamwork like mentoring, catching issues in PRs, or improving docs. Juniors almost never mention it.
The truth is, juniors usually underplay their impact. Left alone, their reviews don’t reflect what they actually did. Helping them nail this not only makes them look good, it makes the team look good. And honestly? It makes you look good, too, because you’re basically doing a piece of the manager’s job before anyone asked you to.
Done right, performance reviews turn into receipts for growth instead of a stress fest.
Wait, Isn't All Of This The Engineering Managers Job?
Yeah, technically. But if you leave it all to management, you already know what happens: juniors get tossed random work, they flounder, and you’re still drowning in tickets with nobody to lean on.
Doing this stuff as a senior isn’t about picking up extra chores. It’s about survival and growth:
Survival: A junior who knows what they’re doing frees you up to focus on the hard problems.
Growth: You’re building real leadership muscles that make it way easier to step into staff or lead roles later.
Think of it less as “covering for management” and more as load balancing in real life. Train your juniors well, and you’ll buy yourself back time and headspace. Leave it all to management, and you’ll just stay stuck in the same loop of frustration.
And if you don’t feel like building this system from scratch, I’ve put together a Notion template that covers all the “admin” side of being a senior onboarding checklists, one-on-one tracking, review prep, the works.
It’s the exact setup I use to keep myself sane while training juniors and still getting my own work done. You can grab it here.