Posted on 12 mins read

This was originally written in 2018. It remains one of my more popular blog posts, so I’ve taken some time to revise it to match the current market environment and my evolving opinions on the topic.

Let me tell you the story of a very successful company that made a very big, dumb decision.

We don’t hire junior developers or interns…if you don’t get a puppy, you don’t have to clean up its messes.

~ Netflix

I’m flabbergasted that some corporate schmuck figured out a way to cast puppies in a negative light and people kept listening. I mean, puppies are the purest beings on planet Earth. Literally made out of playtime and fur. Bright spots in a lonely world. But I digress.

As of 2022, Netflix has started a New Grad Program and annually posts new positions for junior engineers, as well as short-term internships for college students. On the program page they use this as an opportunity to talk about their professional development and continuing education programs. Kudos to Netflix for figuring this one out.

A lot of companies have followed suit with a “we only hire seniors” strategy. When asked why, they’ll offer responses like:

  • We don’t have the time or resources to hire junior developers; we’re moving too quickly.
  • The company can afford senior developers, so there’s no need to hire juniors.
  • We can’t afford to make mistakes at this point. The stakes are too high.
  • Our organization gives a lot of autonomy to its employees. We aren’t set up for the kind of hand-holding that juniors need.
  • We want to get our initial software product in place before we hire anyone inexperienced.

The implication here is that junior developers are a liability, something that a company takes on out of a sense of duty or because of an ailing budget. And the implication of that is, well, maybe other companies can afford to do corporate charity projects and substandard work, but we sure can’t.

Let’s think about this for a moment. There are over 100,000 tech companies in the US, and I’ve never heard one single CEO say “our mistakes don’t matter a lot” or “we need a way to spend some of this loose cash we’ve got sitting around.” Multiple studies have been done on the reasons why companies fail; technical inexperience among rank-and-file employees has never been on the list (though poor management and resistance to change frequently are). And as a career developer, I’ve never seen a case where the presence of talented junior developers was anything but a powerful advantage to their team. So, all you “senior developer only” outfits, whatever shortcut you think you’re taking, whatever system you think you’re cheating, at best you’re cargo culting and at worst you’re hallucinating. There’s no competitive advantage to shutting out juniors. And placing arbitrary limits on your hiring pipeline is a sign of out-of-touch management.

The way you hire and treat junior developers is a valuable proxy measure for the health of your organization, your product line, and your internal culture. Experienced developers know this. And if that isn’t compelling enough, hiring a fair balance of junior developers is a wise financial decision as well.

Preventing messes

If you refuse to hire junior developers because they make “messes,” you’re sending a message about your company culture: no mistakes allowed. You’re painting yourself as the company that fires somebody every time a server goes down. Regardless of how much you pay, nobody wants to work in an environment where job security is touch-and-go. And trying to scare developers into making fewer mistakes spreads a culture of fear and initimidation, which is disastrous for mental health and productivity. Development work slows to a crawl in this kind of environment.

You might argue that this attitude encourages developers to be cautious and implement processes that guard against error: automated testing, QA, failovers, access control, and reversible code changes, to name a few. But this theory is entirely backwards. If company guidelines encourage the use of failsafes like these and the company provides the time and resources for developers to implement them, the “no mistakes allowed” culture isn’t necessary or valuable; most issues will be caught long before they reach production. And every developer, junior and senior, thrives in an environment where strong development processes protect them from worst-case scenarios.

What about the problems that make it past every layer of prevention you’ve put in place? These are valuable opportunities to shore up your defenses. As Code Complete explains, “The longer [a] defect stays in the software food chain, the more damage it causes further down the chain….The cost to fix a defect rises dramatically as the time from when it’s introduced to when it’s detected increases” (2nd ed., pp. 29-30). In the worst case, a defect can cost 100 times as much to fix if it’s discovered too late. Junior developers usually uncover these defects sooner than senior developers, who intuitively know which buttons not to push. So the only question is, do you want to debug your process sooner or do you want to debug it later? “Never” is not a choice, as any experienced developer will tell you. If something can go wrong, eventually it will.

Naturally, you’ll need a few senior development and ops leaders to lay the groundwork and set precedents for an error-resistant development cycle. Nobody’s saying you should only hire junior developers. But if you truly have a workplace that cares about mistakes—that is, a workplace where mistakes are caught early and often—junior developers will fit right in. And developers of all levels will enjoy higher job satisfaction, since error resistance liberates them to build great software (instead of constant firefighting) and protects their nights and weekends.

Bottom-line savings

According to Indeed, a Junior Software Engineer makes an average salary of $79,520, while a Senior Software Engineer makes an average salary of $141,305. A Senior costs almost twice as much as a Junior.

The cost is often justified. Senior developers are expected to be more productive than junior developers. That’s not the whole story, though, and thoughtlessly writing it off as the cost of doing business is needlessly expensive.

Most application code doesn’t require years of experience to write, or even to write well. Every program includes “glue code” that connects various inputs and outputs in a mundane way. It doesn’t matter a lot who writes it. You can pay someone $40 an hour to do it, or you can pay someone $70 an hour to do it. Either way it will come out about the same. If you only hire seniors, you’re paying a premium for a great deal of entry-level work.

Code also varies significantly from application to application, and familiarity is a key factor in productivity. In most cases, a junior developer with six months of experience on a team will be more effective than a senior developer who just signed on, for no other reason than familiarity with the domain. And in my experience, it takes at least six months, often much longer, for the senior developer to catch up. Sometimes they never do. With a bit of talent and a studious attitude, it’s not uncommon for a junior developer to outperform their senior peers indefinitely.

