Reasons to Hire Junior Engineers
What does an efficient team composition look like?
I was recently drafting a post on the problem of using head count as a metric. There were too many implications in it that hiring a junior engineer was a bad thing, so I've decided to publish this post first. After all, every engineer starts as a junior engineer. Without them, we wouldn't have senior engineers.
We should get one thing out of the way first. Software engineers contribute value to a business at a higher rate than their salary growth. That means an engineer making $150k a year is likely provides much more than 2x the contributions of an engineer making $75k. An engineer making $200k a year almost certainly provides more than an extra 33% compared to an engineer making $150k a year.
Any decent engineering manager understands this, even if they've never articulated the thought that way. If you're an experienced engineer, just think of your own contributions to the companies you've worked for relative to your salary growth, especially that first year. A 50% raise is significantly more than what most companies give out, but a junior engineer is probably at least twice as capable their second year on the job than their first. I don't know any company that hands out 100% raises (or even 50% raises) to junior engineers.
If that math is correct though, why does anyone hire junior engineers? Wouldn't it make sense to just stack a team of only senior engineers?
The first reason starts with what makes a senior engineer so much more valuable than a junior one? What is developer productivity? Can senior engineers type 5x or 10x as much code? Will their code perform 5x faster? Will they have only 1/5th of the bugs?
The answer is none of the above. What makes senior engineers valuable is the quality of the decisions they make. I once cut 3 weeks off a project by asking a single question. There are a number of decisions that have to be made on every engineering project that can have a massive effect on the quality of the software and the timeline to deliver that software. You can't complete a project just by making decisions though. It would be ridiculous to say I could have instantly completed a 12 week project by asking 4 questions.
Once decisions are made, a senior engineer may be able to execute on those decisions slightly faster than a junior engineer, but the speed of that execution is probably not going to be 5x. Most software engineers (including me) work on glorified CRUD apps. (For those who aren't software engineers, think of a CRUD app as just entering, modifying, and displaying data on a spreadsheet. It's not rocket science). Those apps may provide huge value to businesses or the general population, but they're ultimately still just CRUD apps. The decisions may be complex, but the code rarely is. You don't need a Phd in computer science to do the job of most software engineers, as evidenced by how few software engineers have a Phd.
Example, a lot of factors come into play when deciding on whether to use a message queue and if so, how it should be configured. Once those choices are made, the code is simple enough for a first year college student to write it. The same goes for databases and ORMs used to connect to those databases.
With that understanding, let's compare two hypothetical 5-person teams. Team A has 2 senior engineers and 3 junior engineers. Team B has 5 senior engineers. Team B has 150% more senior engineers than Team A. Yet the decisions made would only be marginally better at best. If you account for too many cooks being in the kitchen, the decisions may actually be worse. Every team benefits from having senior engineers. Once you have enough to make the necessary decisions, every additional senior engineer has a signficantly diminished return.
Whenever anyone talks about an engineer being 5x-10x better than another, they're averaging the benefit of the decision making (which could be 100x-1000x better) with the execution (which could be 10% - 20% better). It is on that execution side that an engineer's salary growth matches their productivity more closely, making Team A significantly cheaper while being just as productive.
The second reason to hire junior engineers requires us to understand the cost of learning. With experience comes the understanding that some things don't matter. Depending on their experience, different senior engineers will close off certain possibilities. This is important when making decisions because it helps prioritize likely scenarios over unlikely scenarios. Senior engineers will also take the basics for granted because they don't really need to think about them. The basics are just accounted for out of habit.
The unfortunate side effect is that senior engineers have tunnel vision for problems being at their level of expertise. I once spent an internship working on a system that dealt with a lot of concurrency. Anytime there was a bug, there was a 90% probability that the bug was caused by a race condition. The senior engineers always thought of those possibilities first. I was still working on learning the basics so I just looked for the basics. On the (rare) occasions that the bug was caused by something simple, I tended to find the issue faster.
This tunnel vision also means that junior engineers can help senior engineers make better decisions. The world of possibilities is larger for a junior engineer because they haven't learned what doesn't work yet. What doesn't work in most cases can help in some rare causes though. Having a junior engineer make suggestions (or ask questions) is not a waste of time, even if 90% of those suggestions are immediately discarded. The one time they have a point will often make up for everything else. A team is more than a sum of its parts and in the earlier example, Team A is set up to make better decisions as there is more balance in the factors being considered from the junior engineers' *lack* of experience.
That leads us to the third reason to hire junior engineers: experience is not interchangeable and that makes senior engineers incredibly difficult to hire. Software engineering is an incredibly broad field. There isn't enough time in the day to become good at everything. You can't expect an engineer who spent 20 years helping systems achieve a high level of scale to write machine learning algorithms at the level of an engineer who spent 20 years working on machine learning algorithms. When you hire a senior engineer, you're looking at the subset that has the specific experience you need for your project. That subset can be hard to find. That subset may not even exist. Example: there are plenty of memes about job postings requiring 10+ years of Kubernetes experience at the time that Kubernetes had only been around for 5 years.
To add more complication to hiring senior engineers: not all experience is positive. I had a college professor once tell the class that there were engineers with 30 years of experience, and then there were engineers with 1 year of experience repeated 30 times. Learning is hard. It is easy for an engineer to achieve a certain level of competance and then stay at that level for years. Plateauing is comfortable. The danger in engineering is that practices can become outdated so someone who plateaued decades ago is actually less productive than a junior engineer. Example: It is significantly easier to get a junior engineer to write automated tests than it is an engineer with 20 years of experience and never wrote tests before.
So not only are you working with a small subset when hiring senior engineers, you also have to filter for people who actually perform at a senior level as years of experience is not enough. Contrast that with the pool of junior engineers where there are a ton of smart people available.
Those are my reasons to hire junior engineers. I'm sure other people have different ones. I'm sure you do! I'd love to hear them so please write them in the comments.