
Ask HN: Strategies for mentoring junior developers? - PaulStatezny
Software development companies are often willing to hire developers who need a lot of guidance and direction. (Developers who can’t excel without help.) But a large segment of these companies have no strategy or program in place to help such developers reach proficiency and independence.<p>What are some good, holistic approaches for helping train up-and-coming developers all the way to “senior developer” skill level?
======
bertil
Junior developers and newbie in general have one incredible quality: they
don’t know and they are not supposed to. You absolutely want to tell them that
their role is to criticise and occasionally write the documentation. Start
from things that are obvious and leverage their question: anything they ask,
tell them it’s now their role to document it. How the business makes money,
what that metric means, what is TDD, what happens with this fails, whether the
company actually ships bug-free code.

One pattern that I use:

\- pair program initially; I would do that even for principal, just to be
familiar with the code base, but for probably one or two days, after that,
they should be autonomous; for very junior developers, a week make more sense,
but rarely more;

\- gradually replace that with code review, but more than once a day for more
junior people; ask them kindly to commit; make sure to point out one or two
issues in each very small PR: linting, method naming convention, then testing
patterns, structure, etc.

\- have scheduled 30 minutes 1:1 meetings, preferably thrice or twice a week;
make sure there is something nice at some of those: ice cream, walk out if
it’s sunny, and have that meeting have four very explicit parts: what they
have done, what blocked them; what they have learned; what they have taught
(or documented). The last one is often overlooked but it’s very important for
them to realise that they start owning some code, that they should think not
of they direct impact but how to empower people. React to blockages by
offering solutions, both from them and from you: they need to learn to unblock
and that’s how you do it. Move that meeting to once a week for senior
developer, once a fortnight for principals.

~~~
afarrell
> anything they ask, tell them it’s now their role to document it.

Depending on how you interpret it, this advice is either great or terrible. If
you read this to mean that the new person to a project should start out by
documenting the things they don't know, then this is bad:

\- There are definitely Open Source projects which have this attitude and
don't write user-facing documentation, expecting new-joiners to write it. This
makes it both hard for a new person to join a project and hard for the project
to market itself.

\- If you are just starting out on a project, it can be hard to know what are
the key concepts that a person should really know in order to be efficient and
what is incidental. It may or may not be a good idea for them to spend a bunch
of time documenting ways in which your test setup uses selenium after running
into some really weird end-to-end test bug.

\- If you don't know something, it is really hard to write a coherent
explanation of it. You have to both empathize with ignorance _and_ have the
knowledge. Otherwise, you can just end up stuck/lost. If you don't have anyone
willing to help you un-stick yourself...

But that doesn't sound like the interpretation you mean.

From the rest of your post, it very much sounds like you mean that the new
person should turn a vocal explanation into a written one as a way of both
confirming their knowledge and passing it on to others. This sounds great. It
will generate lots of draft docs though, so you probably need some habit or
person to keep them organized and keep them from getting stale.

~~~
bertil
I certainly try to structure their documents a lot, and point them at the
people who can answer their question -- although most of my energy is spent
not assaulting anyone refusing to document properly with ”but I know it, so
it's fine, you just have to ask me” or ”but it’s on an email somewhere, is
that not enough?”. The best audience for the document is “who you were two
days ago” and they generally have some empathy for that person for a day or
two.

------
bpowell
One of the best ways I found is to hire in pairs. Don't just hire one junior
(or entry level) at a time. Hire two or more at once so they can help each
other learn your stack. At the university I work at, this is how we handle it.
We hire a lot of students to help develop our application. These students are
far from entry level when we hire them. Most have taken maybe one CS class at
the university level.

It takes a lot of time to mentor these students, so one of the ways we handle
that is have some of the more "seasoned" student developers help train. This
works out very well for us, in that we have two seasoned student developers
that help train the four fresh students we have. The questions that the newly
hired students have can generally be answered by another student, because they
probably had the same problem. While these seasoned students help out a lot, I
still have to spend time mentoring and training. Be prepared to spend more
time than what you think, but the rewards pay off in the end.

