Filling engineering roles is hard and takes a long time, and yet entry-level and early-career software developers also often have a very hard time finding their first role, many companies only looking to hire mid- and senior-level engineers.
I understand this hesitation. It takes a fair bit of time and commitment, and there is a period of time where they slow other teammates down more than they’re able to make up for with their contributions.
But this time period is so short, and can be made up for in spades if a team is intentional about supporting them well.
This is why I think my last point here may actually be the most important: “Junior engineers don’t stay junior engineers for long…”
The thoughts here are mostly my own, from being a junior engineer myself, from having conversations with so many other junior engineers over the years, both those whose first jobs have been great and those whose first jobs have left something (or a lot) to be desired. I can’t speak for everyone — these ideas might work for some people and not for others. The best thing you can do, no matter what, is ask the junior engineers how they want to be supported. Understand that they may not know the answer at first— that’s why I’m offering some starting points here. But once you’re rolling, check in with them periodically to ask what’s working and what’s not, and be open to their feedback.
Our industry has so much to gain from hiring and retaining new batches of junior engineers, including (especially!) those from non-traditional backgrounds.
Have other thoughts or ideas from your own experience? I’d love to hear them!
Have a single go-to person for questions
Giving new engineers one specific person who will be their go-to for questions can make the prospect of asking questions at all significantly less intimidating, especially if they’re told that that person is expecting it. Even though frequent interruptions can slow down your other engineers, if junior engineers are made to feel like they’re a burden for asking questions, they’re significantly less likely to ask questions, which will slow down their progress and be detrimental to everyone in the long-term.
This person doesn’t necessarily need to have all the answers, but they should be familiar enough with the codebase and team to be able to point the new team member to the correct person when they don’t have the answer.
Having a consistent person can also mean that there’s someone who understands the new dev’s learning style, and can adjust accordingly:
mj👩🏻💻✨@mjpasx
@a_domingus (currently a junior dev) From the start, one of the senior engineers figured out my learning style & adjusted how he explained concepts with me. During pair programing, they explain as they go & when we finish, they have me explain it back to make sure I understood correctly19:05 PM - 09 Dec 2019
0
2
Help them ask the right questions
One of the hardest things as a new dev is knowing what you don’t know. Sometimes all you know is “I’m stuck,” and you don’t know what you need to know to get un-stuck.
Asking them “what have you tried already?”, and “what happened when you tried that?” are good starting places.
Sometimes they don’t need help solving the problem (yet), all they need is help breaking the problem down into small enough, logical and manageable pieces to keep the ball rolling.
Rachel Leggett@rleggos@a_domingus Something that didn't work: In my second year, I was put on a big project in an unfamiliar stack as the only developer with no senior devs to answer tech Qs. I was so overwhelmed and scared that I didn't do anything for weeks. 1/201:55 AM - 09 Dec 2019
Frequent check-ins
New devs can get stuck, and not ask for help soon enough (we’ve all toiled for hours on a problem that someone else was able to solve for us in minutes at least once, right?). They can be unsure how to break problems down into small enough pieces (or not know how to adjust the original plan as they go and the problem shifts).
Daily check-ins should be formalized for at least the first few weeks, but ad-hoc ones can be valuable too, such as when they’ve reached a good break-point in the task they’re working on:
mj👩🏻💻✨@mjpasx@a_domingus something I do for myself is take notes in a journal and use it as a resource so that I don't constantly ask the same questions. also, when working on a new project, we usually agree on a check in point (ex: once you finish the ui, lets make a plan to approach the data binding)19:07 PM - 09 Dec 2019
Create opportunities for quick wins
This goes for any new team member, not just the junior ones, but: humans like to feel productive and like they’re contributing members of the teams they’re on. Creating opportunities for them to feel like this can be huge in building their confidence and feeling like they’re part of the team.
Not to mention that the more tasks they’re able to pick up, no matter how small, the better their understanding will be of how the different parts of the codebase work together, and how to test their changes locally.
Demonstrate failure
Everyone makes mistakes. Seasoned devs are used to this and often take it in stride, but it can be scary for newer devs. Being open about the mistakes you make, and the things you don’t know, and showing how you recover from them, can make acknowledging their own failures seem more approachable to new devs.
Respect their ideas
I hope this goes without saying, though I’ve talked to enough devs in their first jobs to know that it doesn’t always. Junior engineers, in addition to engineers of any level new to a team, have a way of questioning assumptions folks who have been around for longer take for granted.
They ask why things were implemented they way they were.
They mention that they don’t understand a piece of code.
While sometimes they’re missing context or knowledge and explaining the limitations that lead to a certain implementation or how a piece of code works is all they need, these questions can also often point to areas of code that could be implemented more cleanly. Take this into account, and be willing to make adjustments based on this — your codebase will thank you.
Emotional Support
Joining a new team is always hard — there’s a ramp-up period where you’re less efficient than everyone else on the team and feel lower-value. This is particularly true for early-career people who, in addition to being less familiar with your particular codebase and team processes, may be in their first engineering job, or even first job.
They may need to be reminded that it’s ok to have a lot of questions. Ok to complete tasks significantly slower than another team member might be able to. Ok to get a lot of feedback on pull requests.
Helping entry-level teammates build their confidence can be as important to their productivity and happiness as helping them build their technical skills.
Acknowledge their growth
Junior engineers don’t stay junior engineers for long. Six months or a year in, they won’t be recognizable as the same engineer you first hired. Recognizing this and making sure that they’re leveled and paid appropriately, as well as given projects that continue to be interesting and challenging them may require more frequent adjustments than for folks with more experience. But a willingness to consistently make these adjustments will help keep these folks on a career path with your team that means they can stay on your team for the long haul!
Oldest comments (0)