Why it's so much harder to get your first job as a junior engineer

Can't get a job because you have no experience; can't get experience because you don't have a job

I went to dinner a few nights ago with a software engineering manager who makes north of $500k/yr, and they told me something I found profound:

"I could easily get a senior engineering job because of my experience. I don't think, in today's environment, I would easily get a junior engineering job."

Turns out companies prefer to hire engineers with experience. But how do you get experience if you don't get a job? That's the entirety of the challenge of breaking into the software engineering field.

So how do you get experience if you don't have any?

Understanding the Job Market

While it may be tempting to shout at the world (and the job market) that they are wrong to only look for experienced candidates, we need to fight that temptation and face reality. There are reasons companies don’t hire junior candidates, and we need to understand what those reasons are, and how we can overcome them at the many companies that do hire junior candidates.

First, accept that the companies that opt to not hire junior people are rational, not evil. They have reasons, and understanding and countering those reasons are the key to our getting hired.

This problem is particularly pronounced in technical fields or fields where there are high levels of burnout, turnover, or rapid increases in salaries (for reasons we’ll see shortly).

Before we think about how to overcome this hurdle, let’s first seek to understand.

Usually it goes something like this:

Why Companies Shy Away from Hiring Junior Candidates

Let's take a hypothetical example:

AcmeCorp measures the output of its engineering team. It’s a somewhat crude measure, but they try to quantify exactly how much output they get out of each engineer and each team numerically, and their goal is to achieve the maximum output with the minimum investment.

Let’s say a junior engineer outputs 1. A more senior engineer might be 2 or 3. Susan, who is phenomenal (and expensive), produces output at a level 4. In other words, Susan produces about four times as much output as a junior engineer.

Susan has been going it alone for some time, and the company hopes to increase productivity on her team from 4 to 7 or 8. In order to do so, they decide to hire 4 junior engineers (Susan’s 4 + 4 engineers at 1 each = 8).

Susan gets paid $300,000/year (and is constantly turning down offers from Google and Facebook for higher), but junior engineers can be hired for only $80,000/year for a total of $320k. So to get the additional four points from junior engineers will be a little more expensive than getting the same from Susan, but if you factor in the recruiting costs of finding another Susan (which could be $30-$50k) it’s a reasonable tradeoff.

(Quick note: If you’re in shock about how high the salary and recruiting costs are for a Susan, know these are perfectly realistic numbers at a certain levels of software engineering).

So AcmeCorp hires four junior engineers, each at $80,000/year.

It quickly becomes clear that one wasn’t a good fit, so they are let go after the first month (and only $10,000 in salary), Susan works on training the other three. The other three are bright, talented, and hard-working.

But instead of output instantly shooting to 7 (Susan’s 4 + the three engineers at 1 each), instead Susan is spending most of her time mentoring the new engineers. She’s spending so much time training she’s not really writing any code at all, and the three engineers combined are only producing at 2 as they learn the ropes.

So AcmeCorp is now spending $540,000/yr in salary - almost twice what it was spending before - and output has actually decreased from 4 to 2. That’s an investment AcmeCorp is willing to make, but it stings a little, and they really want to see output increasing to what was originally planned as time moves on.

After 6 months the junior engineers are where AcmeCorp had hopped, each has an output of 1. (combined for 3). Huge success. Except for one thing: Susan has to spend some time managing those three, so her output has only returned to a 2. AcmeCorp ended up with an output of 5 for $540k instead of an output of 4 for $300k. They start to wonder if they should have hired another Susan instead of the four junior engineers.

But then… right as things are getting ramped up, 2 of the 3 engineers get offers at other companies, for $120k and $150k, respectively. AcmeCorp matches the lower salary ($120k) but can’t justify the $150k, and that engineer moves on. AcmeCorp has now spent about $60,000 training that engineer for very little return.

Now AcmeCorp has moved from a productivity of 4 at a cost of $300k to a productivity of 5 at a cost of $500k, not including the $70,000 of cost incurred training the two engineers who have now left, or the decreased productivity from Susan to reach this point.

If they would have hired another Susan, maybe they would have spent another $50k in recruiting costs, but then they’d be at 8 for $600k instead of 5 for $500k, and they wouldn’t have lost additional time and money ramping up to get to this point. Next time, maybe they’ll just hire senior.

This scenario is pretty common.

A company wants to invest in young talent, and it does so, but doing so slows productivity, distracts top performers, and as soon as the junior talent is at a level of self-sufficiency it leaves. This happens especially often if the company is not good at or efficient at bringing in junior talent.

The reality is hiring junior talent can be a risky, thankless, painful task.

It doesn’t always happen this way, and some companies plan for some elements of this to happen (or they literally can’t find enough Susans anyway and are forced to hire juniors), but in looking at the frustration we can clearly see what our job is to overcome when trying to convince the companies that are hiring juniors to hire you:

To the extent possible...

The three things you have to show:

You have to show them you won’t slow productivity. That is a mix of programming ability, having shipped actual production code, and that you learn quickly.

You have to show them you won’t distract the top performers. That means that you're a self-starter, that you can solve some of your own problems, and that you are respectful of the time of those who are (generally) happy to help you.

And, perhaps counterintuitively, you want to show them you won’t leave. This is the advice that is probably the most controversial, but you want to signal, in every way you can, that you won't bounce after six months. That can look like talking about how excited you are for the opportunity, how much you love the company, talk about your level of commitment, etc.

There are many criteria for being hired generally that still apply, but when you’re interviewing for a junior role (or fighting to get an interview) these will be the questions nagging your interviewer - these are the things they’ll be keeping in their mind.