Also it helps if you find what the developer is passionate about and maybe
find work that aligns well with that. We had a former student that once we
found out they wanted to do iOS development, we put them on that task and they
really shined. It does take some work to find out what they want to get into,
but it has worked well for us.

As for getting up to the "senior developer" skill level, that is not something
that we have baked into our student program. Once a student graduates, they
can no longer work with us. It takes more than the typical 4-5 years to
graduate university to hit that level.

~~~
monocasa
As somone who started the same day as another junior developer in my first
job, I second this.

Just having someone who's also junior who you don't feel any shame about
asking stupid questions to is killer. You shouldn't feel any shame either way,
but that's sort of one of the things you learn transitioning out of a junior
role.

~~~
fdafellow
Would you able to divulge the name of the company?

~~~
monocasa
There's not really any value. This was many years ago, and the company has
changed a lot. It also isn't a company many people have heard of.

------
songzme
Don't write code. Break down a feature into tasks that you would take 30 mins
or less to accomplish. Have them build each task one by one. If they take
longer than 1 hour, you know that they are stuck on something so you can go
help them. While they are working on 1 task, you are figuring out the next 2
tasks. Your job becomes quick prototyping to make sure the tasks are feasible.

Eventually, after many small merge requests, junior developers will be
comfortable to take up entire features. After a few features, you teach them
how to break down tasks for other junior devs, just like what you were doing
before.

We have been actively following this method for the past 2 years and have
taught engineers with 0 coding background all the way to become tech leads in
our org.

~~~
jbhouse
Sounds super interesting, though it's not something I've heard of before. Is
this a common practice I haven't heard of or a process unique to your company?

~~~
songzme
It's not a practice we have read anywhere, it's something we experimented with
and worked

------
muzani
Pair programming for sure. Senior designs the code, junior writes it. Senior
doesn't touch keyboard. It's real time code reviewing.

The senior's time is rarely wasted. They can always do time consuming high
level work like designing test cases, planning out the next part of the work,
seeing if the API supports stuff.

~~~
donttrack
I would leave, if someone made me do pair programming.

~~~
razodactyl
This is silly, you shut down the idea without any reasoning. I've found this a
great way to get integrated into a new team and occasionally when banging
heads against a wall trying to figure out an issue.

In reality, pair programming happens very rarely but when it does it's very
useful.

~~~
donttrack
I also hate team building exercises, so there's that. Just let me go home.

------
nerdy
How you mentor has a lot to do with the particular topic and the relative
knowledge and skill levels of the people involved.

For example, if you're trying to teach TDD strategy then pairing might be best
because there's a lot of nuance to how things are done. Environment setup.
Tests come first. Make sure all the tests pass before moving on. Refactor
between. So for TDD it would be difficult to provide a big list of dos and
don'ts and expect someone to navigate them.

Some skills are contextually less rigid than TDD. Debugging a problem for
example: if a developer is trying to use an internal API but they are getting
a timeout response instead of any actual output. You could simply tell them to
see if the HTTP server is running, but it's probably better to ask questions
and explore the problem vicariously. "What do you think the problem could be?"
Then you can arrive at gaps in their understanding about how the system or
HTTP servers work.

Asking questions when there's that too-familiar "we've gotta get this stuff
done" atmosphere can be challenging. It's tempting as a senior developer to
just provide the answer without slowing down and exploring the problem with
your junior counterpart.

There's also institutional teaching. Is the junior developer asking questions
which should be addressed in documentation? If so, you should probably commit
those answers to the documentation and have the developer act as a litmus test
for the completeness of the information.

So teaching can be showing, sometimes it's a matter of explaining, and other
times it's more important to just ask the right questions. I think one of the
most important parts of teaching is perspective-taking. You want to explore
the areas just adjacent to the person's knowledge.

Also, blameless postmortems. It's easy to point fingers when shit goes wrong.
Don't.

Developers junior to me ask questions which I find border on alarming
sometimes but I suppress that reaction because I would rather fill those
dangerous gaps than have a developer be too scared to ask.

