Where Do Seniors Come From?

The technical interview no longer measures what it was built to measure. The take-home is the clearest case: one interview platform reported that around eighty percent of candidates used a model to complete a coding exercise after being told explicitly not to, and figures from vendors running interview software suggest something approaching half of technical candidates are flagged for some form of assistance. Treat the precise numbers with suspicion, because the companies publishing them sell the detection, but the direction is not in dispute and it matches what anyone running a loop has seen for themselves.

The standard response has been detection: proctoring, screen monitoring, behavioral analysis, tools that watch for a second window. I think this is a mistake, and not on principle. Detection is a mistake because it is an arms race against a commodity, run by hiring teams against candidates who have more time, more motivation, and better tooling. You will lose it slowly and expensively while making the experience worse for the honest majority.

The deeper issue is that the take-home was always a proxy. We never actually cared whether someone could implement a rate limiter over a weekend. We cared what that implied: that they had absorbed enough practice to produce working software unsupervised. The proxy has stopped implying the thing, which is a measurement failure and not a moral one, and the fix is to find a different measurement, since policing the old one harder changes nothing.

Writing code was never the scarce skill. It was the visible one. Writing code is what shows up in a commit, what a manager can point at, what an interview could test in forty five minutes, and so we built an entire hiring apparatus around it and then mistook the apparatus for the job.

The scarce parts were always the ones that leave no artifact. Knowing which of three plausible designs will still be maintainable in four years. Noticing that a requirement as written cannot be satisfied and going back to ask. Reading an incident graph and forming the right hypothesis first rather than fifth. Deciding that the correct amount of work here is none. I have never been able to test any of that in an hour, which is precisely why we all tested typing instead.

The job did not get easier. What has changed is that the free part got cheaper and the expensive part did not move at all. If anything the expensive part got more valuable, because there is now vastly more plausible output in the world requiring judgment about whether it is correct.

That is the shift in one sentence: the bottleneck moved from production to verification. And verification is harder than production, which is a thing every experienced engineer knows and every hiring process has ignored, because for twenty years we selected for the ability to write and simply hoped the ability to review came along with it.

They can tell when the output is wrong. Given confident, well-formatted, subtly incorrect code, do they notice, and how long does it take. Confidence and correctness have been decoupled by these tools in a way they never were with a human colleague, and an engineer whose calibration comes from "it looks like it was written by someone who knew what they were doing" is now actively dangerous.

They ask what problem this is solving. More important than it has ever been, because the cost of building the wrong thing has fallen and therefore the volume of wrong things has risen. When implementation was expensive, the expense itself forced a conversation before the work started. That brake is gone. The engineer who still stops to ask is now supplying something the process no longer supplies on its own.

They debug from evidence rather than pattern. The failure mode I watch for is the candidate who, when stuck, asks for another generation and never for another hypothesis. Debugging is the one part of this work where you cannot bluff, because reality is holding the answer and does not care how plausible your explanation is. It remains the best signal I know of.

They can hold responsibility for work they did not type. The capacity is new and I think it is underrated. Reviewing and shipping machine-generated code is a genuinely different relationship to ownership, and some very good engineers are bad at it, because their sense of responsibility was tied to authorship. What matters is whether they will defend it in an incident review.

They can explain it to someone who is not technical. Unchanged from ten years ago, and I mention it only because it now filters more strongly than it used to. Explaining a system you assembled and did not author requires understanding it, and there is no faster way to find out whether the understanding is there.

In 2025, METR ran a randomized controlled trial. The subjects were experienced open-source developers working in repositories they knew well. The developers using AI tools completed their tasks about nineteen percent slower. Afterwards, the same developers estimated that the tools had made them roughly twenty percent faster.

The headline number matters less than the gap underneath it. The swing is forty points between measured and perceived productivity, in skilled practitioners, on their own code. Two caveats belong here and I will give them properly: it is a small study, sixteen developers, and METR themselves have since said the result should be treated as historical and are redesigning the experiment, because the tools have moved considerably since early 2025. I would not use it to argue that AI makes engineers slower today. I do not think that is true.

I would use it for something narrower and more durable. Human beings, including expert ones, cannot introspect their own productivity when a tool is in the loop. It feels fast because the waiting is filled and because output appears. The feeling is not evidence.

