Hire 👏🏼 Junior 👏🏼 Engineers 👏🏼

At Code BEAM V America 2021, I had the pleasure of having a Fireside Chat with Ben Marx (co-author of the Adopting Elixir book) on the topic of Elixir Adoption. We defined several key areas where we thought that the Elixir Community could improve in order to make Elixir more welcoming to business environments, and get it out of the side-project designation. We also shared a few fun tips and tidbits that I had learned while co-hosting the fifth season of Elixir Wizards, where we spoke with community members and leaders about adopting Elixir.

In the closing of our Code BEAM session, I asked listeners to consider hiring more junior and mid-level engineers the next time they’re in a position to hire for Elixir roles. A key point in expanding the usage of any programming language is to have as many people as possible exposed to or writing in said language. If you are only ever hiring for senior engineers, you’re exposing this particular language to one small pool of people. Opening up that pool to junior and mid-level folks not only gives you more reach, but more opportunity to invite people into the Elixir community.

I found the conversations that arose in the aftermath to be fascinating. In the Elixir Community, many agreed we were seeing only senior roles being posted. We had a lot of support from friends of the podcast, like Sophie DeBenedetto (Senior Software Engineer at GitHub, co-author of Programming Phoenix LiveView):

And interesting insight from new friends as well, like Okoth Kongo, one of the co-organizers of ElixirConf Africa.

These conversations opened my eyes to a strong pattern we are seeing not only in the Elixir community, but in the tech space as a whole. Over the course of 2020 many businesses had to completely reevaluate their operations, including their hiring practices.

Companies did not feel confident hiring junior engineers, fearing a poor onboarding experience while remote. In early lockdown days, most paused hiring altogether, fearing the unknown. When they started hiring again, they paused hiring juniors until they are back in the office and can start onboarding in person again.

This made sense in theory, but after a year in quarantine many folks in the tech community don’t think things will truly go back to the way they were. Many companies, SmartLogic included, went remote-first. SmartLogic no longer has a physical office and is a fully distributed team across the United States. And a technical recruiter I spoke to about the market for hiring juniors even indicated that he expected that when the world opens up again, the new normal will not include the old office 9–5. He expressed that it is more likely that people will go into the office only when they have to, and more businesses will embrace a remote-first lifestyle like SmartLogic did.

But what do these changes mean for the future of engineering, and why are companies only hiring seniors? I wanted to find out, so I went and consolidated the top reasons I had heard people cite when they talk about hiring.

“We Only Want Seniors”

One of the most popular explanations I’ve seen in the last year when it comes to why companies are only hiring seniors right now is: “We’re a small startup, and we need to move quickly to get this MVP out the door.” This struck me as odd, even if it makes sense at first. You need to build some software quickly, so you need experienced folks at the wheel.

But then I thought back to my experiences on multiple engineering teams and I realized that in all cases of successful, fast-paced progress on any application, there was a mixture of experience levels on the team. A senior engineer or two spearheaded the architecture of the code and lead PR reviews, while under their guidance, mid-level engineers and juniors picked up the leg work.

Having a lot of seniors on a project does not mean that your product will be finished quicker — it might even slow you down because the strong opinions senior engineers have formed over their career can cause decision paralysis.

Having a lot of seniors on a project does not mean that your product will get out of the door quicker.

As I was thinking about this topic, I reached back out to Alexandra Chakeres, a Software Engineer at Blinker. She was a previous guest on the Elixir Wizards podcast, where she shared her thoughts on Diversity & Inclusion within the Elixir Community.

Alexandra noted that the gap between mids and seniors wasn’t a terribly far leap. “I don’t see that much of a day-to-day performance improvement from mid-level to senior. I think seniors provide additional skills when you need to design complex new systems, but most days you’re just building on existing systems,” she said, supporting the idea that seniors are not the only ones capable of doing quick work. She also had observed the trend of companies hiring fewer juniors, and noted that, “Your team does need a few people who can make architectural decisions, but I don’t think that means half your team needs to be senior level.” This isn’t necessarily addressing the question of “why not juniors” but does touch on the question of “why only seniors”.

“Your team does need a few people who can make architectural decisions, but I don’t think that means half your team needs to be senior level.”
— Alexandra Chakeres

Alexandra’s insight was a much more eloquent way of saying what I had been calling “too many cooks in the kitchen.” Ben Marx, during one of our prep sessions for Code Beam, made another argument against having an all-senior team for this kind of MVP work: if your main goal is to build as quickly as possible, you are most likely going to rewrite your MVP app anyways. Seniors can create plenty of tech debt themselves, which is something most companies know but forget when hiring. Why blow your budget on all senior engineers when a mixed-level team can execute just as quickly?

“Juniors are College Grads with No Experience”

