loading...

Onboarding a junior developer to your team? Here's 12 tips.

carolstran profile image Carolyn Stransky Updated on ・4 min read

A few weeks ago, my friend Nico König asked the Twittersphere about best practices when onboarding a new junior developer to your team:

As someone who was recently a junior dev, I have a lot of opinions on this topic. So I decided to summarize them in this post (in no particular order).

💭 Distinguish between opinions and best practices

When you're talking over concepts with your junior, deliberately point out whether the things you're saying are your personal views or proven best practices.

We work in such an opinion-heavy industry. So sometimes it can feel impossible to differentiate feelings from facts - especially if you're new to programming. One tangible way to help with this is to provide resources describing why something is best practice.

🖥 Dedicate time early on for Git commands

On the very first day (or maybe second), walk through the Git commands that you use most frequently on the job with your junior. Nothing is too basic - particularly because many bootcamps or university programs don't teach Git. For example, the bootcamp I went to used Git for version control, but all of our tasks were done solo. So more collaborative Git workflows (like branching or pull requests) were new to me when I started my first developer job.

Ideally, you'd also take the time to explain what each command is actually doing. It took me nine months and one colleague sitting down with a pen and paper for me to finally figure out how a rebase works. Speaking of, teach them how to rebase properly!

📝 Have something for them to work on

Give your junior something to work on that is low pressure, but still impactful. If you're stuck on what kind of work falls into this category, think either nice-to-haves (style improvements, microinteractions, bugs that aren't critical, etc.) or general improvements (refactoring, accessibility, performance, etc).

Be sure to have a dedicated backlog of tasks ready for them to choose from. For most junior developers, this will be their very first software job. So it's unrealistic to expect them to "take initiative" and decide what they should work on without a curated task list.

✅ Give constructive code reviews

Code reviews are a major. At best, code reviews are constructive and serve as continuous learning opportunities. At worst, they can destroy trust and safety within a team.

As the reviewer, you should be pointing out things that are done well and if you have critiques, explaining why something is problematic rather than only saying ‘fix this’ or offering the solution.

👩‍💻 Practice pair programming

Set regular, dedicated times for pairing (like literally put it in the calendar). I'd recommend at least twice per week. You can have a set of tasks that you work on together or switch between individual tasks.

When pairing, make sure you're alternating between who's driving and who's navigating. Depending on your junior and their learning style, this could also be them observing you. Personally, I learn so much from watching and asking questions.

🧠 Pair on things that aren't code

It feels weird at first, but I promise that it’s helpful. Show them your workflow, how you prioritize tasks or approach learning something new. One of the best non-coding pairing sessions I've had was a colleague walking me through how he conducts a code review.

How you test your own code? Dive into a new project? Manage your time? Plan a company-wide presentation? All of this is valuable.

🙋‍♂️ Always be available for questions

Make your junior a top priority. When they have questions, stop what you're doing and help them. If you don't know the answer, help them find it - whether that's searching through StackOverflow or introducing them to someone who knows that domain better.

Jess Mitchell also made an especially excellent point about tone:

💞 Get them a buddy or mentor

This should be someone (not their direct manager) that will guide your junior through their onboarding. Your junior should also feel comfortable talking openly with this person and discussing any problems they might be having.

Ideally, your junior and their buddy will meet at least once per week during the first 6 months.

📚 Learn their learning style

Get familiar with your junior’s learning style and try to cater the resources and materials you send them to that style. So if they like books, try to recommend books or written articles instead of videos courses. It's a small gesture, but it'll help them succeed and shows you care.

⏰ Respect their time

Set a good example by not sending emails at wild hours or pressing for tasks. Let them know what's expected from them in terms of working hours. An example of why this is important: In my first tech job, the lunch break didn't count as working time... but no one told me that even if I took a shorter lunch, I still couldn't leave earlier. Later, the fact that I left 30 minutes early every day was brought up as an argument not to keep me 🙄

