Evidence at a glance
A Test Has Been Dropped, Not Engineering Itself
Felix Reiseberg, a hiring manager at Anthropic, says that this month he stopped asking candidates to take traditional coding interviews. His reason is that Claude is now better at both small React challenges and assembly questions, making it harder to infer from a timed exercise whether someone will be effective as an engineer. This is Reiseberg’s change to his own hiring practice. The material does not say that Anthropic has adopted a company-wide policy of removing coding interviews.
The change matters not because it declares that engineers no longer need to write code, but because it puts the predictive value of hiring assessments in question. An interview exercise uses a short task to estimate how a candidate might perform in a role. When a model can take on more tasks of the same kind, that estimate may become weaker. Technical leaders need to ask whether an interview measures the abilities the job actually requires, or merely a familiar skill that is easy to score.
Why a Coding Exercise Can Become a Weaker Signal
Traditional coding exercises are not without value. They can show how a candidate breaks down a problem, organizes code, and produces an implementation under time pressure. But they compress ability into a particular setting: the interviewer defines the task, and the usual goal is to reach an acceptable answer quickly. Real engineering work may instead begin with an unclear objective, conflicting requirements, or a poor user experience. The engineer first has to decide what the problem is.
Models make the distance between producing code and making a valuable engineering contribution more visible. Reiseberg says he has seen highly impactful builders who were not good at these tests. That is an individual manager’s experience, not systematic evidence, and it does not prove that coding exercises fail for every role. It does warn teams against treating test performance as a direct substitute for job performance. The easier a model can complete an exercise, the more important it becomes to ask whether the exercise still distinguishes candidates, or mainly distinguishes familiarity with the test format.
Shift the Assessment Toward Choosing the Problem
Reiseberg’s advice to junior engineers helps explain the assessment he wants to value instead: shift attention from clearing the backlog to business impact. Engineers are hired to create business value, not simply to write programs. Candidates therefore need to understand what their organization is trying to achieve and propose a small number of ideas that could materially improve the outcome if they succeed. The test is not whether an idea sounds grand, but whether the candidate can connect a technical action to a real objective.
This also changes what initiative means. It is not just taking on more tasks. It is noticing a problem that the existing task list does not express well, then accepting responsibility for deciding how to address it. For junior employees, that ability may draw on direct observation of a product. As users or recent arrivals to a team, they may be more likely to notice friction in the experience. Reiseberg sees this fresh perspective as an advantage, but it still needs to be demonstrated through a specific problem and evidence. It should not be assumed from a generalization that younger people understand users better.
A Weekend Prototype Can Bypass Process—and Blur Boundaries
Reiseberg recommends building one good idea into a prototype over a weekend. He has seen small groups or individual engineers use a working artifact to get past the usual sequence of writing a product requirements document, seeking buy-in, and waiting for product or design resources. A prototype turns an abstract claim into something people can discuss. It can help a team see the problem, a possible implementation, and its potential value earlier. This approach also fits a world where models reduce development costs: when an initial implementation is faster to produce, an idea is easier to show and examine.
But a prototype is not neutral hiring evidence. It may favor candidates with more free time, equipment, or relevant background. It may also cause presentation skills or familiarity with an organization’s context to be mistaken for engineering judgment. The material does not claim that these biases have already appeared in Anthropic’s hiring. They are risks any team needs to address before adding prototypes to interviews. Employers should define scope, expected time, and evaluation criteria, rather than disguising an expanding unpaid project as a test of initiative.
A Good Prototype Narrows the Question, and Hiring Criteria Should Too
A prototype’s persuasive force does not come from how many features it contains. Reiseberg specifically warns that junior employees can cram multiple ideas into one project, leaving a few strong directions hidden among twenty weaker ones. Focusing on one idea makes it easier to see how a candidate defines the problem, chooses a scope, and decides what deserves further investment. For the interviewer, the emphasis should be on those decisions and the reasons behind them, not simply on how complete the finished prototype looks.
This does not mean every role should drop coding questions or replace them with a weekend project. When work involves debugging complex systems, understanding code constraints, or reviewing model-generated implementations, technical foundations remain part of the job. A safer approach is to separate the criteria by role: assess whether candidates understand problems and explain trade-offs, while also checking required technical skills in ways relevant to the work. Reiseberg’s experience gives teams a reason to redesign their signals, but it does not provide validation that one method works for every organization. Models have changed the cost of producing code. Hiring teams remain responsible for making assessments fair, comparable, and close to the work.