Anthropic ends the coding interview and bets on hunger, not tenure

The React test became as useless as testing assembly

This October 2026, Felix Rieseberg, hiring manager at Anthropic, published a post explaining why he stopped using the traditional coding interview in engineering hiring processes. The account was featured by the Latent Space newsletter, which daily rounds up what circulates on technical Twitter/X, and gave it the day's headline spot, alongside launches like Google DeepMind's Genie 4.

Rieseberg's reasoning is direct: asking a candidate to solve a React challenge makes as little sense as testing assembly knowledge, because Claude, according to him, is already better than humans at both. He stresses that the most impactful engineers inside Anthropic succeed regardless of the score they would get on these tests.

This month, I laid the traditional coding interview to rest. As a hiring manager at Anthropic, I stopped asking candidates to do them… There's no more point in giving you a little React challenge than there is in quizzing people about assembly; Claude is now better at both. Our most impactful builders are successful regardless of how good they are at these tests.

Felix Rieseberg, hiring manager at Anthropic

"Coding is solved" is a strong claim. The benchmark agrees only in part

Rieseberg's phrase sounds like hype, but it's worth checking against numbers from the same day. Artificial Analysis launched its Intelligence Index v5 with Claude Opus 5.5 (max) in the lead, 58 points, ahead of GPT-6 Astra (57) and Gemini 4 Argon (50). Cognition also launched FrontierCode 2.0, a benchmark that uses deliberately underspecified prompts and evaluates whether a maintainer would accept the change's merge.

The detail that matters for the hiring angle: the top of FrontierCode 2.0 scores 45%. In other words, even the best model gets most tasks wrong when the prompt is ambiguous, exactly the common situation in real production code, not in an interview challenge. "Coding is solved" is true for the isolated, well-specified challenge, like a 45-minute React challenge. It's much less true for maintaining a production system with incomplete requirements, which is the real job of a senior engineer.

This doesn't invalidate Rieseberg's argument. It just shows why what he's killing is the timed algorithm interview, not the need for technical judgment. The distinction matters for whoever is going to copy the practice without copying the context.

What Anthropic checks for instead

In the post, Rieseberg lists what he started looking at in candidates, mainly juniors, instead of the code challenge:

• Business impact over backlog: he cites Patrick McKenzie's 2011 post about why engineers are hired to generate value, not to program.
• Radical idea, not incremental: candidates should arrive with proposals that, if successful, would meaningfully change the company's results.
• Prototype built over a weekend: he says he's seen small groups and solo engineers skip the entire process of requirements documents, alignment, and waiting in line for designer time, delivering a working prototype directly.
• One good idea, not twenty average ones: the most common junior mistake, in his view, is packing three excellent ideas inside twenty bad ones in the same prototype.
• Fresh perspective as an advantage: those just starting out have user empathy that those already hardened by the product have lost.

Engineers are hired to create business value, not to program things.

Patrick McKenzie, in a 2011 post cited by Rieseberg

What changes for those who hire, not for those who get hired

For a founder or tech leader reading this in Brazil, the point isn't to replicate Anthropic line by line. It's to notice which hiring signal lost value and which gained it.

In short: Anthropic traded a cheap, scalable filter for an expensive, qualitative filter, because it can afford that cost. The company reported, in the S-1 cited by the same Latent Space edition, an 85% gross margin and US$134 billion in cash in the first half of 2026. A ten-person team making artisanal hiring decisions doesn't have the same cushion to absorb a bad hire.

The risk of copying without the context

There's a blind spot in Rieseberg's recommendation worth naming: it tests product fit and ambition, not whether the candidate understands why a distributed system goes down at 3 a.m. For infrastructure, security roles, or any position where the cost of a bug is high and silent, giving up any structured technical verification is a bet that the weekend prototype generalizes to production, which doesn't always happen.

The most honest approach for anyone leading engineering hiring today is hybrid: for junior and product roles, swapping the algorithmic challenge for a short-deadline prototype with evaluation criteria based on decision-making, not syntax, is consistent with what AI already handles well. For senior critical-infrastructure roles, keeping some form of structured technical evaluation is still defensible, except it also needs to evolve: testing for debugging AI-generated code and reviewing architectural decisions matters more than testing for building something from scratch.

The phrase that titles Rieseberg's post, "hunger beats tenure," sums up the moment's appetite well: smaller teams, more AI in the middle of the process, and hiring decided by those who have already proven they build under pressure, not by those who memorized interview patterns.