------
Hydraulix989
The best thing to do is teach them to dig into problems, learn on their own,
and think for themselves. They will have to learn how to deal with missing
documentation and unclear/messy code. They will have to learn how to unblock
themselves when they are blocked, rather than just getting stuck. They will
have to learn how to work around obstacles and think outside the box whenever
the immediate initial solution that comes to mind turns out to not be a
working one.

Coworkers shouldn't be treated as StackOverflow unless absolutely last resort
because it is incredibly distracting to answer mentees' easily-Googled
questions about built-in language API calls every 15 minutes or so. A lot of
programming is just professional Googling. Once they can function
independently, they are no longer junior developers IMO, but this is a learned
skill.

When I started programming, I had enough people on IRC berating and insulting
me for asking about standard C library calls that I learned how to research
and solve my own problems the hard way (the acronym "RTFM" is toxic). It felt
awful, and I can imagine a lot of people getting discouraged and just giving
up.

I was in high school trying to write my own malloc just for fun, and random
strangers on the Internet kept calling me an "idiot" because I was still
learning pointer arithmetic and needed help (and nobody IRL could help me).

------
DougWebb
I've always been a fan of assigning maintenance tasks to junior devs (or
anyone who's new to an existing codebase.) These are tasks that are often
lower priority so there is less time pressure to get them done right, and they
give the devs the opportunity to learn the codebase. Working on existing code
you don't know yet is also a lot easier than new development on code you don't
know (and coding standards you don't know), so that makes it a better
introduction for the new devs too.

~~~
ManlyBread
I understand the rationale, but after getting the "maintenance" role a few
times it feels me with dread. Usually when I get maintenance tasks it's for a
system no one else wants / dares to touch. Evey time I feel like someone
punched me in the face because it's always accompanied with the words like "we
need someone else to know this system", "it's only for a little while" and the
truth is that if you gain minimum competency in such a system you can say
goodbye to more fun tasks - the maintenance of this old crap is your life now.
No company will let someone with a knowledge of some obscure shit stop
maintaining the obscure shit and move that person to a project that doesn't
suck. Currently this is the 4th time I'm tied up in such a situation and while
I was promised to be allowed to work on the "more fun" project "after 6 months
so I can get my feet wet" the very last day of these six months I was told
that one guy is leaving the company and that I can't work on the fun project
because the obscure shit won't have enough manpower. The corporate machine
works so slow that it will take at least another six months before someone
gets hired. Hell, they're so incompetent that they don't even have a job
posting yet.

------
therapeutic
As a junior dev, I've appreciated small signs that other people in the office
are looking out for me and my progress. This can be anything from regular one
on ones with my direct manager, to other engineers asking if I have any
questions when working in a new codebase. I'm the only junior in my office, so
at first it was kind of horrifying asking questions and looking for help.
Since other people have been more proactive in making sure I'm set up properly
I've felt a lot more confident in taking steps on my own to figure things out
and I think it's helped a lot.

------
Dannymetconan
As a junior dev one aspect of mentoring which I have always valued is being
given time to explain to a senior dev how I am about to go about implementing
a solution. This coupled with feedback on how I should change my code and why
is great.

------
Jach
I think the lack of explicit programs is because the path is often "stick
around long enough to have enough things you can point to that look similar in
complexity / effort as other things people with the Senior title have done."
If all those things require relatively little hand-holding then the solution
is just progressively less and less hand-holding, often in the form of "toss
them in the deep end and only go hold their hand once they ask for it". That
has some negative incentive structure of course, but so do other suggestions
proposed here...

Maybe instead focus the mentoring on becoming a better dev. Have them join
your book club (or paper club, talk club, blog club, whatever) that you in
theory already have going on where engineers at whatever levels get together
and discuss a topic and how it can be applied to make them better engineers or
have better team dynamics etc. Maybe do some applying exercises / experiments
too.

The "junior" and "senior" distinction isn't very important beyond salary
negotiation, and often the "needs guidance to excel" or "not fairly
independent yet" criteria can be misleading too because it's somewhat
sensitive to the work and work environment in question. If you really want to
mentor a junior into a senior you just need to make them more like the what-
does-this-company-mean-by-senior person, which might not correlate very well
with good engineering at all and can differ quite dramatically from company to
company.

------
sixhobbits
I've seen several people mentioning pair programming, which I haven't found
useful (too much time wasted while one person is coding the "easy" parts, and
not enough time for the more experienced person to think about the difficult
parts. YMMV.)

In my experience, the most helpful way is

1) code review. Several iterations of all new code. Efficiency, style,
correctness, smaller functions, don't repeat code. This takes time, and as the
person doing the reviews, you might feel like you aren't getting anywhere, but
a few months done the line it will be very rewarding when it finally "clicks".

