Why We Don't Hire Junior Engineers (And Why That Is Not a Crisis)
The most common pushback we get on our “hire architects, not engineers” position is a moral one. If everyone hires only senior engineers, the argument goes, where do the seniors come from? The traditional pipeline – hire juniors, train them, promote them – has produced the senior engineering population the industry runs on. Cutting the bottom of the pipeline will, eventually, dry up the top. The industry will eat itself.
We hear the concern. We do not share it – or rather, we share the concern but disagree about whose problem it is to solve. We do not hire junior engineers at CONFLICT. We have not for several years. We do not plan to start. And we think the worry that this will produce an industry-wide senior shortage is built on a model of how engineering apprenticeship works that no longer matches the technology.
This post explains why we made the choice, why it does not require a moral apology, and where we think the next generation of senior engineers will actually come from.
What the Junior Engineer Role Used to Do
A traditional junior engineer’s job was, by design, a sequence of small, scoped, low-stakes implementation tasks under the supervision of a more senior engineer. The work served two purposes that were in tension.
It produced economic output. The junior engineer wrote code that the business needed written. The code, supervised, was usable. The junior engineer’s marginal cost was lower than the senior engineer’s, so the business saved money by using juniors for the implementation work that did not specifically require senior judgment.
It produced future senior engineers. The work itself, repeated many times over years, built the craft skills that eventually produced senior judgment. The junior engineer learned by writing CRUD endpoints, fixing bugs, reading the senior’s review comments, watching production incidents, and slowly internalizing the patterns that distinguish working code from code-shaped output.
The traditional apprenticeship worked because the same tasks served both purposes. The economic output and the skill-building were the same activity.
Agents have decoupled these two purposes. The economic output of the implementation tasks is now produced more cheaply, more consistently, and at higher volume by agents than by junior engineers. The skill-building, if it is going to happen, has to happen in some other activity. The traditional junior role no longer pays for itself, because the work it was doing is no longer expensive enough to justify a salaried employee doing it.
This is not a moral statement. It is an economic one. The traditional junior role survived for forty years because it was simultaneously useful to the business and developmentally useful to the engineer. The first half of that statement is no longer true. The second half remains true, but the first half is what paid the salary.
What Hiring Juniors Looks Like for a Small Firm
For a small, senior-only firm like ours, the math is brutal.
A junior engineer, supervised, can produce useful implementation output. Slowly. At a quality lower than an agent under senior supervision. The agent’s output is faster, more consistent, less prone to specific classes of error, and much cheaper to operate. There is no economic case for paying a salary for the output a junior would produce, because we could produce the same output at a fraction of the cost without the salary.
The supervisory load on the senior engineer is the second cost. Supervising a junior requires the senior to slow down, contextualize their decisions, write feedback, debrief code reviews, and absorb the time tax of mentorship. Supervising an agent requires the senior to write a precise spec and review the result. The first activity is more emotionally rewarding for many seniors – people are more fun to mentor than models – but the second activity is the one the business pays for.
The third cost is the failure rate. A junior engineer who, after eighteen months of investment, does not develop into a productive senior is a sunk cost. The firm has spent salary, supervisor time, and opportunity cost on an outcome that did not materialize. Small firms cannot absorb this risk the way large firms can. A large firm with five hundred engineers can lose ten juniors and replace them; a small firm with fifteen engineers cannot.
The combination – low output, high supervision cost, real failure rate, no economic case for the output itself – makes junior hiring a luxury small firms cannot defend. We are a small firm. We do not defend it.
Why This Is Different for Large Firms
The math is not the same at scale. A large engineering organization has different cost dynamics, different risk tolerance, and different strategic reasons to hire juniors.
A large firm can absorb the supervisory load distributed across hundreds of seniors, so the per-senior tax is small. A large firm can fund deliberate training programs, run them at cohort scale, and capture economies of scale on the development side. A large firm has career paths that retain engineers long enough for the development investment to pay back. A large firm has strategic reasons to maintain a junior talent pipeline – diversity goals, succession planning, regional employment commitments, university recruiting relationships – that small firms do not.
Large firms should, and many do, continue to hire juniors and develop them. We do not think that should stop. We think that is where the next generation of seniors should come from, because the large firms are the only entities in the industry with the cost structure to make the apprenticeship work.
The mistake – and we see it often – is when leaders of small firms feel pressured to mimic the hiring patterns of large firms in the name of “supporting the talent pipeline.” They cannot mimic the patterns successfully. They can hire juniors, but they cannot afford to develop them at the rate the large firms can. The result is a junior hire who gets less training, less mentorship, and less career trajectory than they would have at a large firm, while the small firm pays a salary it cannot economically defend. Both sides lose.
Where the Next Generation Comes From
The honest answer is that we do not know in detail. The historical pattern – juniors trained at small and mid-sized firms, growing into seniors who move freely across the industry – is shifting. The next pattern is not yet clear. A few hypotheses about where it is heading.
The dominant entry path will be large firms with formal training programs. Companies that have the scale to invest in cohort training, rotational programs, and structured mentorship will increasingly be the only ones doing meaningful junior development. The flow of senior talent in the industry will, for a decade or two, come heavily out of these firms.
Some of the development will move into formal education. Universities that have historically taught computer science as theory will start teaching engineering practice – spec writing, code review, system design, operational ownership. This is overdue. It does not currently happen well. The schools that figure it out first will produce graduates who are closer to senior-ready than the current cohort.
A non-trivial fraction of seniors will be self-taught operators of the new tooling. Engineers working in agent-heavy environments are developing the skills of specification, review, and judgment without going through the traditional implementation apprenticeship. Some of them will become senior in functional terms without ever having been junior engineers in the traditional sense. The industry does not yet know how to credential this path, and the next decade will involve a lot of arguing about it.
There will be a population of engineers who do not make the transition. Engineers whose careers were built on implementation skill, who do not develop the architectural skills the new environment requires, will struggle. This is sad. It is also real. The industry is not the first to undergo a skill-base shift, and it will not be the last. The compassionate response is upskilling investment. The unrealistic response is pretending the shift is not happening.
What We Tell Junior Engineers Who Apply
We get applications from junior engineers, regularly. We answer them honestly. We tell them the same thing we are telling you now: we are not in a position to develop them, and we would rather see them land somewhere that is. We point them toward firms whose scale and structure can give them the apprenticeship we cannot.
This is not a satisfying answer for the applicant. It is not a satisfying answer for the industry. It is an honest one. We are not going to pretend to be able to do something we cannot do, and we are not going to take on engineers we cannot develop just to feel better about our hiring choices.
If you are a junior engineer reading this: do not take it as a verdict on your trajectory. It is a verdict on us. The firms that can develop you exist. They are largely the ones with thousands of engineers, formal training programs, and structured rotation. Apply there. Develop. Come back to us in five or ten years when you are senior. We will hire you then.
The Honest Statement
We do not hire junior engineers because the economic case for the traditional junior role has weakened to the point that we cannot defend the hire. This is not a moral failing on our part. It is the result of working through the math honestly.
The industry needs junior engineers to be hired and developed somewhere. We are not the right somewhere. The large firms with the scale to make the apprenticeship work should do this work, and most of them are. The senior population of the future will come from there.
The small firms that are pretending to do junior development they cannot afford are not helping anyone. The most honest thing they can do is hire seniors, do the work they are best at, and refer the juniors elsewhere. That is what we do. That is what we will keep doing.
Not every contribution to the industry is a hiring contribution. Building good software, training the senior engineers we do hire, and shipping work that demonstrates what the new model can do is also a contribution. We are making the contribution we are equipped to make.