On a related note, try to encourage wellness by recommending self-care tactics and being open about mental/physical health (if you feel comfortable and safe doing so).

📋 Provide regular feedback

Give regular feedback and updates about how they’re doing. If you're working in a country with a probation time, try to give weekly feedback during that time.

Your junior will likely assume they are doing worse than they really are. But if there is something that needs to be fixed, be sure to tell them enough in advance that there's time to make a change.

🌱 Show humility yourself

Admit when you don’t know things and search for answers together. Offer regular opportunities for them to give you feedback and maybe even in a variety of ways (sometimes face-to-face, sometimes written, etc).

Ultimately, their success is your success, so it's important to know how you're doing throughout this process as well.


Did you find this helpful or useful? If yes, please consider buying me a coffee so I can continue to write posts like this 🙌

Posted on by:

carolstran profile

Carolyn Stransky

@carolstran

Software developer and sometimes still a journalist (she/her)

Discussion

markdown guide
 

While this is true of any dev, it's double true of junior devs:

The first weeks, they are going to be anxious to do something - anything - of value. If your code base is particularly complex, this will be difficult. But one thing a team can always use is perspective, and that is easiest to get from a new person.

For years, my go-to task for week one was for the new person to improve the Wiki. Find all of the bugs in our setup docs. Define all of the jargon words we forgot to define. That's all defensibly useful for hiring the next person, which is great, but other than a sense of accomplishment, it doesn't help this person all that much.

In communication or teaching, you want the listener to repeat back what you've just said in order to determine if they actually heard you. Have them work on the high-level overview of the system. Everything they get right, is explained without a bunch of circular reasoning. Everything they get wrong is a teachable moment. And every good teacher knows that they learn as much in the teaching as the student does in the learning. Often this is a good way to find missed features, or solutions to problems you thought unfixable.

 

But one thing a team can always use is perspective, and that is easiest to get from a new person.

I'd always suspected this, but this is the first time I've read it written by someone else.

 

Developer experience is no different than user experience in this regard. You don't know how many assumptions you assume you're not making, and only outside feedback and the more than occasional ELI5 request (see? I just used an acronym assuming everyone on Dev would know it... That's "Explain Like I'm 5" for those who didn't) can help to undo those assumptions.

 

Good tips! I wish more companies / teams would give pair programming a serious try. I've had great experiences since I did an internship back in 2006 and the onboarding was basically an introduction to pair programming, a couple of demos showing us how to do TDD, then "okay, partner up with someone and take a task card off the board over there".

Another thing I find helpful is to make sure there are a couple of really well-defined, small-scoped tasks available for them. Or sit down with them and extract several small-scoped tasks from something in the backlog, then pair up. I really don't like welcoming newbies with "here is the link to ALL OF OUR DOCS" or "here is the our Github org -- feel free to browse through all the source code we've ever written". It's much better if they can sit down and discover the relevant parts of our systems (not the dead code from three years ago that's still referenced in our docs), as needed, to do something concrete and easy to measure... so they know what they're doing makes sense.

 

be aware that folks are different. Not everybody is fan of pair programming. Fore some, following some online courses is a better match. Or even reading a book. Best would be your organisation provides some self-made tutorials, programming guidelines with a lot of examples, template code and snippets to pick from.
My observation: pair programming often leads to silo-thinking and micro-standards but seldom to the quality standards you might need for larger projects. PP heavily depends on the people. Unfortunately the best folks for PP are the most absorbed ones. Knowledge extraction and distribution processes are - at larger organisations and over a longer time period - more important than PP - my very personal observation.

 

Not everybody is fan of pair programming.

Agreed, but I do think it's a skill that everyone should learn.

I've never worked in a larger org so can't comment on your other points, but I'm tempted to believe that if pair programming leads to "silo-thinking and micro-standards" then you have a much bigger problem that isn't pair programming's fault 🤷‍♀️

Dear Carolyn,
When you "think" about stuff, that you have never seen, does not make you a professional :-)
It's just wild guessing and is one of the problems that is holding startups back from scaling and growing fast.

