Hiring ONLY seniors is the worst policy in the software industry
Hiring ONLY seniors is the worst policy in the software industry
Why you should hire a junior for your next open position
Every company has a different excuse:
In small startups - “we are a very small team and we don’t have time to mentor juniors, we need engineers who will be very productive from day 1”
In medium-sized companies - “we are going to grow very fast, we need engineers who can handle scale and faced such challenges before”
In big companies - “our infrastructure is super complex, it’ll take juniors too long to ramp up”.
That’s bullshit.
I’m not talking about age here. There are 25-year-old seniors, and 40-year-old juniors who switched careers.
Software Development is not rocket science
Some developers became seniors in < 3 years, some of them even without a degree. If you don’t believe me, go read the stories of
, and .I’m not saying that after 3 years they will know everything - but they will be very productive, and be able to solve MOST problems in the right way.
Like with everything in life, there are diminishing returns. You will get better with time, but the pace will become slower. You can tell the difference between a developer with 1 year of experience and one with 5, but between those with 10 vs 15? Probably not.
There ARE cases when you need a high level of expertise, we’ll get to it in a moment.
It’s not that hard to onboard a newly graduated student to an existing codebase, and mentor them to be productive in a couple of weeks.
Inexperienced developers can achieve great things:
Evan Spiegel and Bobby Murphy co-founded Snapchat in 2011 when they were 21 and 23-year-old students.
Zuckerberg was 20 when he started Facebook.
Drew Houston was a 24-year-old student when he founded DropBox.
Larry Page and Sergey Brin developed the initial version of Google at 24, also as students.
Bill Gates started Microsoft at 20 (and Jobs was just a year older when he started Apple).
If students can create hugely successful companies, I’m sure they can handle creating a new screen or a microservice… Yeah, I know most of them were software prodigies, who started coding in middle school.
But that’s exactly the point - ambition, character and brains have little to do with experience.
Why you should hire a junior for the next open position
You are a team leader, and you need to hire another developer for your team.
I’ve been in your shoes. In the last 2 years, I’ve hired 5 developers - 2 seniors and 3 juniors. All of the ‘juniors’ are still on my team, and they are definitely not juniors anymore…
5 reasons why hiring a great junior is the right bet for you:
You have a bigger candidate pool, and you can get the absolute top developers. When you look for a full-stack developer with 5+ years in Python and 3+ years in React, you’ll have fewer options and might eventually compromise.
Juniors bring fresh energy to the team - they want to learn, and they have a drive to prove themselves and succeed. Their motivation can be contagious!
The seniors in your team will enjoy working with smart and motivated developers. It’ll give them opportunities to mentor and teach, which they might miss if there are only seniors on the team.Juniors are not restricted by what they know - they’ll not try to reuse the same technologies from previous companies, or recreate those ‘amazing’ design patterns that were useful only in a specific context.
Juniors are more open to working with new technologies, and less picky about the tasks they need to perform. It doesn’t mean you should have them fix annoying bugs all day, but it does give you more flexibility in the team.
Great juniors learn fast and search for feedback, so it’s easier to manage them. They want to improve and know what you think about their work.
And the biggest reason:
Juniors have internships and student positions
The 3 juniors I hired for my team, all started in student/intern positions. It means that I could judge their skill before offering a full-time role.
This is a privilege you never have with seniors - and often both sides suffer because of it. The developers will stay longer in mediocre companies so it’ll look better in the CV, and managers will settle for mediocre performers because they are afraid to fire people.
The ideal mix
Sometimes you need to hire a senior with very specific knowledge, especially in bigger organizations. If you want to make an IOS version of your app, I wouldn’t hire someone who never worked with Swift… Or if your performance is getting worse as you scale up and you want someone to handle that, an experienced engineer is a better choice.
But for most teams working on a SaaS product, the ratio of juniors/seniors can be quite high. While juniors need someone to learn from, great ones don’t need a lot of 1:1 time and attention.
Here is a great analogy I like:
Think of your team as a river instead of a lake. A lake stagnates. There’s no energy or impetus to change. The same is true of groups that stagnate. They cultivate mediocrity and complacency; they abhor risk. A river is always running and changing with lots of great energy. You want a river.
A river depends on the flow of water, and your team depends on the flow of people and information. You can think of the people divided into three groups: new blood, new leaders, and elders ready for a new challenge. Here’s how those groups should balance and flow:
The largest group should be the new blood.
For flow, you want a steady stream of new blood becoming your new leaders, and new leaders becoming elders.
The key to flow is new blood coming in and elders moving out. For this to work, you WANT your elders to transfer before they clog the stream and disrupt the flow of opportunities for others.
If you don’t hire juniors at all, your team stagnates.
For around a year, I had 2 seniors and 3 juniors on my team. 6 months ago, together with my best senior, we decided it was time for her to move on to another team, where she could learn more (I lead a full-stack team, and she wanted to get deeper into frontend).
We survived, and are still productive.
Junior does NOT mean exploitable
The whole point of hiring juniors is not to have ‘rotating cheap labor’, it’s to build a productive and loyal team. That can only be achieved if you pay them what they deserve.
Paying juniors less (even if they are super talented) makes sense - you are investing a lot of time and energy into training them, and it’ll take a while before they are productive.
But assuming you hire great juniors - it won’t take more than a year. After that, you should pay them based on their skills, not years of experience. Otherwise, they’ll just get mid/senior roles at other places, and rightly so.
Read this before you hire:
Everything we’ve learned about hiring for startups in
. I especially loved the tips about making your job ads weirdly transparent (check out that salary calculator!), and “a soft yes being a no”.- . Maybe you don’t need to increase your team’s size after all :)
Should you use your gut in hiring in
The hardest challenge I have had with hiring junior engineers is separating the quality ones from the average. For every Gates or Zuckerberg in their dorm room, there are thousands of average (or worse) who just can’t make the jump to the next level.
I think if you are willing to hire juniors you need to be willing to move on from those that don’t show growth pretty quickly. If they aren’t making great strides in 1-2 years you need to do what’s best for the team and let them go and try again with a fresh crop of junior talent.
It's not as simple as it sounds though.
I have worked with juniors before, and it really depends on the energy and attitude the junior.
One can argue that it's important for every member of the team, and I agree. But, if you settle on the attitude, you'd better get a senior.
Plus, as David posted, it can be pretty hard to find those good juniors who are there to grow and study and not just to get past the "junior" phase so they can find jobs easier.
Adam Grant said in his book, Hidden Potential:
"The best team members are not the biggest rainmakers but the most pro-social"
All in all, very good article and an important topic.
Thanks Anton.