Eighteen months ago, my co-founder and I made a decision that felt obviously correct at the time: we stopped hiring junior developers. We'd burned through three of them in a year, each one taking four to six months to become genuinely productive, and each one leaving within a year of getting there. The math seemed simple. Hire senior, skip the ramp-up, stop the bleeding.
We were half right. The bleeding stopped. But we traded one problem for a worse one, and it took us most of those eighteen months to understand why.
What We Thought We Were Solving
The visible cost of junior hires is obvious if you've run a small engineering team. You pay a salary for someone who can't yet ship independently. You pull a senior engineer off their own work to mentor them. You absorb the mistakes that come with inexperience, the kind that cost a few hours of debugging rather than a production incident, but still cost something.
We did the math on this and it looked bad. Each junior hire was costing us roughly four months of reduced senior output before they became a net positive contributor. With a team of six, losing even a fraction of senior capacity for that long felt unaffordable. So we decided: senior only, going forward.
What We Didn't See Coming
Senior engineers are not interchangeable with junior engineers who eventually become senior. This sounds obvious written down. It was not obvious to us eighteen months ago.
The first problem was retention, the same issue we were trying to fix, just relocated. Senior engineers we hired stayed an average of fourteen months before moving on, often to companies offering either more money or more interesting technical problems than a six-person startup could provide. We'd swapped a junior retention problem for a senior one, except senior hires were more expensive to replace and harder to find on short notice.
The second problem was culture, and this one took longer to recognize. Junior engineers, whatever their cost in mentorship time, were absorbing our way of building things. They learned our codebase conventions, our product reasoning, our customer context, because they had no prior context to default back to. Senior hires arrived with strong opinions formed at other companies, which is exactly what you want for technical judgment and exactly what creates friction when those opinions conflict with how your product actually needs to work.
We ended up with a team of capable individuals who each built slightly differently, because nobody had grown up, professionally speaking, inside our specific context.
The Decision We Should Have Made Instead
The actual problem wasn't junior versus senior. It was that we had no system for developing junior engineers efficiently. We were treating mentorship as an ambient cost that senior engineers absorbed informally, rather than as a structured process with clear milestones and accountability.
Once we recognized that, the fix wasn't to abandon junior hiring. It was to build the system we should have had from the start: defined onboarding milestones at thirty, sixty, and ninety days, a single senior engineer assigned as a direct mentor rather than informal questions to whoever was available, and explicit conversations about career trajectory within the first month, not the first performance review.
We brought back junior hiring six months ago under this system. The ramp-up time dropped from four to five months down to roughly eight weeks. More importantly, the engineers we've hired under this system have stayed, because they can see a path, not just a job.
What I'd Tell a Founder Considering the Same Cut
If you're looking at your junior hiring costs and considering doing what we did, I'd ask one question first: do you actually have a system for developing junior talent, or have you been relying on informal mentorship and calling it onboarding?
If it's the latter, cutting junior hires doesn't solve your problem. It just moves the symptom somewhere more expensive. The fix isn't avoiding the investment. It's making the investment structured enough that it actually pays off, instead of leaking out the door eight months after it starts working.
We learned this the expensive way. I'd rather you didn't have to.