All this has nothing to do with IT but with human nature. I am not saying that pair programming is bad. But it is not enough. When you just have pair programming without a programme around it that makes sure, the the right and always different pairs are built, different characters are addressed their way to learn best, trainers are trained and rewarded, folks are fired who never learn, remain dependent on others, never pay back or contribute etc. - you know - all the general HR stuff - you will get efficiency and motivational problems only Microsofts and Googles can afford - but will take lifes when you are an airplane or car manufacturer, responsible for a nuclear power plant etc. ;-)

Seems like you speak from bitter experience, here.

When you just have pair programming without a programme around it that makes sure, the the right and always different pairs are built, different characters are addressed their way to learn best, trainers are trained and rewarded, folks are fired who never learn, remain dependent on others, never pay back or contribute etc. - you know - all the general HR stuff - you will get efficiency and motivational problems only Microsofts and Googles can afford - but will take lifes when you are an airplane or car manufacturer, responsible for a nuclear power plant etc.

And there's more to the merits of coders learning to pair program than wild guesses. I don't think anybody's saying it's something everyone should do, but it there may be some benefit to learn it in case it's useful in the future, with the right company, colleagues, or program. Tools in the toolbox, and all that.

I have always hated pair programming, as a junior and as a senior dev. It has never not made me feel uncomfortable personally, on either side of it. It's not quite as bad virtually, but still far from great.

 

I couldn't agree more! I wish I had such kind of onboarding process at the beginning of my programming journey back then. Great post, the topic is worth attention!

 

Great post with valuable concepts. Please also consider to make it clear to management, that this process is crucial for mid to long term success. It's an Investment. By the way - I created a pull request and had the junior review it, which made him comfortable with the process and also indirectly pushed him to correct MY mistakes.

 

make it clear to management, that this process is crucial for mid to long term success

💯💯💯

 

Yeah this is worth tying to risk reduction and revenue.

 
  • Be nice and kind and let them feel and see, that you care about them (as dev AND human)!
  • Show them that they can also tell you "negative" things, e.g. challenges and hurdles, both emotionally and technically
  • Invite them to an open-minded discussion culture instead of a "I don't care about your opinion"-culture
  • Invite them to take responsibility, e.g. by asking questions like "How would YOU solve this problem?"
 

Hello Carolyn!
My name is Tatiana, I’m a Brand Manager representing Plarium-South, an international game development company specializing in mobile and browser games (company.plarium.com).

We would like to translate your article and post it in our blog on Habr.com.

We appreciate your consideration of our permission request. Link to the specific original content will surely be provided in the translated version. Looking forward to hearing from you soon!

Regards, Tatiana

 

Hi Tatiana! I've received your message (and DM, and email). I'm thinking about it and I'll let you know soon.

 
 

Hi Carolyn! Are you ready to give an answer?

Hi yes sorry for the delay, feel free to translate it 😊

Thank you for offering and thinking of this!

 

Anyone choosing to hire junior devs should be prepared to shoulder some of the burden of teaching them. If you can't afford to spend time doing that, you should only hire senior devs (which also has an associated and increased cost). It's unreasonable to hire a junior person and expect them to only have other juniors to mentor them. A junior dev is an investment - they won't pay off right away and require time in place of the higher salary you'd pay someone who could hit the ground running.

Your response sounds like you've had a lot of junior devs foisted on you, which is not the junior's fault. Presumably, a company knows what skill level they are hiring someone at and it doesn't make sense to be angry that they take more time to onboard.

 

Great advice! They are spot-on. All of this creates a warm and safe environment for junior developers. That's essential since they will feel like they can ask questions and actually do things without the fear of being judged or anything.

 

Good tips! I've been implementing almost all of these at MousePaw Media for years, and can vouch for them.

