Tactical Challenges In Hiring Junior Engineers

All too often, I see comments or opinion pieces that read like platitudes about how every team should be hiring junior engineers. Let me start by saying that I’m all for hiring more junior engineers. There seems to be a perennial shortage of competent “senior” talent that seemingly every team is chasing, which often explains the “talent shortage” trope in tech.

Hiring and mentoring junior talent can be a huge competitive advantage. Junior engineers often bring new energy and enthusiasm to a team, are eager to learn and grow, and can be great ambassadors of the team.

But there are many tactical challenges involved in successfully onboarding and growing a junior engineer that are hardly ever discussed. In this post, I wish to explore some of these challenges.

Who even is a Junior Engineer?

If you, like me, have worked in San Francisco, especially at startups, then it’s not unusual to meet a 24 year old “senior” engineer with 2 years of industry experience. Many organizations lack meaningful career development plans or even career ladders. At a lot of companies, even if said career ladders exist, they’re steeped in politics. I’ve myself got offers to be a “senior engineer” when I didn’t even have 1 full year of industry experience, making me very sceptical of “titles” in general.

So it’s hard to accurately define who even is a “junior” engineer. But for the purpose of this post, let’s assume it’s someone who is “early career”. This includes folks who have never held a full-time engineering job before (fresh college grads, bootcamp grads and so forth), or folks who have fewer than 2-3 years of industry experience (though years of experience, like lines of code, isn’t a reliable yardstick).

Hiring a Junior Engineer is a 1–2 year Commitment

Hiring any engineer is something of a gamble. Engineers hired at a certain level might end up underperforming (despite acing the technical whiteboard interview), or might require more mentorship/guidance than initially anticipated by the manager.

However, hiring junior engineers is slightly different, in that it’s more a commitment than a pure gamble. I strongly believe that if a team isn’t willing to invest at least 1–2 years, they shouldn’t be hiring junior engineers.

A lot of teams — especially startups — clearly aren’t set up for this, for a number of reasons, not least:

• not having enough runway for the company to last 1–2 years
• not having enough bandwidth for mentorship
• not having enough senior engineers on the team who can be effective, empathetic mentors
• not having a clear product roadmap

If in doubt, I’d argue that one shouldn’t hire a junior engineer. Early-career scars can be very hurtful, and in the worst case can drive folks out of this industry.

You Need Experienced Managers

A bad manager has been a horrendous formative experience for many folks I know.

Inexperienced managers aren’t probably the best suited to hire and mentor junior engineers, since it’s unlikely they have the tools in their arsenal to effectively deal with scenarios where the junior engineer ends up requiring additional help or isn’t quite as productive as the manager had hoped they’d be when they’d made the hire. This involves everything from assigning projects, assigning mentors, addressing conflicts, intervening when the project isn’t on track or is delayed or doesn’t end up as expected, providing actionable feedback and more.

Inexperienced managers themselves are probably in need of mentorship/guidance from senior managers or leadership folks in learning how to best tackle scenarios where a junior hire (or any hire or team member, for that matter) isn’t performing at the level expected.

Remote Work Presents Unique Challenges

For the foreseeable future, most tech companies based in the Bay Area are entirely remote. Abruptly being thrust into a remote work environment has been a deeply disorienting experience for even many of the most senior engineers. But I fear the ones most impacted by this turn of events will be junior engineers.

Mentoring junior engineers remotely presents unique challenges. A lot of what I learned when I was an early career engineer myself was via osmosis — listening to conversations other senior engineers were having, even if I wasn’t a part of the conversation. This often sparked curiosity in me about how some system was set up or how some part of our stack worked, which led me to dig deeper into the code or design documents to gain more context. This learning helped me immensely. This is hard to replicate in a remote setting. I don’t overhear conversations anymore. I don’t have serendipitous conversations or meetings anymore. This means I’m only strictly privy to conversations that take place in Slack or in emails/design documents/pull requests. So the amount I learn simply by observing how my coworkers debug some problem or overhearing conversations they have discussing the pros and cons of an approach they’re pursuing has plummeted.

