Coding Interviews Are Dead

If AI takes the traditional coding interview out the back and buries it six feet under, I’ll happily lend it a shovel.

Of all the things this technology might destroy, asking an experienced developer to traverse a binary tree while someone watches them through a webcam is pretty low on my list of things to mourn.

Build this component. Implement this sorting algorithm. Explain every line while a stranger silently judges how long you take to remember a method name. Congratulations, you’ve passed the technical round for a job where half your problems will involve figuring out what somebody meant by the word customer.

I think that interview is dead. Companies will keep administering it, obviously. Companies still fax things. But its usefulness as evidence that someone can do the job is getting harder to defend.

AI can do the homework

Claude Opus 5.5, GPT-6 Astra and coding models such as Cognition’s SWE-2 are built to handle work far beyond a self-contained interview exercise. Generating a component, implementing a familiar algorithm and producing a convincing explanation of the code are comfortably within the territory these tools cover.

They can also get things wrong. I’m not claiming every generated answer beats every human answer. You don’t need that claim for the interview to have a problem. A test loses a lot of value when the candidate’s everyday tools can produce the thing you’re using to measure the candidate.

The explanation doesn’t rescue it either. Asking someone to explain generated code can tell you whether they understand it, if you probe properly. Accepting a tidy walkthrough as proof they could independently solve the problem is a much bigger leap. AI can write the walkthrough too.

So the employer bans AI. Close your other windows. Share your entire screen. Turn on your camera. Prove that you, unaided, can do something we’ll give you a paid tool to do once you start working here.

Lovely. We’ve turned recruitment into an exam invigilation business.

I understand wanting to know whether someone has technical foundations. I’d want to know that too. But if the job involves working with coding agents, deliberately removing them from the assessment leaves a fairly large hole in what you’re assessing. You never see whether the candidate gives the tool useful context, notices a bad assumption or accepts a confident answer without checking it.

The job was always bigger

The most useful skill a developer could have was always understanding what a business needed and turning that into something people could agree on and build.

Developers, designers, product teams and executives can sit in the same meeting, hear the same sentence and leave with four different ideas of what was agreed. Somebody has to notice before there’s a working application demonstrating all four misunderstandings.

That work takes patience. It means asking the awkward follow-up question when everyone else is nodding. It means explaining a technical limitation without making the person asking feel stupid. Sometimes it means telling an executive that their urgent feature will create more work for the people who have to use it.

You could be excellent at that and terrible at performing algorithms under observation. You could also memorise enough interview questions to sail through the process and then spend your first month building exactly what was written in a ticket without once asking why.

AI makes that second approach much faster.

Consider a hypothetical business asking for a dashboard because invoices are getting paid late. A developer can now generate charts, filters and a very respectable-looking table before anyone has established why the invoices are late.

Maybe customers never received them. Maybe the invoices went to the wrong contact. Perhaps the accounts team already has a report and needs a way to follow up without opening twenty browser tabs. Another dashboard could become one more place to look at the problem while doing absolutely nothing about it.

I’d want the person interviewing for the job to ask how an invoice gets sent. I’d want them to speak to whoever chases payment. Finding out that the requested dashboard won’t help is a useful outcome, even if there’s nothing colourful to demonstrate at the end.

Good developers did this before AI. I don’t think we’ve discovered a new profession because a chatbot learnt TypeScript. I think we’re running out of excuses for treating this part of the profession as optional.

Product engineers

I think a lot of application developers are heading towards the title product engineer. Some already use it. Soon, calling yourself a software engineer might tell an employer less about your job than explaining which product you take responsibility for.

The title itself doesn’t excite me. Recruiters will ruin it shortly. Somewhere there’s probably already a job description asking for ten years of experience with a product that launched on Tuesday.

The responsibility interests me. A product engineer should understand the problem well enough to question the proposed solution, help build it and care whether it works for the people using it. That includes the boring bits after the demo, when a customer imports an unusual spreadsheet or a member of staff tries to undo yesterday’s mistake.

Technical knowledge belongs in that job. Knowing how authentication works, how data can be lost and why a page is slow gives you a better chance of catching an agent’s mistakes. Being able to read the code still helps enormously. You can’t take responsibility for a system by repeatedly asking the thing that wrote it whether it’s happy with itself.

