Producing plausible code is now free, which has broken the interview, unsettled the job description, and quietly removed the bottom rung of the career ladder. Two of those are solvable. The third is the one that keeps me up, and I do not think the industry has an answer yet.
16 June 2026·10 min read
The obvious problem first, because it is the one everybody has already hit.
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, behavioural analysis, tools that watch for a second window. I think this is a mistake, and not on principle. It 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. That is a measurement failure, not a moral one, and the fix is to measure something else rather than to police the old measure harder.
Which requires being honest about what the job actually was, and here I think the industry has been quietly kidding itself for years.
Writing code was never the scarce skill. It was the visible one. It 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 artefact. 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.
So the honest description of what has changed is not that the job got easier. It 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 whole 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.
So what does good look like now. My working answer, which I use when writing a scorecard.
The single most valuable trait, and the hardest to fake. 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.
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.
The failure mode I watch for is the candidate who, when stuck, reaches immediately for another generation rather than 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.
This 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, not whether they wrote it.
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 rather than authored requires understanding it, and there is no faster way to find out whether the understanding is there.
There is one research result I would make every hiring manager read, and it is not about hiring.
In 2025, METR ran a randomised controlled trial on 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.
That gap is the important part, not the headline. It is a forty point swing 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. That 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 rather than collect an impression, which is the same discipline you would apply to any other claim and which hiring processes almost never apply to themselves.
What I have changed, concretely, in how the loop runs.
Banning them tests obedience and 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.
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.
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.
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.
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.
And now the part I do not have a tidy answer to, which is the reason I wanted to write this at all.
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.
Not all of that is AI. There was a hiring correction, an interest rate cycle, and a surge in the number of graduates. But the AI component is real and it has a specific shape: these tools are best at exactly the codified, well-bounded, previously-solved work that we used to hand to juniors. Not because it was valuable, but because it was safe, and because doing it was how they learned. We automated the training set.
Here is what worries me about it, and it is not a moral point about opportunity, though that argument stands on its own. It is a supply problem, and it is mine. In five years I will need senior engineers. Senior engineers are not manufactured by hiring senior engineers, they are grown, and the growth medium we used has been drained. Every organisation 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.
The best answer I have, offered without much confidence.
Seniority was never actually produced by writing the boring code. That 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 honest reason it will not happen widely. The old apprenticeship was cheap for the organisation 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 rather than 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.
The uncomfortable part is that 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. 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.