Hiring juniors has always been a subject that's close to my heart. If I had an avatar, he would be wearing a backpack. In that backpack would be a soapbox on the benefits of hiring juniors that I'd carry with me, ready to stand on at a moment's notice.
I think companies are missing out on absolute gold mines of programmers and talent for fear of their team velocity or bottom line.
In this article, I'm going to outline my personal thoughts on why hiring early-career devs could be one of the smartest moves a company could make.
And before you start angry typing in the comments, consider all of this, not with a "protect the company and its assets" mindset, but rather, an altruistic pay-it-forward way of thinking.
We are not here to push the cogs of the digital capitalist machine forward. We are here because we enjoy what we do, and we should make it a point to lift others up in their journey to do the same.
The Negatives
We'll get the downside stuff out of the way first. You could potentially list a lot of things that would be negatives towards hiring junior developers.
But, after meditating on this and discussing it with others, I've noticed that it really only boils down to THREE reasons.
- Team/Product velocity
- Increased potential for breaking production
- Liable to leave after experience gained
At a glance, these are three strong reasons to not hire juniors. But are they, though?
Team/Product Velocity
One of the biggest arguments is that a junior will take more time to onboard and get familiar with the codebase. That may be true, but there is an onboarding cost for any developer brought on to a new team, and the difference between onboarding a senior and junior will likely be a much smaller percentage than you think.
Is 25% longer really that much of a difference in the grand scheme of things? Considering that you're offering your junior a potentially life-changing position? And 25% is being fairly generous.
Another argument is that they'll require more resources from the rest of the team with teaching, training, troubleshooting, and all of the dev stuff in between. Again, that's probably true, but consider the knowledge gained from both parties during any of those pairing sessions.
It's a win/win, because even if the senior developer knows exactly what's going on in their head, having to articulate it in a way that can be understood by someone else requires a deeper focus- and in many cases may even reveal something they themselves did not know on the subject.
Increase potential for breaking production
There's not much to say here. Yes, it's a possibility- for everyone.
Unit tests. CI/CD pipelines. Regression testing. Manual QA. Git history.
These are all things that negate, prevent and restore any breaks in production that most companies already have in place. The breaks are inevitable. Don't deny someone the opportunity to learn, grow, and contribute when the reason for the denial applies to everyone.
Liable to leave after experience gained
What company doesn't already expect this? A lot of companies already keep a steady flow of applications coming in because they expect literally this.
If you believe in your hires, be aggressive and pro-active at keeping their pay competitive and having consistent and open conversations on their growth- both from a performance and financial perspective. This one isn't even specific to juniors.
The Positives
I have a rather unorthodox view on hiring juniors that shape what my positives are. Here's a quick list them (from a company perspective):
- Likely no bad-habits
- Mold them into ideal developer for your team
- Great checks for clear vs clever code
- Incredibly ambitious
- Thankful for the opportunity. Likely to become loyal employees.
- Lower salary expectations
Hot take
Hire closer to the door. What do I mean by that? Hire people that have maybe explored a little react or vue, or insert framework here- but haven't really delved deep into any of them.
Find people who have some- and this is specific to front-end because that's the realm I come from- HTML, CSS, and Javascript knowledge, with maybe some cursory knowledge of the framework you'll be hiring them for, and give them a chance.
Why? For two reasons, mainly- and we'll get into specifics.
- Less experience = less pay * more on this in a just bit
- You could be changing their lives
With that said, let's get into specifics for the larger positives list and work our way down.
No Bad Habits
When you're hiring junior- and even more so if you're hiring closer to the door- they likely haven't built any bad habits that you or your team will have to train out of them.
If they do have any, it's very likely that they don't have a strong enough opinion to push back and insist on continuing that way.
I know bad hires exist and happen, but I've heard stories of senior devs leaving in as little as two weeks because they refused to follow their new job's style guide or workflow.
Mold Them into the Ideal Developer for Your Team
On the same note as the last point, because they have less experience and opinions- you can take that gap of knowledge and fill it with exactly what you need for them to be the ideal candidate for your team.
Your style guide, code formatting, tooling, etc... could be their default baseline. And that compounds to when they do have more experience and another developer is brought onto the team, guess who knows the tooling and style guide back to front and can guide new hires? Your recent (probably no-longer-junior) developer.
Great Checks for Clear vs Clever
What's one of the best ways to see if a function is complex for the sake of the flex? Put it in front of a junior developer and see if they can read what it's doing or find a less complicated way to achieve the same goal.
A simple "why don't we do it this way instead?" can reduce complexity and drastically improve maintainability and readability. Their suggestion doesn't always work. Sometimes the complexity is called for- but I've personally heard senior devs say "I've done it this (complicated) way for so long that I forgot you could even do it that other way."
Simpler code is easier to read, maintain, and handoff- why not add a solid check for that?
Incredibly Ambitious
This is an opinion based section
I have yet to meet a junior developer who wasn't willing to do (almost) anything to get that first or next job. "Oh, you're hiring for framework x? I don't know it- but give me a week and then we'll talk."
They're spending their nights and weekends grinding on Youtube, FreeCodeCamp, Egghead, Udemy, etc.. to give themselves and their families a new opportunity and possibly a new lease on life.
Imagine what they could do to your codebase with that drive and ambition. Imagine the new perspectives that would be brought to the table.
Thankful for the opportunity. Likely to Become Loyal Employees.
This goes hand-in-hand with the last section.
These juniors- at least the ones that I know- have been working tirelessly, for months and/or years to find that person that will take a chance on them and give them that life-changing break.
They will be so thankful for that opportunity- provided your culture doesn't suck, if it does, fix it- that they won't even consider looking at a job board or for other opportunities for a while.
Lower Salary Expectations
This is where it feels a little weird to talk about, but hear me out.
The closer to the door you hire, the lower the salary expectations will be. Closer to the door as in "just in the door of learning to code".
I'm not saying pay them unfairly. I'm saying pay them commensurate to their abilities. And there is a trade off here, but I feel the pro's listed above make the trade fair and beneficial for both.
So, your senior dev is hitting you for $120k+/yr. They have some of the same potential issues as juniors. Onboarding time, increased chance of breaking production, etc.. but they could have bad habits they're not willing to part ways with.
However, this junior is over here willing to take $60k/yr. They have enough understanding that will provide some forward momentum. No bad habits.
They're an unshaped blob of developer clay ready to take whatever shape you need them to.
That $60k/yr they're willing to take may seem like you're doing them wrong for paying so little (so pay them more 😉)- but that could very well be the most they've ever been offered in their life. Or, maybe it is less than they currently make, but the remote life and all of its benefits make it worth it for them.
On top of that, they'll go from learning in their spare time of a handful of hours a week to 6-8 hour days, 5 days a week.
Tell me you won't get your money back on that investment after 6 months of them working and learning full-time. They'd be beyond junior within 12 months- and arguably worth more than that initial $60k offer. So. Pay. Them. More.
Bake an aggressive pay-scale into their contract.
"We're starting you at $60k/yr, with the understanding that there will be some training needed from us and some learning/growth from you. If everything goes well and you're performing- then you'll get $70k/yr at 6 months. Keep it up and keep scaling your ability- $80k/yr at 12 months."
Again, ^ this is framed around the idea of hiring someone with foundational front-end knowledge, but would need some grooming into the framework. If you're hiring someone who's already familiar with the framework, then your first offer shouldn't be below $70k/yr.
Hire Early. Believe Often.
At the end of all of this, I know it compiles to a company taking a risk on a new hire. Companies don't like taking (uncalculated) risks. Juniors aren't uncalculated.
There are plenty of cases of companies hiring junior and them becoming some of the best employees to company has seen.
We have the opportunity to flood the industry with developers full of good practices and (in my case at least) such a gratitude for finally "making it" that a lot of them will turn around and pay it forward.
Which is all I'd like more companies and hiring managers to do. Pay it forward.
Someone took a chance and hired you early on- maybe before you were even ready. It worked, in their favor and yours.
Pay that forward.
Top comments (1)
Nice!!