Why companies don't hire juniors
It's a nice thing to do. That's not enough.
This was a talk at a conference last year.1
I’ve heard the commentary that companies are afraid to hire juniors many times. And there's plenty of anecdotes on Twitter:
As someone who has hired many juniors (eg this guy) here's some thoughts on why more companies don't. In my opinion there are two major reasons.
As a disclaimer, I've worked with and hired lots of great juniors over the last 10 years. I've also worked with some that haven't been so good, and I've interviewed people that I didn't hire. All of which is to say, nothing I say here should be taken as a comment on any one specific person.
Remote work made training too hard
Last decade, if you hired a junior you'd have them sit next to someone more experienced who is their buddy. The deal would be, they can ask their buddy any question at any time and the buddy would help them out. During that time you expect a lot less output from the buddy. Ideally you'd only do this for a few weeks, then the buddy either moves onto another freshie or goes back to writing code full time. This is an incredible way to learn, and it's good for the buddy too because it's something different to just writing code all day. And for managers it's a great model because it's really easy to see if the junior and buddy are working together well and if the junior is progressing. "Managing by walking around" is a thing and it works very well here.
I implemented this model successfully many times, and whenever I did it the unspoken assumption was that the junior would turn up to work on time every single day. This made sense because they were eager to learn and they were learning a lot very quickly. I knew it was a good model because this is how I started my career. My first job I worked at for about 15 months, and I went into the office every single day. I didn't even have a setup at home. I learned so much from that job that I was able to start Tanda immediately after.
Obviously the idea of remote work wasn't invented in 2020, but before then it was still a minority view and you didn't look like a lunatic for giving someone a desk in an office. Today that is totally different. Barely any companies are 100% in-office (in the software industry). Any company that isn't remote is "hybrid", meaning the social contract is that everyone is "in the office more days than not". That's basically the system we have at Tanda these days.
The problem is that training is exponentially harder with this model. First, the junior doesn't even think they need to come to work every day! This is amplified by their buddy not being there half the time, you can do the math on how many actual days of overlap they are expected to have. If you've ever explained something over a Github comment or a Zoom call vs in person or on a whiteboard, then you know that learning will be exponentially slowed as a result.
To be clear: I'm not attacking remote work! I get why people like it. I like it! But I have over 10 years experience, so the things I am learning day to day are totally different to what juniors need to learn. Because of the big slowdown in learning basics, remote work is really bad for juniors. Put yourself in the manager's shoes:
You can assume learning is slower because there's less buddy interactions
You know that learning is slower because you can see output is slower/worse
You can't tell if the buddy is doing a good job and getting along with the junior just by walking around
You're going to reconsider if the junior training program is worth having. This leads into problem 2…
Juniors are not cheap anymore
When we were starting out 10 years ago, in a mid-sized Australian city, you could get university graduates who were reasonably able to write code, and very good at learning (with a good buddy to help), for a very reasonable wage.
Today that is not the case. Cumulative inflation in Australia from 2014 (when we made our first grad hire) to today is 16%. The entry level wage we pay for a developer has gone up over 50% in the same time.
I'm sure you could do more research on this and see if this is consistent across the industry - I believe it is, but don't have any data. I also don’t have data back through to 2014 on mid-levels and seniors, but over a more recent time period I can confidently say that the increase for them is nowhere near as aggressive.
In other words, there is a decrease in the gap between junior and mid-level wages. A fresh graduate today earns pretty close to what a mid-level developer earned in 2014. At the same time all wages are going up.
This is great for the developer and I don't begrudge them at all!
But from a manager's perspective it nudges you into rethinking the juniors. 10 years ago you could get "two juniors for the price of one mid", and if you were confident you could train them well, you could jump start two careers! A great deal for everyone. Today that bargain doesn't exist, so as a manager you ask yourself "why go through all the effort of training someone when I could just hire someone who's already been trained".
The economic problem in a nutshell
The easiest way to cut costs in a business is to avoid new expenses. It's much less painful than cutting current expenses.
So if you are trying to get to profitability (which everyone will be as we enter a recession), you can "decrease engineering wages as a percentage of revenue" by lowering people's salaries, or by committing to hiring less. Everyone will choose the latter option. The first hires to cut are the least profitable ones, and the least profitable hires are juniors.
Juniors at Workforce.com
As I said, we always hire juniors. But I understand why other companies choose not to. As much as some people on Twitter will imply, I don't think any company has an obligation to hire and train anyone. If a company has thought through the economics of the situation, then during a recession I don't think they will change their mind just because someone on the internet said that it's the right thing to do. An economic argument must be made too.
Here’s some things we are doing that make hiring juniors work for us:
Support Engineers
Most of the juniors we hire are developers straight out of coding bootcamps. So they are not quite university graduates, but more often they are looking for a career switch. We’ve had a lot of success putting these folks in Support Engineering roles, which is a mixture of writing code, debugging code, and responding to complicated customer issues.
This works well because it lets them develop their skills at a more relaxed pace; there isn’t the pressure to be a productive, useful, full time developer on day 1. And it also has them doing highly productive and useful work from day 1. Some Support Engineers love the role and stay in it forever, others switch to a full time developer path later. Either option is a great career move; there’s no pressure to switch to being a developer if you don’t actually want to.
Full Time In Office on Day 1
I mentioned above that the “hybrid” office social contract that every non-remote company has these days is not a good thing for training juniors. One of our offices has found a simple solution: every developer starts full time, 5 days a week, in the office. Once they hit their stride, things might get a little bit more relaxed, depending on the role.
Telling people this in interviews works really well. A few applicants get put off by not being 100% remote. Most are excited to actually meet their colleagues, get real training, and not go crazy sitting at home all day.
If you offer exactly the same “perks” as everyone else you will get average candidates. By offering something no other company offers, we’re able to take our pick of the best candidates that like to work the way we like to work.
As a junior looking for a job - don't give up! Good jobs will always be out there, and if you have the skills you'll find them. But keep the issues I noted here in mind. Remote work with top 5 percentile wages sounds awesome… but maybe for your very first job you could commute, settle for a slightly lower wage, and consider a support engineering role? If you focus on learning quickly and developing useful skills, the money will follow. The inverse is not true.