2) Looking at code and theory in 1:1s. Normally I spend about 10-30 minutes on
HR type stuff and the rest of the ~1h 1:1 is spent on training/mentorship.
Sometimes looking at specific code reviews and explaining reasoning behind the
comments in more details. Sometimes it's to fill in gaps in the person's
theoretical knowledge about syntax, algorithms, style, unit tests, caching,
whatever weaknesses were identified.

1:1 time and code-review should form the basis of all coding education at all
levels IMO.

Shameless plug for HyperionDev[0], the coding bootcamp provider I'm working
with where we focus on 1:1 time and code review both for our customers and for
our dev team.

[0] [https://www.hyperiondev.com](https://www.hyperiondev.com)

~~~
hawaiianbrah
one of the pair can tend to other things while the other is hammering out the
“easy” parts... as for the “not enough time for more experienced person to
work through the hard parts”, isn’t the point that it’s a partner activity?
the idea being together, you’re going faster

------
ccccccccccccc
As a junior dev, keep us on the edge of just enough work and too much work.
Too little work seems to cause disdain of the company (questioning why we were
even hired) among my other junior peers. On the other hand, too much work
causes us to burn out too quickly since we are still solidifying our time
management and prioritization skills.

------
d0paware
I think probably one of the most valuable things you can do with your junior
developers is to set expectations around how to ask good questions. Your goal
is to help juniors strike the right balance between spending time figuring
something out on their own versus spending too much time and going way off
track. You also don't want your juniors to ask too many questions that they
should have first spent some time investigating on their own.

There's a good link on this: How to Ask Good Questions
([https://news.ycombinator.com/item?id=13293301](https://news.ycombinator.com/item?id=13293301))

Other than that, I think having a junior shadow you while you debug a bug or
help them debug one of theirs while explaining each step you are doing is also
very helpful.

Something else that's pretty good is to give juniors a shining example of a
high quality SPIKE task on a new technology or design consideration. You want
them to learn by example.

And here are some other links that I've found personally helpful:
[https://softwareengineering.stackexchange.com/questions/1383...](https://softwareengineering.stackexchange.com/questions/138396/how-
to-mentor-a-junior-developer)

For you:

Ask HN: How to manage developers who "aren't very good" (because let's be
honest, we've all had this sentiment before whether or not the developers were
actually bad or not)
[https://news.ycombinator.com/item?id=9008845](https://news.ycombinator.com/item?id=9008845)

For your juniors, to give them something to aspire to:

On Being a Mature Engineer [https://www.kitchensoap.com/2012/10/25/on-being-a-
senior-eng...](https://www.kitchensoap.com/2012/10/25/on-being-a-senior-
engineer/)

Ask HN: How to Be a Good Technical Lead?
[https://news.ycombinator.com/item?id=10395046](https://news.ycombinator.com/item?id=10395046)

------
rdsubhas
(assuming mentoring them with the objective of becoming "engineers" rather
than staying developers)

Many code pairing/reviewing strategies assume that the mentor is the one who
has to teach everything on the job. Its not true, it slows everyone down and
leads to "lots of talking" and less coding.

Don't by shy of making them have a follow up learning checklist. When you are
pairing or reviewing, leave them links that have helped you on the past, or
give them concepts that they should learn in order to more effectively do the
same task. The next day, ask them if they have had a chance. Not as a way of
"control", its totally fine if they don't, and its also totally fine if they
have "glanced through" theoretically. If they are eager to learn, they'll be
asking you more questions back, and you can fill in the gaps (or point in more
directions). Its as much an effort of the mentee as the mentor.

Junior developers often just need "direction" because they don't know what
they don't know. But they're quick to explore further only if pointed the way.
Give them the resources they need to learn, not necessarily the learning
itself and keep following up. Contrary to many opinions, juniors like having
tough mentors (which is why mentor should not be a reporting figure).

Communication and social skills are a large part of development. You should
also be guiding them specific to the organization context, whom to reach for
what, how to communicate better in different circumstances, how to reinforce
basics (writing tests), make them present something they learned, help them
build visibility by attending meetups, how to make decisions on technology,
how everything has tradeoffs, how to negotiate their salary, how to talk
product stuff with product (biz to biz, qa to qa, executive to executives),
how to escalate from personal > IM > emails > calls > meetings, habits like
task tracking and learning to estimate by slowly working on complexity points
and matching up with their "self velocity", how to say no to more tasks and
avoiding burnout, etc.

The mentor only provides useful guidance, but in the end, the execution is up
to the junior and the context of the problem they're working on. Ideally they
should also not be having one mentor, but many with different styles and
opinions.

------
Insanity
You can ignore pretty much everything I wrote underneath, but if one thing, I
feel like this video really helped me as a senior engineer:
[https://www.youtube.com/watch?v=m6G8f9pZZRM&t=1594s](https://www.youtube.com/watch?v=m6G8f9pZZRM&t=1594s)

Don't see them as a 'nuisance' or something that's not "part of your job". As
a senior developer, it is at least implicitly part of your job to mentor
junior developers.

It helps to really take out time to help them, I schedule some sessions in
which they can ask anything about anything related to programming. The
language we are working in, the program we work on, general computer science
questions. This has received quite positive feedback overall.

Often junior developers are scared to ask questions because they 'know' they
are 'wasting' your time with their questions.

~~~
btbright
I was going to post a link to that video, too. Great talk!

------
bensummers
My company has put a lot of effort into helping junior developers get a really
good start to their careers. To a certain extent, you have to structure your
work to enable this. I'd suggest seeing the support as a wider thing than just
the activity of mentoring.

I wrote some notes:

[https://www.haplo-services.com/blog/2017/working-with-
early-...](https://www.haplo-services.com/blog/2017/working-with-early-stage-
developers)

------
xsmasher
Make sure you foster a culture of asking dumb questions. It should be clear to
all of your developers that they should ASK whenever they are stuck, or don't
know something, or when they need a rubber duck.

We have a "stupid questions" chat channel at work, and juniors and seniors
alike are expected to use it when they need advice. If new developers see
everyone putting their egos aside and asking for help, they are likely to
follow suit.

------
eysquared
I think this largely depends on where in their career they are and how
familiar they are with coding in the environment they just found themselves in
(large org, small company, startup, tech stack, etc).

In general I find pairing a new hire with a less senior but relatively new
hire to be a good way to get them ramped up quickly. Ideally this person has
recently gone through the same process and can help get the new person
unstuck. It also very much helps in the first few weeks to have a single point
of contact to ask all the basic questions to get them up to speed before they
feel comfortable reaching out to the larger org.

After this its all about knowledge transfer and task management. Helping them
understand why things are the way they are, not just how. There is a tendency
for new devs to come in and want to change everything to be "better" without
understanding the reasons for the current state of the world.

Once they are up and running, giving them larger and larger tasks with less
and less guidance will get them out of their comfort zone and needing to get
better integrated into the team. They will need to ask for help from an area
expert, sync with PM, and be responsible for something end to end (though
likely already pre-defined by someone more senior).

If they've made it past that point they should start becoming more autonomous
and a great candidate to be a mentor for new devs coming in. Once they hit
this stage, I find giving them more responsibility and less guidance can help
them grow, fail, and learn.

I could write a lot more about this subject but thats a general idea of how I
look at the ramp up process. Getting to Senior is a whole different topic, but
for context I've only ever worked at large tech firms so thats the only
definition of Senior I know.

------
scarface74
I very much struggled with training a junior developer that cane out of a boot
camp. I couldn't teach him how to logically find an issue just by tracing the
data flow.

While I stagnated for years and became an "expert beginner"
([https://www.daedtech.com/how-developers-stop-learning-
rise-o...](https://www.daedtech.com/how-developers-stop-learning-rise-of-the-
expert-beginner/)) at one company, I've never been a "junior developer". By
the time I got my first job at a small company, I already had 10 years of
experience as a hobbyist and knew how to program.

It's easy to mentor someone who knows the fundamentals of how to logically
break an issue down and throw out some ugly code to get them to a "clean code"
stage or even teach them a language.

But if they already know the fundamentals of development as a junior
developer, it's pretty easy to get to the next step with time, lunch and
learns and reading a lot.

~~~
proverbialbunny
It's rather easy to teach these basic skills. Breaking a problem up is as easy
as that: your description of it teaches it.

The trick with newer programmers is to take an abstract concept, such as that,
and then bridge it to a concrete pattern that can be visibly seen and
explored. You have to demonstrate, often out loud, your thought process while
you're working through a problem, much like a job interview. Also, you'll want
to go slow enough they're comfortable asking questions, taking notes, and
doing google searches and what not, or only having very small talks at a time
like 5 min at a time small slices.

Usually you'll want them at the keyboard to learn debugging with you over
their shoulder, but if their skill level is absolutely basic, then you might
want to be at the keyboard, and just run over problem solving of a easy 5
minute problem. By watching you run through a debugger and watching you google
search for help (bonus) will give them enough idea to start doing it
themselves, then in a couple of days you can switch and have them at the
keyboard.

------
crdoconnor
Pairing. Ideally let the junior drive.

This is also a good way of getting new seniors up to speed on a code base
they're unfamiliar with.

------
kodablah
Give em small projects and code review them big time (kindly of course).
Accept a bit of argument (i.e. don't get hung up on requiring humility from
the junior, mistakes bring that on their own). Do not be time constrained on
these initial projects but keep on top to prevent interminable bike-shedding
or pursuits-for-perfection juniors often have. If no improvement is shown over
time, there is just not much you can do...sometimes mentoring means
recognizing when it's fruitless.

------
detay
\- Pair coding \- Periodic code reviews on codebase as a team (on weekly
diffs) \- Providing team a development guideline and enforcing it.

------
fdafellow
"Software development companies are often willing to hire developers who need
a lot of guidance and direction." Is it in US? As a developer with 1 year of
experience I find most of the companies are looking for only junior(3-5 years)
or mid(5 - 7years) or senior(7+ years) of experience.

~~~
chrisper
Where are you located? I am in Europe as well and we consider Junior 0-2, Mid
2-5 and senior 5+.

------
sheepmullet
The most important thing is to allocate enough time to help them - 20 hours a
week for 2-3 months followed by 10 hours/week for the next 1-2 years is
usually enough.

------
csnewb
Out of curiosity, how many years of experience categorize a developer as
"junior"?

~~~
rkho
I don't think it's about years of experience -- someone who does the bare
minimum for five years and never provides input could very well still be
categorized as "junior"

~~~
chrisper
Would that also work the other way? Someone providing a lot of input within 2
years is to be considered senior?

~~~
troebr
It's all about what they bring to the table. Some people are clearly senior
level after 2 years: they communicate well, they can mentor other engineers,
they can criticize an existing design or plan the implementation of a new
feature, have good organizational skills etc.

After 2 years I wasn't able to provide constructive feedback without being a
little too brash, I couldn't have designed anything distributed, I wouldn't
have been able to break up a gigantic feature into smaller problems etc. I've
worked with people who were technically competent and mature 2 years after
school.

