Anthropic engineering manager ends coding interviews, citing Claude's coding skill
Anthropic engineering manager Felix Rieseberg says he no longer runs coding interviews because Claude codes better, and urges junior engineers to show drive.
According to TechRadar, Felix Rieseberg, an engineering manager at Anthropic, has stopped using coding interviews as part of his hiring. In a blog post, he explains that the AI model Claude now writes code better than many of the tasks such interviews ask candidates to complete, which he says makes those exercises less useful.
The same post speaks to junior engineers, encouraging them to approach their jobs and current roles with a particular attitude. TechRadar summarizes the message with a line that favors hunger and drive over job security and seniority, suggesting that eagerness to learn matters more than a settled position.
Rieseberg also says he is looking into ways to interview people who are skilled at using AI for coding, according to the report. TechRadar's summary does not describe what those methods would involve, and it does not say whether Anthropic has adopted a formal replacement for its previous process.
The announcement came in a blog post published on October 31, and TechRadar's account rests on that post. The report does not include comments from other Anthropic staff or from outside hiring experts.
Background
Technical interviews have long been a standard gate into software jobs. Candidates are often asked to solve algorithm problems on a whiteboard, write code in a shared editor while being watched, or complete a take-home assignment. Supporters say these tests show how a person thinks through problems. Critics argue that they reward practice with puzzles, can add stress that has little to do with everyday work, and may screen out capable people who communicate or learn differently.
AI coding tools have spread quickly through software development over the past few years. Developers now use assistants inside their editors to draft functions, search codebases, explain unfamiliar code and suggest fixes. That shift has raised a practical question for employers: if a tool can produce a working solution in seconds, what should a test of a person's coding ability actually measure?
Companies have answered in different ways. Some have kept traditional tests but allowed candidates to use AI tools during them. Others have moved toward project-based work, system design discussions, or reviews of past code. Hiring for junior roles has also drawn attention, because entry-level tasks that once trained new engineers, such as routine bug fixes and small features, may be easier to automate. Any change in interviewing therefore touches on how people learn the trade, not only how they are chosen for it.
Why it matters
A senior engineer at an AI company stepping away from coding interviews is a notable signal, because it comes from inside a firm that builds the tools in question. If the people building AI systems conclude that a standard coding test no longer separates strong candidates, other employers may reach the same view and begin revising their processes.
The change also highlights a tension. Interviews that test raw coding skill may matter less if the work increasingly involves directing AI tools, checking their output, and understanding what the code does and where it can fail. That shifts the skills employers want toward judgment, communication and the ability to evaluate results, qualities that are harder to score in a short session.
For early-career engineers, the message is mixed. The advice to lean into drive may be useful, but it does not address how newcomers will gain experience when some routine tasks are handled by software. How companies answer that question will shape the path into the profession for years.
What to watch
The most useful detail will be what replaces coding interviews. Rieseberg has said he is exploring new approaches, so a published description of the method, and whether other Anthropic teams adopt it, would show how seriously the idea is being taken. Candidates and recruiters will want to know how such evaluations are scored and whether they are fair.
It will also be worth watching whether other large employers report similar shifts, and whether junior hiring trends change over the coming year. Any data on that would help separate a single manager's view from a broader pattern in the industry.
Viewpoints
Commentary from our columns: three angles on this story.
The Skeptic open questions and weak points
It is worth pausing on the reasoning here. A claim that a tool codes better than people is easy to repeat and hard to measure. Coding interviews were never a perfect test, but they gave employers a common yardstick. If that yardstick is retired, the question becomes what replaces it, and the answer is not yet clear from the public account. A new method might be better, or it might simply be less transparent. Candidates deserve to know how they will be judged. Hiring managers also face a quiet risk: when a test stops measuring what it once did, they may not notice until the wrong people are hired. Before anyone treats this as a template for the industry, the replacement process should be described in detail, tested against outcomes, and shown to predict on-the-job performance. Until then, the sensible reading is an open question rather than a settled answer.
The Builder the engineer's view
From an engineer's seat, the interesting part is what the test was really for. A whiteboard problem was always a proxy for how someone breaks down a task, reasons about edge cases and reads unfamiliar code. Those abilities still matter when an AI writes the first draft. The job shifts toward reviewing, testing and deciding what should be built in the first place. A good replacement would likely look like a realistic work session: a messy codebase, a bug with partial clues, and a request to explain trade-offs out loud. Candidates could use the tools they would use on the job, and the interviewer would focus on whether they can judge the output. That is harder to grade than a puzzle, but it is closer to the real thing. Teams that try this will learn quickly whether they are measuring understanding or just fluency with a chat window.
The User what changes for people who use it
For people applying for jobs, this news lands in a real and personal way. Someone who spent months preparing for coding puzzles now has to wonder whether that effort still pays off. The advice about drive is encouraging, but it can also sound like a shift of responsibility onto the individual, when the labor market itself is changing. Junior engineers often learned by doing small, repetitive tasks, and those tasks are the ones most likely to be handled by software. Newcomers may need new ways to show what they can do, such as building small projects, documenting their reasoning, or contributing to open-source work. Employers who change their interviews should also be clear about what they now expect, so applicants are not left guessing. Clear expectations would make the transition far less stressful for everyone trying to enter the field.