This will impact junior engineers the most. A lot of valuable skills now need to be consciously learned. This requires that managers or senior engineers on the team be cognizant of the need for junior team members to learn these skills and come up with tactical steps on how to achieve this goal.

Well-Defined Starter Projects or Bugs

Any new engineer on the team will take at least 4–6 weeks (in the best case scenario) to fully onboard onto the team and become self-sufficient and productive. When it comes to junior engineers, it often takes much longer.

This means that if the team has immediate deliverables to complete or if the team is on a deadline to launch a new product, then work in the “critical path” cannot be assigned to the junior engineer. This means the team needs to ensure there’s a sufficient number of “starter projects” over the course of 6–12 months — work that is interesting and important enough for the junior engineer to feel a sense of belonging that they’re a part of the team and doing important work, and yet not critical to the team’s immediate success. Teams that aren’t in this situation shouldn’t be hiring junior engineers.

Senior Engineers Will be Less Productive

On one of the teams I worked on during the course of my career, I had a colleague mention that hiring a junior engineer brings down the productivity of a senior team member by at least 50%, at least initially.

A good mentor will always be available to answer questions, always be patient in explaining how something works or providing context, unfailingly kind especially when providing critical feedback, always willing to help, always ready to teach the mentee the skills needed to meet the goals. In short, this is a huge time and emotional investment on the part of the mentor.

Your senior engineers will be less productive if they spend a considerable amount of their time pairing/teaching/mentoring junior engineers. This can be emotionally draining and can leave your senior engineer feeling exhausted.

If you have mission critical projects that your team needs to ship on a deadline, this can pose a huge problem. If your senior/tenured engineer is spending only about 50% of their time working towards their projects, the project is invariably going to take twice as much time to complete. This requires that in addition to having well-carved starter projects for junior engineers, your team also needs to account for the fact that your senior engineer is going to be only half as productive as they usually are.

Product Roadmap

Having well-defined projects which can be delineated into “critical” projects and “non-critical” projects often requires that the team have a strong product roadmap. A lot of startups, especially ones trying to find product-market fit, usually don’t have clearly defined goals or projects. This can compound problems for junior engineers, as many (but by no means all) simply aren’t well-trained to multitask on multiple goals or switch context effectively. This can lead to a very chequered experience where an engineer might end up working on a hodgepodge of different projects without a clear narrative or clear learning opportunities. This does little to help the junior engineer identify and grow skills if their focus is split or if they’re unable to focus on a problem for extended periods of time.

The Payoff Might Not Be Evident

Also the average tenure of a Silicon Valley engineer at many companies (especially startups) is 18–24 months. There are exceptions to this rule, but this is how it plays out at a staggeringly large number of companies. Engineers either leave for greener pastures or are let go (“fire fast” is a mantra many companies have internalized to the point where they default to firing).

This can mean that the investment a company decides to make in growing a junior engineer might never pay off, since the engineer might end up quitting in 2 years to work at another company where they hired at a higher level or are offered a different title. This might disincentivize many companies from investing in junior engineers (or engineers of any level, for that matter). If retention is something a company is struggling with, then before hiring junior engineers, I’d argue the company should first address the cause of poor employee retention.

Conclusion

Large companies are already well set up to do this effectively and successfully hire thousands of fresh grads and junior developers every year. But many teams are also simply not in the position to successfully hire, mentor and grow junior talent. Such teams should not hire junior engineers before they get their house in order. A bad formative experience can leave long lasting scars. A lot of bad practices and behaviors take years to unlearn.

The reason I wrote this post isn’t to discourage companies from hiring junior talent. Senior engineers don’t grow on trees. I’m all for throwing the gates wide open for more folks to enter tech and have long, fulfilling careers. For many folks — and especially folks from underrepresented groups in tech — a successful tech career can be a path towards building generational wealth. I only wish more conversations focused on the tactical challenges involved in pulling this off successfully.