Onboarding Junior Developers

3 months after leaving Hackbright, and I'm still running triage for many of my students who've been hired in the past 6 months. Not that partner companies are mistreating them, or that their skills aren't up to snuff. Most of my triage stems from a lack of real mentorship. Everyone knows that "time-to-useful" with any engineering hire is usually around 2-3 months, but no one really understands what is happening during that time that takes so long, and why some people don't really make it. 

So I'm going to write a book about it.

In this book, I'm going to discuss some of the programs I've seen work, ways they could be better, and most importantly, how to make junior developers useful, quickly, while making sure they understand how their performance actually is throughout the entire process. There will be case studies, research, fun charts and graphs and instructions on how to cost-and-time-effectively hire and onboard junior developers.

But this is a blog post, not a product announcement, so I'm going to drop some insights on you before that. 

A culture of teaching


How many mid-to-senior level developers reading this right now feel like they know everything they need to know to do their job? That they could functionally program without any reference materials, or debug without Google? Anyone who raised their hands probably doesn't work well with junior developers. 

Everyone who didn't raise their hands understands that knowing isn't the important part, reasoning is. Mentorship makes up the space between a productive jr. developer, and an unproductive one. Mentorship mostly consists of style guidance, help in navigating the typically awful reference materials for a given language, and institutional knowledge about the codebase and it's quirks. Junior developers need this, and it's a people skill to be a good mentor. Not everyone is suited to mentorship, but those that are can multiply the output of a junior developer by their own, and end up with much more than either would have produced alone.

Mentors should plan to spend at least 8 hours a week with a junior developer for the first month of their employment, and 5-6 hours for the next two. That's at least an hour a day, preferably in the morning. This should mostly be spent pair programming, or doing an overview of what you expect them to be able to do, and how they might go about doing it. Usually, an honest end-of-day check in is also important, but this can be done over email. Encouraging honesty about what they are having difficulty with is imperative, so that you can give further reading, or explain concepts that might not yet have solidified.


Fostering a culture of learning doesn't end with mentorship, however. Everyone on the engineering team is a learner, and everyone has the capacity to share knowledge. Having workshops and lunch sessions taught by your engineering staff helps encourage senior staff that sharing their knowledge is important, and helps set expectations that it's not just up to them to handle the hard stuff. Teach a mix of beginner and advanced topics, such as explaining how the complex recommendation engine you use works, as well as a primer on your front-end JS framework. This prevents siloing, and also helps jr. developers to feel they can be honest about their actual skill level. You want to foster the idea that you don't expect them to just know, but that you expect them to ask. Junior developers should also be expected to teach, and asking them to explain in depth things you know they will have had to learn on the job will help them with both their credibility and confidence. 

Re-teaching language fundamentals is a good idea- most developers have to learn a new language for their first job, and going over both basic and advanced techniques will help new developers become more effective, faster. You can lean on your existing talent to do this, over lunches and in afternoon sessions, but you may be able to bootstrap it by inviting user groups to put on classes in your office in the evenings. Asking your junior talent to teach things they don't yet have confidence in causes them to investigate deeper, think more critically, and helps others. Having junior talent do a series of short talks that other junior staff is required to attend allows you to parallelize the effort they're individually putting in, as well as give them expectations to measure up to.

Hiring In Groups

Junior developers work best together, in pairs. Hiring a group of 2-6 (or more, if you have the budget and inclination to take on "classes") can be many times more effective. When working together, two jr. developers can more easily ascertain if they need help, learn faster, and have twice the working memory space. When hired together, most jr. developers are net positive twice as fast than when hired alone. 

New developers need someone who they can realistically compare their knowledge against, and who they can freely toss ideas around with. Many jr. developers don't feel comfortable or feel intimidated by other members on their team, out of a feeling that they are wasting time, or their ideas are primitive and too obvious. Most developers probably can remember a time they didn't speak up because they thought their idea was too obvious (and obviously wrong) and so hadn't been covered by the team, only to bring it up later and be told they could have saved everyone a lot of time.

Setting (real) Expectations

Honestly discussing and setting productivity milestones within the first few weeks are extremely important. Understanding what is expected of them in terms of productivity is important, because most new developers will spend most of their time learning the skills they need to accomplish what is expected of them, and they need to know if (for instance) they need to spend more hours at work getting things done, or if they can go home and learn more about the skills their job demands, or if they can rest their brains. 