The aforementioned glue code and domain-specific code account for at least half of all development work. What remains is code that truly demands and benefits from the expertise of a senior developer. And even for this code, a junior developer can do outstanding work if they have access to sufficient educational resources and the guidance of an experienced mentor.

For these reasons, a pairing of one junior and one senior developer is frequently equivalent to two senior developers, and comes at about 78% of the total cost. If your goal is maximum productivity for minimal expense, this junior/senior pair should be the fundamental molecule of your organization.

As an aside, one factor that’s impossible to account for in these numbers is the stereotypical tendency of senior developers to debate about topics that end up being insignificant to a project’s success—algorithms, microsecond optimizations, programming paradigms, large-scale refactors, and so on. Having too many senior developers on a project can be like having too many CEOs at a company. If an organization hires only seniors and doesn’t have a rock-solid decision-making process in place, projects can spend hundreds of hours mired in decision paralysis. Junior developers rarely have this problem.

Building careers

If you don’t hire junior developers, another message you’re sending is that you don’t know how career progression works.

Again, this isn’t about corporate citizenship or “doing your part” in the tech community. This is about making your company a decent place to work so that developers will join your company and stay long enough to make an impact.

I’ve heard a few developers say “I’m done changing job titles. I just want to be a senior developer forever.” However, I’ve never heard one say “I hope I never get a pay raise or learn something new or get recognized for my achievements ever again.” And, inconveniently, the resources necessary to sustain ambitious ladder-climbers and complacent senior developers are about the same. You need ways to measure and recognize a job well done, plentiful educational resources, and a variety of projects young and old in your development pipeline. You need to create a sense of progress, even for those who don’t want a promotion.

But don’t get stuck on those folks. They’re a minority. Most people in tech aren’t planning on being senior developers for 40 years straight. We dream of being software architects, team leads, CTOs, and founders. And a company that advertises its disinterest in career progression is going to rank very low on our list of prospective employers.

One of the most impressive things a developer can hear as they walk into a job interview is, “Hi, I’m a team lead, I’ve worked here for eight years and I joined the company as an intern.” Impressive—and very rare. That person is intensely valuable to the company. They know the product line in and out, they’ve seen code from every project within a 100-yard radius, and they’ve worked alongside everyone in the organization. They can innovate within that company in a way very few can. And the company is earning inestimable dividends on that person’s work because they figured out how to keep them interested for eight years—about one tenth of their life expectancy. That’s a sign of success for the company’s culture. It marks a workplace where morale is high, good work is recognized, and interesting projects are waiting around every corner.

Saying “we don’t hire juniors,” on the other hand, is an open admission that your company isn’t prepared to be part of someone’s career. It essentially advertises stagnancy: the company expects experienced and talented developers to join the company and contribute indefinitely while getting nothing but a paycheck for their efforts. Some are willing to do that, but only if it’s a truly massive paycheck.

If your company is committed to career growth, on the other hand, a restriction against junior developers only serves to shrink your hiring pipeline and shorten the possible tenure of your employees.

Making great software

Junior developers have several unique traits that their more experienced colleagues have usually lost. One of these is blind optimism. Another is a willingness to follow. But perhaps the most valuable trait juniors bring to the table is their lack of baggage. Senior developers have seen technologies come and go, projects fail, teams dissolve into infighting, and all the other trappings of the technology sector. They build up strong opinions and often overgeneralize, assuming that what worked (or didn’t) for one team or one project must be equally effective for another. And this can manifest as a slowness to learn the nuances of a new problem space.

Sometimes a project manager’s job is to say “I know that didn’t work there, but maybe it will work here.” And a junior developer is usually the best person to test that theory—they can build a proof-of-concept or a prototype without bringing along any of the biases that senior developers have built up over the years. As a junior developer I frequently took on this kind of work, trying out new tools and technologies, rebuilding things in a different way, proving out ideas that others had judged too quickly. I often discovered better ways to build and the company’s software was materially better as a result. There were cases where page load time improved by an order of magnitude; multiple pages were condensed into one, saving weeks of future maintenance; or the company was able to rule out insufficient technologies that could have led to weeks’ worth of wasted time. The benefits provided by a clean slate and a fresh perspective are substantial.

Some companies may be able to get away with putting a bunch of senior developers in a room and letting them fight through to a consensus over how to solve problems and build things. But adding a few juniors to the mix, developers whose time you can afford to spend on one-off experiments and wild ideas, will turn up surprising improvements to your products.

When it comes to software quality, junior developers also do an important form of work that generally goes unappreciated: they place natural limits on the heady, overengineered code that their senior colleagues may be tempted to write.

If you replace “average or mediocre” in the above tweet with “junior,” you can see how this works. A codebase is an abstract record of the way its contributors think critically. A healthy mix of junior and senior contributors encourages simplification, which makes features easier to build as time goes on.

Building a better pipeline

The widespread “seniors only” attitude in tech undervalues junior developers. It’s a detriment to everyone, especially the organizations that mistakenly think they can make things easier by shutting out inexperienced candidates. Although some of these companies have been financially successful, the waste of money and opportunities they’ve absorbed is likely massive.

If your company is ahead of the curve on this issue—if you know how to hire, train, and retain junior developers—you’re reaping benefits I’ve only begun to describe here. Your company has lower turnover, higher diversity, and less overhead than the competition. Your software is less likely to break and more likely to delight. There are, of course, other factors at play. But a competent approach to hiring and retaining junior developers is an important mark of a quality workplace for developers at every level.