To be clear, by entry-level, I mean 0 years of experience, but with the skills that you would get from a bachelors in CS (or related) and some internships. Going by myself, when I graduated, I had built a compiler, a SQL-like database, a 3D modeling and animation application, image processing algorithms, a robot-arm controller, a theorem prover, etc. I had used version control, worked in the computer center, and had some tech-related summer jobs. This pales in comparison to what I’ve seen from modern CS graduates.

When I was hired at my first job, I fixed a lot of bugs to learn the codebase. My first big task was to reduce the memory footprint of our application by rewriting our windowing code (this was on DOS, so we simulated windows with ASCII Art). I worked on build scripts. I helped port our software to UNIX. I fixed a lot of core dumps. I worked on our printing code (yes, printing to paper). I could do all of this without understanding what Foreign Exchange Options were (yet). There’s a ton of work like this on most teams, and frankly, you are overpaying if this is what you have your senior devs doing.

That’s the main reason you need entry-level devs. There’s a lot of work that is only cost-justified if they do it. They can learn while paying off some technical debt, automate tests, and fix the quality-of-life bugs that make your app look unpolished. They can learn your domain by participating in code reviews.

The second reason is that all of this work is hindering your senior staff from growing. They shouldn’t be doing this work—they should be driving bigger outcomes (as I wrote on How Senior Software Developers Think). You are risking them leaving because they fear having 1-year of experience 5 times.

Finally, healthy teams have a diversity of experiences. An all-senior team may seem great, but they will have more groupthink than a team with some junior developers. It gives seniors a chance to mentor and will frankly make them code better (because it needs to be understood by less experienced team members). Having to explain things makes sure you understand them yourself. Documentation will be better, because you need it to be.

If you know how to retain them, entry-level developers grow with the company. Our CEO had started right out of school (where he was the first hire, I think). I eventually went on to lead the engineering team. At Atalasoft, we hired mostly entry-level, and they went on to build the products that were the basis of our acquisition. My last job, Trello, was co-founded by Joel Spolsky, who famously wrote about how to find great developers – TL;DR: get them at the entry-level. When I joined, a lot of the engineering team (that had built Trello to 7 million users by this point) had been hired out of college.

I understand that there’s risk, but learning how to recruit and evaluate entry-level developers is a core skill that your team should have.