The only one I can't follow is having a "buddy who isn't a direct supervisor". Our particular situation makes that impossible: I have to be both the internship supervisor and primary mentor at this point, since we're so small. But, because of how leadership and decision-making is structured within the development team, that works out pretty well regardless. I also strongly encourage people to work together without me, through pair programming, code review, chat, and other collaborative opportunities, so developers wind up supporting each other anyway!

 

sometimes it is the same body but different ROLES!
Knowing which ROLE one is playing for a given moment and acting accordingly is something that is even more important the smaller you team!

 

That's definitely one way to look at it. I will occasionally switch into "Supervisor Mode", but I have to say, it's not often. My management style is already more "guide" than "herd", my philosophy being that it's easier for you to dig yourself out a hole you dug, than to dig yourself out of a hole I dug for you. I'll let individuals decide how they want to approach a particular task they've been assigned, and I'll seldom interject my two-cents until they ask for it (the one exception being if they are about to walk right into a proverbial landmine.)

 

Great advice!

Many developers often forget how little they knew when they begin. Nothing is too basic for a beginner about Git, that's true, but for many other things as well.

I saw many experienced developers explaining clean code, OOP, and TDD in half an hour. Going little step by little step is, I think, a better idea.

 

Great topic and valuable content. My two cents: I don’t think refactoring is a proper task for a junior, especially a newcomer.

 

