AI Is Forcing Employers to Rethink Coding

Anthropic engineering manager Felix Rieseberg says he has stopped using traditional coding interviews. His example is a small React task: if an AI model can complete it better than a candidate, what does asking the candidate to do it reveal?

That question hits a familiar hiring ritual. Give someone a tightly bounded problem, start a timer, watch them write code, then use the result to predict how they’ll perform on a team. Rieseberg’s decision concerns his own interviews, not a declared company-wide Anthropic policy. But the challenge extends well beyond one manager’s calendar: when a tool can produce the answer to a test, employers have to decide whether the answer was ever the skill they needed to measure.

I’d keep one distinction in view. A model completing a small React exercise says little by itself about how a candidate handles a product requirement that changes halfway through, an unfamiliar codebase or a bug that appears only after deployment. Nor does a candidate’s inability to beat the model on speed make them a weak engineer. The hiring question is what that person can understand, decide and check when the code arrives quickly, whether they wrote it or an AI did.

The Old Test Had a Job

Traditional coding exercises offer something employers understandably want: a common task with a visible result. A hiring team can ask several candidates the same question, set the same time limit and compare their approaches. Watching someone work can also reveal whether they can explain a decision, notice a mistake and recover from it.

Those are advantages over hiring by résumé alone. A polished application can’t show how someone thinks at the keyboard. An interviewer who asks only conversational questions may reward confidence or shared vocabulary instead of technical ability. The strongest case for retaining a coding exercise is straightforward: a team still needs to know whether a prospective engineer can read and change code without treating every AI suggestion as a trusted instruction.

The trouble begins when the exercise becomes a stand-in for the whole job. A short puzzle rewards performance under an artificial clock. A tiny React component rewards knowledge of a narrow framework pattern. Software work also includes figuring out what a request means, tracing failures across existing systems and making changes colleagues can maintain. If AI removes the difficulty from the bounded task, the test may leave employers with a crisp score for an increasingly small slice of the role.

That doesn’t mean every coding question belongs in the bin. It means the interviewer needs to name the skill each question is supposed to expose. If the answer is “can produce this component from scratch in 30 minutes,” Rieseberg’s comparison puts pressure on that choice. If the answer is “can identify why this component fails and explain a safe fix,” the same code might support a more useful conversation.

Give the Candidate a Decision, Not Just a Blank Editor

Consider a hypothetical interview built around a small application with a failing test. The candidate can inspect the code, ask questions and propose a fix. The interviewer can then change one requirement: the fix must also preserve a behavior the first attempt overlooked. The result is still concrete code, but the interviewer now sees how the candidate diagnoses a problem and reacts when the easy answer stops working.

An AI-assisted version could allow the candidate to use a model and ask them to review its output. What assumptions did the model make? Which test would the candidate run before accepting the change? What would they tell a teammate reviewing the pull request? That format tests direction and verification alongside implementation. It also resembles a plausible day at work more closely than asking someone to race a chatbot through boilerplate.

Tool use can become a proxy for performance. A candidate who knows the quirks of one model might look smoother than a careful engineer who has used a different tool or none at all. Employers can reduce that mismatch by telling applicants in advance whether AI is allowed, offering the same setup to everyone and judging the reasoning they can explain rather than the elegance of a generated first draft. The interviewer still needs to understand the task well enough to spot an answer that sounds convincing but breaks the application.

This is an extension of the problem facing AI-assisted hiring more broadly. When tools help people polish résumés and complete assessments, the visible artifact gives employers a thinner view of who made which decisions. A live follow-up can restore some signal, provided it probes the work instead of turning into a surprise ban on tools the employer expects people to use later.

Watch the Failure, Not Only the Finish

A finished solution tells a hiring team whether the task got done. The route to it can expose more. Did the candidate reproduce the bug before editing? Did they check an edge case after making the obvious fix? Could they explain what would happen if their assumption about the data were wrong? Those questions give an interviewer observable behavior to discuss rather than a gut feeling about whether someone “seemed senior.”

Debugging also offers a way to test fundamentals without pretending AI assistance doesn’t exist. A small Anthropic study of junior developers found weaker coding-quiz performance among AI users, particularly on debugging. That finding raises a practical hiring concern: if a person can generate a patch but can’t locate the fault when it fails, the team may inherit the problem after the interview. An assessment that includes diagnosis can check for that ability directly.

The exercise needs limits, though. Handing a candidate an enormous unfamiliar repository and asking them to “figure it out” may resemble work in the least useful way: all setup cost, little opportunity to show judgment. A compact, documented task with a clear evaluation rubric gives the interviewer something to assess and the candidate a fair shot at demonstrating it. Employers should also decide whether they are testing independent coding, AI-assisted work or both, then tell candidates before the timer starts.

A Better Interview Still Has to Be Fair

Replacing one standardized exercise with an open-ended conversation can make hiring less consistent. Different interviewers may chase different tangents. Candidates who talk quickly may appear stronger than candidates who pause, investigate and then give a precise answer. A vague request to “design something interesting” can reward familiarity with an interviewer’s favorite systems rather than the requirements of the job.

A practical replacement could combine short stages: inspect a defined piece of code, make or describe a change, test a failure case and explain a trade-off. Interviewers can use the same prompts and scoring criteria for everyone while allowing more than one reasonable solution. They can record whether the candidate identified the constraint, checked their assumptions and communicated the risk. None of that requires a six-hour take-home project from someone who has already spent time applying.

The job itself should set the mix. A team hiring someone to maintain a mature product may learn more from a debugging task than a blank-file algorithm challenge. A role that demands low-level implementation may still need an exercise where the candidate writes code unaided. If a team uses AI daily, banning it throughout the interview hides how the candidate would use it. If the role requires someone to handle an outage when tools are unavailable, an independent reasoning segment has a purpose too.

Rieseberg’s React example leaves employers with a sharper design question than “Are coding interviews dead?” They can keep the code, the clock or the AI tool if each reveals something they’ll need from the hire. The test earns its place when an interviewer can point to a candidate’s decision and say how that decision would matter after the offer letter is signed.