Hiring juniors in 2026

Entry-level software hiring has contracted sharply. The reasons are partly cyclical and partly a genuine belief among hiring managers that AI tooling has reduced the need for junior engineers.

The first part will recover. The second part is a mistake, and it is the kind of mistake that is invisible for four years and then extremely expensive.

the argument for not hiring juniors#

Stated honestly, because it is not stupid:

A junior engineer's first-year output is mostly small, well-specified tasks — the CRUD endpoint, the test coverage, the bug in a file someone pointed them at. That work is now substantially automatable. Meanwhile the junior requires mentoring time from senior engineers, which is the scarcest resource.

So the ROI on a junior looks worse than it did. That reasoning is coherent.

why it is wrong#

Seniors come from juniors. There is no other supply. An organization that hires only seniors is free-riding on other organizations' training, and if everyone does it, the pipeline empties. This is a classic collective action failure and the industry is walking into it with open eyes.

The judgment that makes seniors valuable comes from doing the work. The ability to look at plausible code and know it is wrong comes from having written the wrong version and debugged it at 3 a.m. You cannot read your way to it and you cannot prompt your way to it.

If the apprenticeship stops, the next generation of senior engineers does not exist, and the current one retires.

Juniors are better at the new tools. Consistently, in my experience. They have no prior workflow to defend and they explore. A team of only senior engineers adopts new tooling slowly and grudgingly.

Mentoring makes seniors better. The engineer who has to explain why a design is wrong understands it better afterward. Teams with no juniors lose that forcing function and get sloppier about articulating their own reasoning.

what actually has to change#

The old model — hire a junior, give them small tickets for a year, gradually increase scope — does not work as well when the small tickets are automated. The model has to change, not the hiring.

Start them on reading, not writing. Give a new engineer a real system and a week to understand and explain it. Have them write the architecture document that does not exist. This builds the skill that actually matters now and it produces something useful.

Give them debugging, not features. Debugging is the skill that generalizes, that AI is least reliable at, and that cannot be learned from a course. Pair them on incidents. Give them the flaky test nobody wants.

Make them review agent output. Reviewing machine-generated code with a senior engineer walking through what is wrong with it is an extraordinarily efficient teaching mechanism. You get a stream of plausible-but-flawed code, which is exactly the training material you want and which used to be expensive to produce.

Require them to write the tests first. Specifying behavior before implementing teaches design, and it is the part of the workflow that has become more important rather than less.

Do not let them delegate the hard part. For the first year, some things get done by hand, deliberately, because the point is the learning rather than the output. Say this out loud so it does not feel like an arbitrary restriction.

the hiring signal that works now#

Traditional junior screens — implement this algorithm, complete this take-home — are substantially defeated and were never good predictors anyway.

What works better:

A code review exercise. Give them a pull request with three problems. Watch what they find and how they talk about it. This is the job.

A debugging exercise on a real repository. Failing test, thirty minutes, any tools they want including AI. Watch the process, not the outcome. Do they read the error? Form a hypothesis? Check it? Notice when the model's suggestion is wrong?

A conversation about something they built. Follow-up questions until you hit the edge of their understanding. Where that edge sits, and how they handle reaching it, tells you almost everything.

the case to make internally#

If you are arguing for junior headcount:

The cost of a junior is roughly a senior's partial attention for a year plus a below-market salary. The cost of a senior hire in three years, in a market where nobody trained anyone, is going to be considerably higher than it is now.

Every organization that stopped training in 2009 spent 2013 through 2016 paying enormous premiums for the engineers who had been trained elsewhere. It is the same trade and it is being made again.

The organizations that keep training through this period will have a meaningful advantage in five years, and it will be very hard to catch up to them quickly.