Is the coding interview dead?What the data says about AI, hiring and who sits closest to the revenue

An interview is a proxy. Nobody pays you to reverse a linked list. Companies asked because doing well on a hard puzzle used to predict doing well on the job, at least a little. That link weakens once a machine can do the puzzle for anyone.

In September 2025 the best university programmers in the world sat the ICPC World Finals: 12 problems, five hours. The best human team solved 11. OpenAI's system solved all 12.

The machines can. At that same contest, Google's Gemini 2.5 Deep Think solved 10 of 12, including one problem no human team solved. A month earlier, OpenAI placed sixth against human contestants at the International Olympiad in Informatics. Canva ran its own interview questions through AI tools and got correct, documented solutions in seconds, often with no follow-up prompt.

A test that anyone can pass with a second window open no longer separates candidates. Think of a mental arithmetic exam for accountants after the spreadsheet arrived. The skill still has value. The exam stopped telling you who the good accountants were.

Yet the market has barely moved. Interview Query analysed 59,738 technical interview reports from a fixed panel of 639 companies. Puzzles held flat. Among software engineers specifically, 52% of reports this year still mention them.

Leaders know the instrument is broken. In Karat's 2026 survey of 400 engineering leaders, 71% said AI is making technical skills harder to assess. Yet 62% still ban AI in technical interviews, while estimating that more than half of candidates use it anyway. Most companies are running a rule they expect most candidates to break.

Fraud makes it worse. In a Gartner survey of 3,000 job candidates, 6% admitted to interview fraud, either posing as someone else or having someone pose as them. Gartner predicts that by 2028 one in four candidate profiles worldwide will be fake. One student built a tool for passing coding interviews, says he used it on an Amazon interview, and then raised $5.3 million.

The companies that have acted are not dropping technical assessment. One group brings AI into the room and tests how you use it. The other takes AI out of the room and checks that you are real and know the basics. Some do both.

The two camps look opposed, but they share a concern. A team asking whether you can work with AI and a team asking whether you can work without it both want to know one thing: can you tell when the output is wrong?

“Our most impactful builders are successful regardless of how good they are at these tests.”

Notice also how few have removed coding altogether. The boldest move on this list covers a single team, and its author says he has not yet found the replacement. Rebuilding is the trend. Abolition is not.

Canva published what it now scores: whether you know when to use AI, how you break down a vague requirement, whether your technical decisions hold up, and whether you can find and fix problems in generated code. Its questions got messier on purpose. Instead of a textbook exercise, a candidate might be asked to build a control system for aircraft takeoffs and landings at a busy airport.

Its most useful finding is about who struggled. Candidates with little AI experience did badly, and the reason was weak judgment in guiding the tool rather than weak coding. The best ones asked clarifying questions about the product first.

Others are landing in the same place. Cerebras keeps the interview going after the first working version, into whether it was the right user problem, what should be tested and what breaks under load. Speak treats it as a red flag if a candidate cannot defend one design choice over an equally valid alternative. Luke Behnke, VP of product at Superhuman, reads candidates' AI prompt chains and puts it simply: "What's important to me is, why did they do that?"

The answer has become cheap. The reason behind the answer is what employers now pay to see. Anthropic found the same shift when it analysed its own interview scorecards: comments on autonomy and judgment rose the most, while domain expertise shrank as a share of the discussion.

The labour market is buying judgment too, mostly by buying seniority. A Harvard and INSEAD working paper compared AI-native startups with similar non-AI peers across thousands of firms.

The pattern repeats in the jobs data. Stanford's Digital Economy Lab, using ADP payroll records, found a 13% relative employment decline for workers aged 22 to 25 in the most AI-exposed jobs. The New York Fed puts unemployment among recent computer science graduates at 7.0%, against 5.6% for all recent graduates. Anthropic reports the junior share of its technical hires falling from 27% to 9%, though its technical hiring grew overall. When I went through seven years of jobs data last month, 71% of the rebound in US developer postings had gone to senior roles.

Follow the logic to its end. When building something costs little, the scarce decision is which thing to build, and the honest test of that decision is whether it makes money.

This idea is old. In 2011 Patrick McKenzie wrote that engineers are hired to create business value, and advised them to attach themselves to the parts of a company that make money. What has changed is the leverage behind that advice.

An agent is AI software that carries out a multi-step task by itself. The clearest measurement I have seen of what agents do to a team comes from telemetry inside an AI lab. By August, the agents Anthropic staff directed were logging six hours for every human hour, and those sessions sat idle about 80% of the time, waiting for a person.

When agents spend 80% of a session waiting for a person, that person's speed and quality of decision set the pace of the whole system. A fast, correct call is now worth more than a fast pair of hands, and you can see that in what each person now earns for their company.

Treat that with care. Revenue is not profit, and compute is expensive. Not every AI company looks like this either: on the same estimates, Glean and Synthesia sit near $200K. The narrower point holds. Where one person directs far more output, a good or bad decision travels further.

You can see the money moving toward the customer. The clearest signal is the forward-deployed engineer, or FDE: an engineer who sits with the customer, works out the real problem and ships the fix into production. The distance between that person's code and revenue is close to zero.