But the business doesn’t get much value from your ability to type a component from memory if the component shouldn’t exist.

When implementation gets cheaper, choosing what to implement deserves more attention. Otherwise you can spend your newfound productivity building an impressive quantity of unnecessary software. Then you get to maintain it. What a treat.

I also don’t want product engineer to become an excuse to make one person do five jobs for the same salary. You still need design expertise and people who understand operations. Having a broader understanding of a product should make collaboration easier. It shouldn’t mean the company fires everyone you were supposed to collaborate with.

The plumber can build an app

I know electricians and plumbers who are building things with AI despite having zero coding knowledge.

That still makes me stop for a moment. Three years ago, I wouldn’t have imagined people I know going from no programming experience to building their own software this way. Yes, no-code tools existed. This feels different when someone can describe what they want, try it, complain about what it did and keep changing it through a conversation.

Their software might have problems. It might be ugly. They might need help before trusting it with anything important. None of that makes the change less remarkable.

And they know things about their work that a developer doesn’t.

Take a hypothetical scheduling app for a trade business. A developer might start with a calendar and available time slots. A tradie might immediately ask how it handles a job running over, a part that hasn’t arrived or a customer who won’t be home until after lunch. They’ve lived with the inconvenience the application is supposed to remove.

They can now get much further with that knowledge before paying someone to translate it into code.

I find that exciting. I also think developers should pay attention to what it does to the value of a prototype. Turning up with a working demo used to establish that you could get past a fairly substantial technical barrier. Now the demo starts a longer conversation about whether you’ve understood the work and whether the software survives contact with it.

An experienced engineer can still contribute a huge amount. Help the person protect their customers’ data. Work out why their app loses changes. Make it possible to recover when something breaks. There are plenty of useful things to do without being offended that someone got the first version working without us.

The org chart needs work

Companies need to reconsider how they’re organised around all of this. Hiring a product engineer and then making them wait three weeks for permission to try something seems a fairly efficient way to waste the opportunity.

A lot of software organisations have built their routines around expensive implementation. Layers of middle management, planning meetings, estimates, another meeting to discuss the estimates. Committing to a feature could mean tying up a team for weeks or months, so deciding what to build carried a substantial cost.

Some of that planning made sense. Some of it was a meeting that had learnt to reproduce.

When a piece of work can take hours or days, the balance changes. You can spend longer seeking approval for a prototype than it would take to build it and put it in front of somebody. By the time the planning document gets its final comment, a small team with permission to get on with it could already have found out whether the idea works.

Even a junior developer with a Claude Code subscription, a detailed spec and enough autonomy could get surprisingly far in a system they don’t fully grasp yet. The agent can help them trace unfamiliar code and attempt an implementation while they’re still learning how the pieces fit together.

Will it be perfect? Of course it won’t. A more experienced engineer will spot things they’ve missed. There might be an assumption about permissions, an expensive query or a dependency the junior didn’t know existed. Give that engineer time to review the work and explain the problem. A junior having something substantial to discuss is a useful starting point for learning.

The detailed spec also has to come from somewhere. Someone needs to resolve the ambiguity, understand the constraints and decide what success looks like. That’s work. But a company can put its experienced people into that work, and into reviewing changes, without requiring their permission for every small experiment.

I wouldn’t give a junior unrestricted production access and wish them luck. I’d give them a safe place to build, a clear boundary and someone available when they get stuck. There’s an enormous amount of room between supervising every keystroke and letting an agent make irreversible decisions about customer data.

The speed of progress possible inside those boundaries is ridiculous. Companies should be looking at which approvals protect something and which ones merely keep work waiting. If the implementation takes an afternoon and the approval takes a fortnight, there’s probably a more useful discussion to have than whether the developer can type any faster.

Give them a messy problem

If I were hiring an application developer now, I’d give them a small, deliberately incomplete business problem and let them use AI.

For example, a booking system lets two people reserve the same appointment. Staff want a warning. The owner wants fewer complaints. A candidate gets a small existing application, some sample data and enough context to ask questions. Everybody gets access to the same tools, so the interview doesn’t become a competition over who can afford the most expensive subscription.

I’d be interested in what they do before changing the interface.