I also would be remiss if I didn’t address the fact that the majority of folks in the tech community think of junior engineers as mostly fresh-out-of-college graduates with little to no real world experience.

This is often not the case.

There are plenty of bootcamp graduates, self-taught folks, and junior engineers who have been in the industry for a year or two but don’t quite feel ready to call themselves mid-level. The fear of onboarding a junior could be assuaged just by looking more into these micro-levels of skill sets.

Moreover, the idea that engineers are born and bred on college campuses is limiting. A non-traditional background has proven to be invaluable to every engineering team I have ever been on; I have worked with people who came from accounting, political science, people who studied history and theatre, and everyone in between. Everyone has had something unique to lend to the team. At SmartLogic, we have understood the value of non-traditional paths and it has served us well in the past. One of our developers, Melvin Cedeno, was recently included in Technical.ly’s How I Got Here series, discussing his journey as a technologist via the Turing School of Software And Design in Denver, Colorado.

2020 was a year a tumultuous year for all of us, but one good thing that we saw over the last year was the strong push towards more diversity and inclusion in the technology community. As we know, diversity and inclusion means more than race and gender identity — it includes individual teammate backgrounds. Candidates can come from all walks of life: someone might have changed careers in their mid-40s, or never finished college, or decided to go to a bootcamp immediately after high school. If you only hired out of the Ivy Leagues, no matter the color of the hire’s skin or the pronouns they use, the diversity of thought can be pretty distinctly lacking.

Diversity and inclusion means more than race and gender identity — it includes individual teammate backgrounds.

Most senior engineers have been in the industry seven to 10 years, and they tend to belong to the same demographic. If you’re only aiming to hire seniors yet also focusing on diversity in your hiring, you’re going to have a hard time meeting both of those goals; you are setting yourself up to fail.

“Small Companies can’t invest in Learning & Development”

Companies have recently been more worried than usual that they can’t support their juniors. As aforementioned, they don’t feel like they can remotely onboard and mentor new teammates in the capacity that they could in a physical office.

Some in the tech community have also commented that they believe that small companies are not able to invest in their employees. But most candidates (not only juniors) might be hesitant to work at a company that does not have a career trajectory of growth plan for their employees. Personally, when I see a company does not accommodate for or appreciate learning on the job, to me that is a red flag. You don’t magically stop learning when you become a senior engineer, so why would you want to invest your time in a company that didn’t have any interest in investing time in you?

Ben Marx, during our Adopting Elixir chat, agreed that growth is important and it is essential that a company give you some professional development time. But this does not mean that a company has to give their juniors two weeks at a time to drop all production development work to work on themselves — which is what a lot of companies think they have to do if they hire someone more junior.

Fortunately, there are simple ways to integrate learning and growth into daily or weekly tasks. Here are a few tips for running a productive, mixed-level team.

Tips for operating with mixed-teams

Pair programming is one key way through which we have seen folks get up to speed in Elixir. At the moment there are not many resources for learning Elixir from the ground up, which means that many folks learn on the job while pairing with their teammates on tasks.

Pairing is a powerful tool. At SmartLogic, we have weekly pairing rotations set between engineers and their managers or a relevant senior engineer on the project at hand. During pair programming sessions, it’s usually best to let the person who is working out an issue drive on the keyboard as well as explain any challenges they’re experiencing. Allocated pair programming time gives them the chance to try out the task at hand on their own, run into some errors, attempt to troubleshoot on their own, and then stash their questions for when their 🍐 session is coming up.

Sub-tasks are another productive way of divvying up tasks on a Kanban board for juniors and mids to have clear direction on projects that are typically considered “work for seniors to move fast” on. If a senior engineer can define sub-tasks with well-written acceptance criteria and proper steps for reproduction, theoretically someone with any level of experience would be able to pick up that task and execute it — this is typically considered best practice anyway). If a stakeholder told me they don’t have time to define well-written cards or acceptance criteria up front, I would plainly ask them if they wanted a quality product built, or something that would fall apart within months. Proper planning applies to all teams, not just a team of junior engineers.

Hire. More. Juniors.

The reticence to hire juniors is not only a pattern in the Elixir community, but in the tech community as a whole. We can acknowledge that at the end of the day, hiring a junior engineer is an investment. But realistically, all hires are an investment, which fortunately tend to be worth it in the long run.

According to Bruce Tate, founder of Groxio and author of Seven Languages in Seven Weeks (and another great friend of the podcast!), not hiring junior engineers is a swift way to have a language fizzle out.

If you liked this, please consider checking out the original talk presented at Code Beam V America on Adopting Elixir that was the origin story for this thought piece. Also, much of Season 5 of the Elixir Wizards podcast covered similar adoption tips and tricks.

Header photo by Christina @ wocintechchat.com on Unsplash