Realistic milestones are important - if you feel like your junior developers should be blowing away your milestones, then your expectations aren't real, they're just a minimum that you'll ultimately be disappointed in. 

Hiring a consultant

Ultimately, these things are hard to implement. It's tough to look at your existing team, and know who will make a fantastic mentor, what your junior talent should be learning (and teaching themselves). It's hard to know what they'll be capable of 2 months from now, based on where they are now. Hiring an engineering onboarding consultant, or an educational consultant, can be a fantastic option for those running teams strapped for time, or whose teams lack the empathy capital to spend on hours of mentorship. 

Fortunately, consultants exist who can do this kind of thing. I'm one of them (shameless plug) and can help you design an onboarding process, or help your existing onboarding process accommodate developers from a more diverse set of backgrounds than it currently does. These processes can help your existing team save time, identify stars (and bad apples) faster, and help foster the growth of your entire engineering team. 

If I can help, shoot me an email at lizTheDeveloper@gmail.com.

18 responses
Learned a lot from this article. I wish I could share this to my previous employer. :-)
Awesome article, Liz. I'm a former Dev Bootcamp SF grad (Summer 2012) trying to do my part to improve the junior dev mentorship culture in software engineering as well. Just curious as to your thoughts on how to deal with this issue if you have a small, remote, or non-existent development team? As a consultant at Carbon Five, I've found that many of our smaller clients that lack a lot of engineering power are the most willing to hire Junior Dev candidates, but don't have the technical leadership to properly onboard somebody without a lot of experience. Is the only way to deal with this to bring on a consultant?
What you need is for them to create their own wiki. That way, everybody collects information in a form they will understand. I'm a seasoned veteran and a wiki is always my top priority when I have newbies.
Tom, Wikis are a fantastic resource when you have newbie talent. However, too often newer developers are just told "read the wiki", or given a great deal of out-of-date information from the wiki. Having a "getting started" section, and some dedicated time for updating documentation are big keys to pro wiki usage, since a wiki alone won't solve most problems. I think everyone who's ever had to set up their development environment has run into those little, "oh, we forgot to add how to set up x" things. It sucks, but usually documentation is everyone's lowest priority. Being honest about the state of the documentation is difficult, and requires something called "beginner's mind". It's a zen principle, one that requires cultivation to master. It's not something everyone can bring to bear on everything they write, so recognizing that as a unique, developable skill is super important. -Liz
Liz, I completely agree with the points you've made. In my current job, I made a Quickstart and then a troubleshooting section that I have to constantly update. In a previous company I worked for, I did the same and I've heard through the grape vine that the wiki is totally stale--because nobody cares to keep it current. But what is the alternative? I have mentored a lot of newbie developers but they have to also be willing to read books on each new technology we have. I've encountered 20-somethings who came right out and said: "Oh, I can't read books." Dang near broke my heart to hear that and I was forced to do oral mentoring, repeating the stuff we learned the days before at the beginning of every mentoring session. I can do that but it takes a really motivated mentor. A larger problem I find is knowledgeable senior developers who don't like to explain things gradually. So, when a junior developer comes and asks them a question, they basically vomit a huge generalized answer verbally and then the junior has to rush back to her desk and unpack what was said--perhaps missing crucial details. The best alternative in my experience is this. When somebody comes to ask me a question, I open an email to them and I explain it by writing. They listen and just try to understand. When I'm done with that explanation, I press "send" on the email and they have the notes that I just wrote. An alternate way is if they are at their desk doing the driving. That's better practice but only if the mentor is damned patient.
Regarding pair programming, I actually think 8 hours a week might be too little. If you have the resources, you should pair as much as possible. Pairing can allow junior devs to understand what it looks like the complete a real feature end to end, or what strategies you can use to solve a really difficult bug, or things that more senior engineers might consider while building out the architecture of their story.
This post is inspirational! Great writing and great idea for a consultancy, Liz. We've thrown our junior devs into the deepend and it's been scary for them. So much room for improvement!! This posts sets a clearer path for how to do better.
Very good post, Liz! Thanks for sharing your thoughts.
10 visitors upvoted this post.