This is not only a US story. Indeed reports FDE postings in India up nearly 19-fold year on year. Fortune, citing Lightcast, puts the median advertised US salary above $188,000.

I see the same pull in my own company. IdeaBoxAI runs forward-deployed engineering alongside platform and delivery, and my delivery team ring-fences about a quarter of its capacity for pre-sale work. An engineer in a pre-sale room learns quickly which problem a customer will pay to solve. This year I also ran HackIndia in Chennai for about 300 students, and the evaluation afterwards gave us a ranked pipeline of candidates for forward-deployed roles. I trust that signal more than a puzzle score.

I started with a simple hypothesis. Product managers sit closest to the decision and the revenue, so product managers win. The data does not support that as stated.

The case for it is real. TrueUp data published by Lenny Rachitsky shows more than 7,300 open PM roles, the highest in over three years, with AI PM openings up 465% from their low. Andrew Ng argues that faster coding moves the bottleneck to product decisions, and he has described a team proposing one PM to half an engineer.

The case against is just as real. Live Data Technologies figures show PM headcount at US tech companies 28% below its 2022 peak, with VP-level PMs down 38% and directors down 35%. PM openings are up 75% from their low, but engineering openings are up 78% over the same span. AI-native startups carry about 15% fewer managers than their peers, and at Anthropic there are about 17 engineers per PM, a ratio that is still rising. The US Bureau of Labor Statistics has no product manager category. Its closest, project management specialists, is projected to grow 6% over 2024 to 2034, against 15.8% for software developers.

The title does not pay. Three things held together do: you decide what gets built, you sit close enough to revenue to know whether the decision was right, and you can build it yourself with AI. Ng lands in the same place. His advice to PMs on LinkedIn is to learn to build.

The reward for sitting in that top-right box is speed. A PRD, or product requirements document, was the old way to buy a decision: write it, win support, wait for a slot. A working prototype now buys the same decision for less, and anyone close to the problem can make one.

I felt a version of this in October, when an AI agent wrote 10,578 lines of WebAssembly in 26 hours and shipped a 3D game in 40 KB. The typing was the cheapest part. What to build and how to check it were the expensive parts, and that is what I would want an interview to probe.

The puzzle may be surviving for a reason. Thirty percent of reports is not a rounding error. Puzzles are cheap, consistent and easy to defend, and a large employer may rationally keep one in a supervised room to check fundamentals. Google's move points that way.

Fundamentals may matter more, not less. In an Anthropic randomised study of 52 mostly junior engineers, those learning a new library with AI scored 50% on a follow-up quiz, against 67% for those coding by hand. The largest gap was in debugging, which is the skill you need to supervise an agent. So I would change the format of the fundamentals check. I would not drop it.

AI productivity on real code is contested. In METR's randomised trial of 16 experienced open-source developers on 246 real tasks, early-2025 AI tools made them 19% slower, while they believed they had been 20% faster. Tools have improved since. The gap between felt and measured speed should still worry anyone reporting productivity to a board.

Developers do not trust the output. In the Stack Overflow 2025 survey, 84% used or planned to use AI tools, yet 46% distrusted their accuracy against 33% who trusted it. Only 3% trusted it highly.

Many of these sources have a stake. Karat sells technical interviews and Interview Query sells interview preparation. OpenAI and Google reported their own contest results. Anthropic sells the tool it measures, and its data covers one unusual company. I am CTO of an enterprise AI company with a forward-deployed team, so this thesis flatters my market too. Weigh it accordingly.

For hiring leaders. Retire the remote, unaided puzzle. In its place I would run three checks. First, an in-person session reading and debugging unfamiliar code, because that is the supervision skill. Second, an AI-allowed build on a real product problem. Third, a decision round: here is the business goal, what do you build first, what do you cut, and how would you know it worked?

For engineers. Keep practising puzzles while your target companies still ask them, because many will for a while yet. Then find out what your manager's manager is measured on, and build one idea over a weekend that moves that number. Get in front of a customer as often as your role allows.

For product managers. Learn to build. Bring a working prototype to the decision instead of a document. Own a number that finance also tracks.

For juniors. The door is narrower, and I will not pretend otherwise. But Rieseberg’s argument is the most hopeful one I found: impact is “less bounded by how many years of accumulated knowledge in frameworks and libraries you’ve gathered,” and he is seeing newer engineers “fly past people who are probably better coders.” His summary is “Hunger beats tenure.” Debug by hand while you learn, because that is the skill the AI group lost in the study above.

His practical advice, which I would follow: learn what your manager’s manager is measured on, pick one radical idea that would move it, and build a prototype over a weekend that communicates that single idea. A working prototype skips the product requirements document, the lobbying and the wait for permission, because, as he puts it, “Execution isn’t expensive anymore.”

The coding interview is not dead, but the puzzle no longer tells you much. The interview that replaces it asks a harder question: can you decide what is worth building, get AI to build it, and prove it is right? The closer that decision sits to revenue, the more it pays.

If you hire engineers, try this tomorrow. Paste your favourite interview question into an AI assistant. If it answers well, ask yourself what that round is still measuring.