Onboarding a junior developer to your team? Here's 12 tips.
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, micro-interactions, 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 video 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.
Have thoughts or feelings about onboarding junior developers? Join the discussion on DEV.
Like my work?
Let me send updates to your inbox (and one day, a newsletter).
Unsubscribe anytime. No spam ๐ค