When AI can handle small programming exercises, a coding interview may reveal less about a candidate than it once did. Felix Rieseberg, an engineering manager at Anthropic, says teams should pay closer attention to what engineers choose to build, which problems they notice and how well their ideas serve a company’s goals.
Why coding tests may miss what matters
Rieseberg, who has led development of Claude.ai and Claude Code Desktop at Anthropic, argues that Claude can complete the small programming tasks often used in interviews better than candidates can. He compares asking applicants to solve a small React challenge with quizzing them on Assembly: in his view, the exercise no longer measures the skills that matter most.
He also says strong test scores have not reliably identified the best developers on his teams. Instead, he has seen relatively new engineers pass more experienced colleagues. His phrase for that pattern is: “Hunger beats tenure.”
His use of “junior” is broader than years on the job. He is talking about engineers who lack status, authority or an established network inside their company. That position can make it harder to get an idea heard, but it may also leave them more alert to problems others have stopped questioning.
Fresh eyes can challenge old assumptions
Rieseberg points to organizational researcher James March, who wrote in 1991 that organizations depend on a steady stream of naive and uninformed newcomers. The argument is that unfamiliarity can be useful: new employees may see confusing routines or obstacles that long-serving colleagues have come to accept.
He also cites Stripe founder Patrick Collison’s encouragement for new hires to flag anything that seems strange. People who have worked around a friction point for a long time may no longer notice it. A newcomer’s questions can reveal that a practice is an assumption rather than a necessity.
Rieseberg recalls an example from his time at Notion. He was asked to design an offline architecture that colleagues thought could not work, partly because of the complexity of the data model and the belief that CEO Ivan Zhao would reject the only workable solution. Rieseberg says the technical challenge was real, but the assumed opposition had never been checked: nobody had asked Zhao.
Use AI to make an idea tangible
Rieseberg says organizations developed layers of approval because building and testing ideas used to be costly. A small group of decision-makers could approve or block work, while other engineers often had to gain trust and move through a hierarchy before they could make something real. AI, he argues, lowers the cost of execution.
His advice begins with business understanding. Engineers should learn what their company is trying to accomplish, connect their work to the areas that create value, and understand the goals of their manager’s manager. He draws on a 2011 quote from Patrick McKenzie: “engineers are hired to create business value, not to program things.”
Once an engineer spots an opportunity, Rieseberg suggests choosing one ambitious idea and building a working prototype over a weekend. A prototype can make the proposal concrete without first going through the usual sequence of specifications, approvals and discussions with designers or product managers.
The scope should stay focused. Rieseberg advises against burying a strong proposal among many weaker ideas or trying to build an entire system at once. The goal is a clear demonstration that helps leadership understand the opportunity and see who could take it forward.
Empathy helps, but the new bar has costs
Rieseberg sees different advantages depending on the work. For user-facing products, newer engineers may bring empathy for people outside the company. He says long-tenured colleagues at Slack or Notion could struggle to see the product from an outside user’s perspective. For infrastructure and internal tools, a newcomer may benefit from not already knowing why a problem is supposedly impossible.
He points to two relatively new Anthropic engineers, Anthony Morris and Alice Zhao, who built the graphical interface for Claude Code over a weekend. The first public version shipped about eight days later. Rieseberg says he now looks for small prototypes in job applications that show taste, empathy and principled thinking, and he does not expect the classic coding interview to return.
That approach offers a way for newcomers to make their ideas visible, but it also changes what entry-level work demands. The emphasis shifts toward entrepreneurial thinking, product judgment and taste—skills the source says most universities barely teach and companies have often expected from experienced product managers or founders.
There is also a question of access. The examples Rieseberg praises involve engineers who built prototypes on weekends without being asked. “Hunger beats tenure” may inspire initiative, yet it assumes a level of spare time and willingness to hustle that every new developer may not be able to bring to a job.