Why I'm still hiring juniors

In March, when I asked for a second junior engineer in this year’s plan, our CEO asked me a question I’d been half expecting. If a senior engineer with an agent now gets through what used to take two people, why would we hire someone who’ll take most of a year to be really useful? It wasn’t hostile. It’s the obvious question, and every engineering leader I know has been asked some version of it this year.

I gave an answer I wasn’t completely happy with, we hired both, and I’ve been working on a better answer since. Then last Tuesday Matt Garman, the CEO of AWS, said on Matthew Berman’s podcast that replacing junior staff with AI was “one of the dumbest things I’ve ever heard”, and four people sent me the clip within a day, so this is the better answer, or at least the current draft.

Garman’s version

His reasoning, as it’s being quoted, was that juniors are the least expensive people you have, that they’re the ones most leaned into the AI tools, and that if you stop hiring them, then ten years from now you have nobody who’s learned anything. I agree with the last part completely. The first two I’d put more carefully.

Cheap is true but it’s not much of an argument. A junior engineer costs us a lot less than a senior, and still a lot more than an agent subscription. If the only question is cost per unit of output in the next twelve months, the agent wins, and pretending otherwise isn’t going to convince anyone in a planning meeting.

“Most leaned into the tools” is also true, in my experience. It’s also the part that worries me most, and I’ll come back to it.

The pipeline argument is the one that works, and the one I made in March. Every senior engineer on my team was a junior once, on somebody’s payroll, being slow at things. I was one, in the early 2000s, and before that I was a teenager writing TSRs in Turbo C and learning what a segment register was by crashing DOS a few hundred times. Nobody hired me for my output. If every company decides to let someone else do the training, nobody does it, and in a few years we’re all competing for the same shrinking pool of people who can tell when an agent is wrong, which is the skill I’m shortest of already.

What the tedious work was for

The part I didn’t say well in March is that this isn’t just “hire juniors like we used to”. The way people used to learn this job doesn’t happen by itself anymore.

When I think about how the good engineers I’ve worked with got good, a lot of it was work nobody wanted. Writing the fortieth CRUD endpoint, and noticing on the fortieth that the validation was the same each time and could be one function. Chasing a bug through four layers of code nobody had documented, and coming out the other side knowing how the system actually fits together. Writing tests for someone else’s module, which is the fastest way I know to understand it. That was the apprenticeship, and it was hidden inside the tickets.

That’s exactly the work agents are best at now. I’m not going to ask a junior to write the fortieth endpoint by hand for their education when a senior next to them is doing it in a sentence, and they’d be right to ask why. So the learning that used to happen by accident has to happen on purpose, and someone has to design it.

What we’re doing

Our first junior hire started in May and the second one started two weeks ago. Both came through the work sample we changed in 2023, where you extend a small working piece of code, talk us through it, and can use any tools you like. Out of a bit over 500 applications for the two roles, we did about 40 work samples, and the two people we hired were the two who were best at explaining why the code did what it did, which wasn’t the same as the two with the best code. One of the strongest solutions came from someone who couldn’t tell us why his agent had added a retry loop. He’s probably a good engineer. We didn’t find out.

For their first couple of months, the juniors are one notch to the left on our autonomy table from everyone else. On product code they can use an agent to explain things, to search, to answer “where does this happen”, and they write the change themselves. On tests and internal tools they can use it the same way everyone does. It’s a temporary rule, and I’ve told them so. I want the first few times they change our system to be times when they feel it resist.

The first exercise for each of them was the one I wrote about in 2012, adapted. Pick one real request, put a breakpoint at the front door, and follow it all the way through to the database and back, writing down every file it goes through. An agent could produce that list in thirty seconds, and the one it produced for me afterwards was accurate. What I wanted was the afternoon spent stepping through it, and the four or five “wait, why does it do that?” moments, which are where the questions for their mentor came from.

The other thing is how we review their work. Before a junior opens a PR, they walk their mentor through every line of it, out loud, including any lines an agent wrote. Our PR template already asks how a change was made, and that tells the reviewer where to look. The walkthrough is different. It’s there so the junior finds out which lines they can’t explain, which is most of the learning. It takes about half an hour for a typical change, and it’s the most expensive thing we do for them. The mentors were skeptical. One of them told me last week it’s also the best review his own code has had in years, because he started doing it for himself.

The worry

Back to “most leaned into the tools”. In July, our May hire fixed a flaky test with an agent’s help, on an internal tool where she was allowed to. The fix was a rescue around the call that was failing, which made the test pass every time, and also meant the tool silently skipped the records it couldn’t process. Every test was green. Her mentor caught it in the walkthrough because she couldn’t explain what happened to the skipped records, and she was a bit annoyed with herself, which is fine. That’s a normal junior mistake. I made versions of it for years.

What’s new is how fast it happened and how finished it looked. When I made that mistake in the early 2000s, I’d usually spent long enough on the bug to have some feeling that I was papering over something. She had a working fix in four minutes and no feeling at all, because she hadn’t spent any time with the problem. The tools take away the friction, and some of that friction was where people’s instincts came from. I don’t think anyone knows yet what replaces it. The walkthroughs are my guess.

What I told our CEO, eventually

The better answer, the one I gave him in June when he asked again, is that I’m not hiring juniors for what they produce this year, I’m hiring them so that in three years I have people who know our system well enough to review what the agents write. That’s the job I can’t fill from outside, because the knowledge is about our code and our customers, and it takes time in the codebase to get it.

I’m not certain it works. It might turn out that the judgment we need can be learned some other way, faster, and the walkthroughs and the breakpoint exercise will look as old-fashioned as learning assembly first. But if I’m wrong, I’ve spent two salaries on people who’ll still be good engineers. If the companies that stopped hiring juniors are wrong, they’re going to find out in about 2030, and there won’t be a quick fix for it.