A warning might help someone notice a clash. It might also do nothing to prevent two requests arriving together. I’d want to hear the candidate investigate where bookings are accepted and which rules the server enforces. If they don’t know, they can use documentation or ask the agent to help trace it. Watching them find out is useful.

They can build a fix with whatever assistance is available. Then I’d ask them to demonstrate how they checked it. Two browser tabs are a start. A test that sends competing requests tells me more than a screenshot of a new warning banner.

During the exercise, I’d introduce a reasonable change: staff sometimes need to override the booking restriction. Now there’s a question about permission and a record of who made the exception. Does the candidate ask which staff? Do they explain the consequences to the owner? Can they make a modest change without letting the agent redesign the entire application?

An unfinished implementation with sensible decisions could tell me more than a polished solution that misses the problem. I wouldn’t mark someone down for asking questions I’d deliberately made necessary.

There’s still code in this interview. There’s also an explanation. The discussion has something concrete to test, though. When the candidate says duplicate bookings are prevented, we can try to create one. When they say only managers can override the rule, we can sign in as someone else.

I want to see what they do when their first answer is wrong. Do they investigate, or do they defend it because the model sounded certain? Can they explain the remaining limitation in plain English? Would I trust this person to tell me a feature needs another day?

For a junior, I’d scale the task down and help more. I’d look for learning and reasonable questions, without expecting the business judgement of someone who’s spent fifteen years cleaning up other people’s decisions. We still need ways for people to gain experience. Declaring every vacancy senior and then complaining about a skills shortage is a fairly stupid plan.

Keep the exercise short. If it needs several hours, pay for the time. And use a made-up problem. A hiring process shouldn’t be a convenient way to clear your backlog using people who need a job.

Humans wrote slop too

Whenever this discussion comes up, someone points out that AI produces broken or insecure code.

It does. I’ve got no interest in pretending otherwise. Generating more code also gives you more code to inspect, and a careless developer can use an agent to spread a bad decision across a repository very efficiently.

But humans were writing slop long before AI existed. The internet didn’t enjoy decades of flawless software before ChatGPT arrived and ruined everyone’s impeccable engineering standards.

Look at this month’s PHP security releases. PHP’s October announcements describe fixes for CVE-2026-109618 and CVE-2026-109619, critical vulnerabilities that can allow unauthenticated remote code execution. Software people depend on can contain serious defects, even with experienced maintainers working on it.

A vulnerability isn’t automatically evidence of careless work, and those advisories don’t establish who or what wrote the affected lines. I’m not going to use them to insult PHP’s maintainers. They do make the fantasy of inherently safe software rather difficult to sustain.

Human authorship has never been a security guarantee. Neither is a model’s confidence. We need review and testing whichever way the code arrives, and somebody has to understand enough to decide what those checks should cover.

That’s a much more useful hiring conversation than asking a candidate whether they can reproduce a sorting algorithm. Give them a plausible implementation with a permissions mistake. See whether they notice. Let them use an agent to review it, then ask how they checked the finding. A list of possible vulnerabilities copied from a chat window isn’t much help if they can’t establish which ones apply.

Leave the whiteboard alone

I’m happy to see algorithm puzzles lose their place as the entrance exam for ordinary software jobs. Algorithms themselves are doing fine. AI can help discover them now: Google’s 2026 AlphaEvolve update describes algorithm improvements used in its infrastructure, alongside work on scientific problems.

There’s something funny about insisting a person recite an algorithm to prove they’re qualified to use tools that can help develop new ones.

If you’re hiring someone to work on database internals or compilers, assess the knowledge that work requires. I’d expect the interview to be technical. For a job building business applications, I’d rather spend the available time on the decisions that person will have to make on a Tuesday afternoon.

Can they tell when a requirement contradicts another one? Can they explain why a seemingly small change risks losing data? Will they talk to the person using the software before generating six thousand lines of code on their behalf?

Those abilities were valuable when implementation took weeks. They’re going to be harder to ignore when implementation takes an afternoon.

I’d be quite happy to end an interview with a candidate telling me the feature I requested shouldn’t be built. Provided they could explain the problem, show me what they’d checked and suggest something smaller that would help, I’d have plenty to talk to them about. They might even save their future colleagues from another dashboard.