Fair point! Refactoring helped me learn a lot, but definitely not at the very beginning of my first dev job. Plus it needs to be presented in a helpful way (what's the goal, why is the current approach not ideal, etc).

 

Thank you very much for this write-up. Most of the points are things we are practicing in our company already, some of them by explicit decision, some more established by common sense. Seeing this written down helps reflecting on the things we do and why we do them.

There is one thing I'd like to warn about though and that are a bit of a conflict in your points:

Always be available for questions <-> Respect their time

I'm sure it was not your intention to put it that way, but saying that you always have to be available and stop whatever you are doing when the junior has a question puts a lot of mental stress on the mentor. Interrupting tasks all the time is very exhausting and should be avoided.

So, being respectful with each others time goes both ways in my opinion. Of course, a mentor should dedicate a lot of time to the junior to be available to answer questions. I always like to split this between urgent matters and more general matters. I will interrupt my work for urgent matters when the junior approaches me with a question. But for things that are not urgent, I usually reserve a spot when we go through a number of questions that have arisen over the day or half a day.

This allows me to be fully dedicated to the questions and also fully dedicate myself to other work (often requests from other colleagues).

 

I do agree... except at the very beginning of the onboarding process. When the junior first arrives to the team, they should be the top priority (unless something is literally on fire). Then once they are more settled, I think working out a schedule like you mentioned sounds nice!

 

Great article. I wish we had a better word than "junior" for people. I'll never call anyone that.

I like the part about being honest about what we don't know. The illusion or perception that we know everything is harmful. I look for any opportunity to say I don't know something. Even the newest, least experienced developer will know things I don't.

Also distinguishing between opinions and best practices. Even best practices are usually subjective. It's okay for a team to decide to do something and expect new members to go along, but we should be prepared to explain anything and answer questions. The worst thing we can do is portray a practice as something decided by Smart People (You Are Not Included) Who Shall Not Be Questioned.

I especially dislike, "That's not how the team does it," as if the the person we're talking to isn't part of the team. Chances are that's not how we meant it. But we should at least ask ourselves, "How do I mean it?"

 

These are very handsome points!

As a self-taught (or however you call it) developer who was lucky enough to find a job without even having a solid base to start, I suffered a lot from these situations. Especially for Git commands and processes... I broke things until I got used to it. And I heard about 'rebase' only months later I started to work and it was not in my workspace but in a face-to-face interview with another company. Since then I have more often been using the command.

Mentor or buddy, pair programming, and constructive code reviews are all valuable points.

Thanks for sharing!

It's hard not to roll my eyes any harder. Carolyn's post is not making a list of demands, but rather talking about how to have the best experience onboarding a junior dev. I'm not asking for help becoming a junior engineer - I'm the one who onboards, trains, evaluates, and occasionally has to fire engineers that are not able to progress. I passed out of the junior stage a decade ago.

Anyone who expects a daycare will quickly wash out, whether or not someone takes these measures to onboard them well. Senior devs who are too arrogant to put in the time to onboard a junior dev because they think that they are all "millennials fresh out of their safe space" will certainly lose out on talent by relying out stereotypes. Newsflash, even the youngest millennials aren't just starting their first jobs these days, as they are in their mid-twenties. I think you need to upgrade your insults for the next generation.

 

Absolutely awesome advice. Thank you Carolyn!!

 
 

Hi,
This was a greate reading and surely will be helpful. I wanted to push further my curiosity to understand the scenario of hiring first junior developer under non-IT manager. What extra care to be taken in such case because non-IT manager is not going to teach junior developer any coding or best-practices?

Thanks
Jp

 

Curious, why would you hire a junior without an IT manager?

 

Actually my friend has a long career in sales and he is not from tech background. He has started his own business and looking to hire junior developer due to his budget limitations (and of course to keep another monopoly type of constraints).

and of course to keep another monopoly type of constraints

Could you translate that for me?

Also, the sales guy might not be able to find an IT Manager or a well seasoned dev, but he may well want to look through his network for someone to advise him on this stuff.

 

Wise words, from a wise ape.

Don't forget to give them the highest quality 32-bit Windows 7 laptop available!

And, second most importantly, make sure that they don't have any access to the VPN.

 

Great topic. Pair programming is an excellent way to learn but senior devs don’t seem to see the value in it or ceos are acting like overseers trying to get every minute of focused work out of you. Communication is also important sometimes people tell you that you’re messing up without telling you what you’re messing up on.

 

Great article!
I have a thought...

Business domain: I feel it is important that they are provided with some insight into the business domain as it helps them to reason about things and decisions in a more contextual way.
Also fresh new eyes and talent can also identify some obvious solutions, that us deep in the rough experts might miss.

 

Oh that's a really good one! Knowing about the business domain and what other departments do improved my experience at my first dev job.

 

I'm being buddy for an SDE who's onboarding our team and it's being a rich experience. I try to keep casual conversations and regular follow up sessions so the new teammate can feel welcomed and confident about making questions.

 

tips are really good, problem how to implement the tips lol

 

May I ask to what putative person or entity you're referring by the word "you" in here?

This is a good example of someone who should not be a developer on any sort of team - or perhaps a developer at all. Why do I say this? This is Brilliant Jerk mentality. What does your company do when senior devs move on? How do you even become a senior dev at a company if nobody showed you the ropes or took the time to mentor you? Have all the sane people left that toxic work environment and you are senior by default?

Did we read the same listicle?
This all seems kind of ballistical.

 

You forgot the most important part. Make sure to call them "junior!" They love that.

"Must be a case of the Mondays, Junior, eh?"

Office Space, it's a pretty good documentary about IT work, you might have heard of it

 

May I ask to what putative person or entity you're referring by the word "you" in here?

This is a good example of someone who should not be a developer on any sort of team - or perhaps a developer at all. Why do I say this? This is Brilliant Jerk mentality. What does your company do when senior devs move on? How do you even become a senior dev at a company if nobody showed you the ropes or took the time to mentor you? Have all the sane people left that toxic work environment and you are senior by default?

Did we read the same listicle?
This all seems kind of ballistical.

If memory serves me right, he was responding to a comment that no longer exists.
(Not sure what is up with (auto?) promoting responses to comments to top comments in dev.to)

Well I'm going to look really confused in here, then.

 

I 100% agree with this article!
I hope that the industry awareness for the points you mentioned increases!

 

Excellent post. Your "ultimate" is the most important. Set peeps up for success, and it will pay you back.

 

What about companies that expect for you to be 10x developer since day 1?

Job title: junior web developer
Requirement: 5 years of experience in 3 year old framework.

 

The last point is absolutely the most important, I always make it very clear that not-knowing is a big part of my life!