The hiring consequence is direct. Every self-report you will hear in an interview about how someone works with these tools is unreliable, and so is your interviewer's impression of how effectively a candidate used them in an exercise. If you want to know something, you have to measure an outcome instead of collecting an impression, which is the same discipline you would apply to any other claim and which hiring processes almost never apply to themselves.

The tools are allowed, and that is stated up front. Banning them tests obedience. It measures nothing about the job, since the job permits them. Saying so also removes the ambiguity that makes honest candidates anxious and dishonest ones comfortable. The exercise assumes assistance and is built to be hard anyway.

Bring something broken, not something empty. The strongest exercise I have found is a small real codebase with a real defect and a failing test, where the fix requires understanding why rather than what. Generation helps far less than candidates expect. Comprehension is the bottleneck and comprehension is what we are hiring.

Review, do not write. A pull request full of generated code with two subtle problems in it, and the question is simply: ship it or not, and why. This maps directly onto what the work now is, it is fast to run, and the spread between candidates is wider than on any writing exercise I have used.

Ask about a decision they reversed. Not a failure, a reversal. It requires them to have held a position, to have noticed evidence against it, and to have changed. That combination is rare and I have never found a way to fabricate it on the spot.

Watch how a candidate talks through the code. Live, with screen sharing, and interrupt. Ask why that line. Ask what happens if the input is empty. The cheating playbook collapses under questions, and more importantly, so does shallow understanding, which is the far more common problem and the one that was always there.

The entry-level market has not softened, it has fallen through the floor. SignalFire's analysis puts hiring of people with under a year of experience down by roughly two thirds at large technology companies against 2019, and worse at early-stage startups. New graduates have gone from around a third of big-technology hires to something in the region of seven percent. Unemployment among computer science graduates has been running near double the rate of many other degrees, in the field that spent a decade telling everyone it could not find enough people.

That baseline is doing less work than it looks like. 2019 sits immediately before a pandemic, a move to distributed work, a hiring boom, a correction, and a rate cycle, and the tools only turn up for the last stretch of it. The number measures the size of the hole and says nothing about what dug it.

What AI adds is a specific shape. These tools are best at exactly the codified, well-bounded, previously-solved work that we used to hand to juniors. We handed it over because it was safe, and because doing it was how they learned. We automated the training set.

And the move out of the room took the other half of the same apprenticeship: the overheard conversation, the question cheap enough to ask out loud, the senior engineer noticing what you had got wrong before you knew to ask. Only one of those two gets blamed for the collapse in junior hiring. Both drained the same medium, which is why I would not file this under AI and leave it there.

Here is what worries me about it. The moral point about opportunity stands on its own; my own worry is a supply problem. In five years I will need senior engineers. Senior engineers are grown, and the growth medium we used has been drained. Every organization currently declining to hire juniors is making a locally rational decision that is collectively suicidal, and the bill does not arrive during the tenure of whoever is making the decision.

Seniority was never actually produced by writing the boring code. Producing it that way is the assumption underneath the panic and I think it is wrong. It was produced by consequences: owning something that real people used, being wrong in a way that mattered, and being present for the repair. The boring code was just the vehicle that carried a junior into contact with consequences slowly enough to survive them.

If that is right, then the vehicle can be replaced, and it is now cheaper to replace than it has ever been. Give a new engineer ownership of a small real service in their first month rather than their second year. Put them on call for it, with support. Have them review machine-generated changes from the first week, because review is the skill and there is no longer any reason to withhold it until they have earned it by typing. Let them make decisions that can be wrong, inside a blast radius you have deliberately made small.

That is more work for the people around them than handing over a ticket queue was, which is the reason it will not happen widely. The old apprenticeship was cheap for the organization because it was passive. This one requires senior attention, which is the scarcest thing in any engineering group. I do not think that makes it wrong. I think it makes it a real cost that has to be argued for and never assumed, and the argument is not "juniors are cheaper", because they are not any more. The argument is that in five years you will either have senior engineers or you will be trying to hire them from a market where nobody else grew any either.

So what does a good engineer mean now. Roughly what it meant before, with the emphasis moved: judgment over production, verification over generation, and the willingness to own an outcome regardless of who or what produced the work.

This is the definition experienced engineers always privately used, and we simply never had to make it explicit because the old proxies did an adequate job of selecting for it by accident, and they do not any more. We now have to say out loud what we are looking for and build a process that actually looks for it, which is harder, and is also just the job we should have been doing all along.