Anthropic Engineering Manager scraps coding interviews: 'Hunger beats tenure'

Anthropic engineering manager Felix Rieseberg has scrapped the classic coding interview, arguing that Claude now solves small programming tasks better than job candidates do — and that AI is letting ambitious newcomers overtake more experienced engineers on his teams.

Rieseberg has led development of Claude.ai and Claude Code Desktop at Anthropic. In a post aimed at what he calls "junior" developers, he says there is no longer any reason to give candidates little programming exercises. In his view, handing someone a small React challenge today makes as little sense as quizzing them on Assembly.

His redefinition of "junior" matters. He doesn't mean people just starting their careers. He means any engineer without social status, power, or a network inside their company. The takeaway: the bar for who counts as an outsider isn't age or experience, but influence.

Why is the coding interview dead?

Rieseberg's argument is mechanical. The coding test existed to check whether a candidate could execute well. AI has collapsed the cost of execution, so the test no longer measures anything scarce.

On his teams, good test scores no longer predict who turns out to be a top developer. Instead, he says he's watching relatively new engineers overtake more experienced colleagues. "Hunger beats tenure," he says.

That shift carries real stakes for the job market. If coding tests stop filtering candidates, hiring moves to signals like product sense and taste — skills companies have traditionally expected from experienced product managers or founders, not entry-level engineers.

Why do newcomers spot problems veterans miss?

Rieseberg argues newcomers hold a structural advantage: they notice problems that long-time employees accepted as givens years ago.

He points to organizational researcher James March, who wrote in 1991 that organizations depend on a steady stream of naive and uninformed newcomers. Stripe founder Patrick Collison has also explicitly urged new hires to flag anything that seems strange to them. Veterans, Collison noted, stopped noticing those friction points long ago.

Rieseberg cites his own time at Notion as proof. He was asked to design an offline architecture that people inside the company considered impossible. The data model was too complex, and CEO Ivan Zhao would supposedly never accept the only workable solution. The technical hurdle was real, he says — but the founder's resistance wasn't. Nobody had asked Zhao, because everyone treated his objection as common knowledge.

The lesson in plain words: "impossible" inside a company often just means nobody checked.

How does cheap execution break the hierarchy?

The core problem for newcomers, Rieseberg says, is that nobody in the company listens to them. Because execution used to be expensive, organizations were built so that a few decision-makers could approve or block ideas. Engineers had to climb a rigid hierarchy before management trusted them to actually build something.

AI changes that equation because execution is no longer expensive, Rieseberg writes. When a working prototype costs a weekend instead of a quarter of headcount and budget, gatekeepers lose their leverage.

His first piece of advice builds on a 2011 quote from Patrick McKenzie: "engineers are hired to create business value, not to program things." Developers should understand what their company is really trying to achieve, he says, and attach themselves to the parts that make money. A useful starting point: know your manager's manager's goals.

From there, Rieseberg suggests picking one ambitious idea that would dramatically advance those goals and building a working prototype over a weekend. That skips the usual cycle of product specs, approvals, and lobbying designers or product managers.

He warns against overreach. Focus on one good idea instead of hiding three good ones among 20 bad ones. Anyone who builds a prototype that includes a new programming language, a backend, and mobile apps all at once will fail, he says. The prototype should get the idea across so clearly that leadership immediately sees both the opportunity and the right person to run with it.

Do newcomers have an empathy advantage too?

Rieseberg distinguishes between two types of engineers. Newcomers working on user-facing products bring a natural empathy for outside users — long-tenured colleagues at Slack or Notion had a hard time seeing things from an outside user's perspective. Engineers working on infrastructure or internal tools benefit differently: they don't know why something is supposed to be impossible.

He backs this up with an example from inside Anthropic. Two engineers who were relatively new at the time, Anthony Morris and Alice Zhao, built the graphical interface for Claude Code over a weekend. The first public version shipped about eight days later.

That example doubles as a hiring signal. Rieseberg now looks for small prototypes in job applications that show taste, empathy, and principled thinking. The classic coding interview isn't coming back, he says.

What does this mean for entry-level jobs?

Rieseberg's advice cuts two ways. On one hand, it reads as a message of empowerment: AI becomes an equalizer that lets newcomers get past gatekeepers who've gone blind to their own company's problems.

On the other hand, it moves the bar for entry-level jobs away from diligence and craft toward entrepreneurial thinking, product sense, and taste. Most universities barely teach those skills, and companies have traditionally expected them from experienced product managers or founders.

There's also a personal cost hidden in the message. The engineers Rieseberg holds up as models — Morris and Zhao — built prototypes on weekends without being asked. "Hunger beats tenure" sounds motivating, but it assumes a hustle mentality that not every new developer can bring to the job.

For Anthropic's own hiring, though, the direction is set: show a prototype that demonstrates taste, and don't expect a React challenge in the interview loop.