Felix Rieseberg — the engineering manager at Anthropic who has led engineering for Claude.ai, Cowork, and Claude Code Desktop, and who co-maintains Electron — has done something rare and public: he has retired the traditional coding interview, and written down what he thinks replaces it. His argument is short, sharp, and hopeful in a way the "AI is coming for the junior developer" narrative usually isn't. In a world where Claude is now better at a React challenge than the candidate is, he argues, the thing that no longer separates a great engineer from a good one is accumulated framework knowledge. What separates them is older and rarer: hunger. "I'm seeing engineers who are comparatively new fly past people who are probably better coders and have been around much longer," he writes. Hunger beats tenure. This post unpacks his argument, traces the organizational-theory roots of it (it goes back to a 1991 paper by James March), reconstructs the specific economic shift that makes "a weekend prototype" a legitimate unit of organizational change, and then pushes back on where the thesis is survivorship-biased, where the selection problem he describes is genuinely hard, and what the whole thing actually implies for how the next generation of engineers gets made.
Who's Saying This: Why the Source Matters
Before the argument, the author, because the argument is only as credible as the person making it. Felix Rieseberg is not a thought-leader theorizing from the outside. He is an Engineering Manager at Anthropic who has, in his words, "led engineering for Claude.ai, Cowork, and Claude Code Desktop," and is a co-maintainer of Electron, the open-source framework that underpins a huge share of desktop apps on the internet. Before Anthropic he led Web Infrastructure and Desktop at Notion (2023–2025), led Payments Integration Experience at Stripe (2021–2023), was a Senior Staff Engineer and EM on the Electron and desktop-app teams at Slack (2016–2021), and before that was an Open Source Engineer at Microsoft. That is, unusually, a career that has been continuously at the exact layer this post is about — the layer where a prototype becomes a product, where an engineer's idea has to get past a room of more senior people, where a weekend build turns into a shipped thing. He has built desktop apps at four companies that became things people use. When he says "I've already seen my fair share of popular apps and products made this way," that is not a metaphor. That is his resume.
And he is a hiring manager. The post is not a prediction; it is a report of a decision he has already made. "This month, I laid the traditional coding interview to rest. As a hiring manager at Anthropic, I stopped asking candidates to do them." That is the difference between a blog post about the future of hiring and a first-person account of someone who has already changed the machine. It is also, quietly, a signal about how far Anthropic's hiring process has moved from the industry norm — the firm that just published that it built and migrated an entire source-control system (Scion) in five months with seven people is the same firm where one manager has decided the whiteboard is gone.
The Coding Interview Is Dead, and He Says Why
The coding interview "had a good run." His candor about its actual predictive power is worth sitting with: "Being able to quickly define problems and find elegant solutions was a weak but useful predictor for how successful you'd be on my teams. Small coding challenges in real code did tell us something meaningful about candidates." A weak-but-useful predictor. That is the honest statistical description of what the whiteboard has ever been: a noisy signal with a small true positive rate, kept around because it was cheap, standardizable, and — crucially — because at the time it correlated with the one scarce thing, which was raw implementation ability. Then the scarce thing stopped being scarce.
"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." Read that sentence slowly. The coding interview was, at bottom, a test of the lowest abstraction level in the stack: can you manipulate the machine and the framework directly, by hand, without help? When the machine and the framework are answered for you by a model that is better at the manipulation than you are, testing the manipulation tests nothing about the person who is going to be doing the actual work. It is the same logic as stopping the assembly quiz the day the compiler arrived — the abstraction moved up a level, and the thing that used to be the hardest part of the job is now the cheapest part. The interview was testing the cheapest part of the job.
There is a second, less comfortable point he raises, and it is the one that will "make established engineers have strong reactions." The coding interview "was, despite its ubiquity, never popular." Not popular with the people who had to sit through it, and — he is implying — not entirely popular with the people who had to design it either, because everyone knew it was a poor fit. Its persistence was never about its quality as a signal. It was about inertia, standardization, and the fact that it was a defensible default: an interview process you can run on everyone, score, and defend in a lawsuit. The disappearance of the whiteboard is, in part, the disappearance of a cargo-cult — a ritual that survived long after its original function (differentiating hand skill) became irrelevant. "I suspect that established engineers will still have strong reactions to its disappearance — if only for what it says about the evolution of our roles." The interviews were not just a filter. They were a small, repeated, public ritual that told every engineer in the room what the job is. Kill the ritual, and you have to answer the question the ritual had been dodging: if not hand skill, then what?
The Thesis: Impact Is No Longer Bounded by Accumulated Knowledge
Here is the actual claim, stated as clearly as he states it anywhere: "Impact is less bounded by how many years of accumulated knowledge in frameworks and libraries you've gathered." That is a load-bearing sentence, so let's be precise about what it does and does not say.
It does not say that expertise is dead. It does not say that a twenty-year engineer is now the same as a two-year engineer. What it says is that the specific form of expertise that used to gate impact — the deep, internalized knowledge of which library, which pattern, which framework, which API quirk, which tool — has been partially externalized into a model. The framework knowledge was always a proxy. It was a proxy for the ability to get something built. Now the model carries a large chunk of that proxy directly, which means the proxy no longer does the gating. Two engineers with very different framework tenures, put in front of the same model and the same problem, converge much faster toward the same output than they would have in 2020. The differentiator is what remains after you subtract the framework knowledge: taste, judgment, the ability to frame the problem correctly, and the willingness to actually go after it.
He frames this as "more hopeful," and it is, but only in a specific sense. The hope is that the bottleneck that used to keep a talented new person from making a large impact — years of grinding through a codebase, learning the idioms, earning the right to touch anything real — has been lowered. The model is, in effect, a compressed apprenticeship. You don't have to spend four years becoming fluent in the framework to get a fluent framework's help. That is genuinely democratizing, and it is the reason he thinks "engineers who are comparatively new" can "fly past people who are probably better coders and have been around much longer." The person who was "probably a better coder" was better at exactly the thing that got automated.
The Advantage and the Handicap: All Vision, No Voice
The most interesting part of the post is not the optimism. It is the section where he names the structural problem that the optimism has to fight through, and it is titled, aptly, "All vision, no voice." His first piece of advice is "know both your advantage and handicap," and the two are the same thing seen from two sides.
The advantage: fresh eyes, even naive ones, are powerful. He gives three pieces of evidence that the power of the newcomer is not a platitude but a documented, recurring phenomenon. First, when he joined Stripe, founder Patrick Collison "implored us newcomers to pay close attention to things that seem odd to us" — the bet being that newcomers "would spot friction and opportunities that old-timers had long stopped noticing." Second, a 1991 paper by the organizational theorist James March, "Exploration and Exploitation in Organizational Learning," which argued that healthy organizations depend on "maintaining an influx of the naive and ignorant" — a now-canonical result in management theory that mature, optimized organizations tend to become over-exploitative, locking in their own assumptions, and that a continuous stream of genuinely new people is the mechanism that keeps them from ossifying. Third, a quote from Orson Welles, who, when asked how he had the confidence to try shots nobody had tried, answered: "Ignorance, sheer ignorance — you know there's no confidence to equal it. It's only when you know something about a profession, I think, that you're timid or careful." The pattern across all three: the newcomer's ignorance is not a liability to be corrected. It is a feature. It is the absence of the "it can't be done" assumptions that the experienced have absorbed so thoroughly they no longer see them.
His own story makes it concrete. When he joined Notion, an interview asked him to design an offline-mode architecture. He was "baffled to hear that they considered it a 'trick' interview, since an offline mode was deemed impossible." The reasoning was that the data model was too complex to sync an entire workspace, and that downloading individual pages was a user experience the CEO would never allow. "The data model complexity turned out to be true; the founder resistance didn't." The first half of the "impossibility" was real. The second half was an assumption that had hardened into folklore. "People considered it such common knowledge that nobody had checked. I, an ignorant newcomer, didn't know better than to just ask." That is the whole argument in one anecdote: the experienced knew the data-model fact, which was correct, and had over-generalized from it into a complete "impossible" that no one was willing to test, precisely because it had become common knowledge. The newcomer, not knowing the folklore, simply asked.
Then the part that makes the post honest. He says it is "easy to read anecdotes like this one and see people making bad decisions," and that he "cannot overstate how hard it is to spot these mistakes when you're the one making them." Then he gives the proof that he became the mistake. Shortly after joining Notion, he wanted to put large TVs in every team's space to display live dashboards. "I ran into organizational walls, failed, and didn't care enough to start a whole fight." A year later, a new hire named Ji Pei had the same idea. "I scoffed and told him not to bother; I'd already tried. He'd already asked. The TVs showed up the next day. Somewhere in that year, I had become the old-timer." That is a remarkable sentence for a senior EM to write about himself: within a single year of joining, he had acquired the exact "it can't be done" reflex that the newcomer was supposed to be free of. The naive window is real, and it is also short. You do not get to be the fresh eyes forever. The person who asks the question you told them not to ask is, very often, the person who was you a year ago.
The handicap, which he then names bluntly: "The only problem with all that ignorant power: Nobody cares what you think." This is the structural wall. "Most tech companies have layers of middle management to translate larger business goals into execution. Structurally, companies are often built around the idea of a few people green-lighting or blocking individual ideas. In a world where execution is expensive, you normally have to grind your way to some social status before the entire organization would 'take a bet' on your idea." And here is the key transition of the whole post: "Well, good news: Execution isn't expensive anymore." That is the economic sentence that turns the entire argument from a nice anecdote into a thesis. The "all vision, no voice" problem — the newcomer who can see the opportunity but lacks the status to get it built — was a problem because building it was expensive. It required a team, a roadmap slot, a PM, a designer, a quarter. The cost of a mistake was a quarter of someone's life and a line item. Now the cost of a weekend prototype is a weekend. The economic precondition for "the junior can just go build the thing and show it" has, for the first time, actually been met.
What to Do: The Five-Point Playbook
Felix's advice is concrete, and it is worth quoting in full because it is a sequence, not a list of platitudes. The sequence matters: it goes from choosing the right target to building the right evidence.
The sequence, in order
The Proof Case: Claude Code Desktop Was Made Exactly This Way
Felix closes the advice with the proof that this is not hypothetical, because one of the most consequential products at his own company was built by this exact playbook, by two people who were comparatively new. "At Anthropic, people got so used to using Claude Code as a command-line interface (CLI) that it took two relatively new engineers (Anthony Morris and Alice Zhao) to whip up a working prototype over one weekend. The first public version shipped roughly eight days later. You won't be surprised to hear that a good graphical interface for Claude Code is a very popular product."
Read that as the argument in miniature. The opportunity: everyone was living in a terminal, and a lot of capable people were not going to. The idea was not a modest improvement; it was a different interface for the company's flagship product. No PRD process, no "let's discuss the roadmap implications in Q3." A weekend. A working prototype. Then eight days to a public version. The people who did it were, in Felix's own framing, "relatively new" — which is to say, junior by tenure, and therefore, under the old rules, exactly the people who would not have had the social capital to be handed a flagship-adjacent bet. Under the old economics, that product would have been a "let's see if the desktop team can find time next quarter" item. Under the new economics, it was a weekend, and the weekend happened. That is the thesis running itself. A junior-person's weekend prototype, aimed at a real usage pain, shipping to the public in eight days. The "hunger beats tenure" title is not a slogan; it is the causal story of Claude Code Desktop.
"The Future Is Bright": What He Actually Believes
The final section is the most optimistic, and the least quoted. "I don't think the coding interview is going to come back." That is a strong claim from a hiring manager, and it is worth taking seriously because he has a specific reason for it. "It's easy to get sentimental given how many copies of 'Algorithms and Data Structures' were bought in hopes of unlocking good jobs and a better future — or how the death of the coding interview is another milestone in software engineering reaching a new level of abstraction." He is aware of what he is doing. He is not just killing a test; he is marking the moment when the industry's entire entry ritual — the LeetCode grind, the algorithms book, the whiteboard — which had functioned as the gate to the profession for about two decades, stopped measuring the thing the profession actually requires. And then the line that is the emotional center of the piece: "At the same time, as a longtime hater of promotions by tenure, I can't help but be optimistic."
He is a longtime hater of promotions by tenure. That is a man who has spent his career being on the receiving end of the "you don't have seniority yet" reflex, and who has now, as a hiring manager, watched that reflex's economic foundation dissolve. The post is, quietly, a personal manifesto: the person who was once the "vision, no voice" newcomer, who watched himself become the old-timer who scoffed at the new hire, and who now has the authority to change the gate — is changing it. That is why the piece lands. It is not a theorist describing a future he hopes for. It is a practitioner reporting a change he has already made, for a problem he lived.
His own admission at the end is the most honest sentence in the piece, and the one the industry most needs to hear: "I'm probably not the only manager trying to figure out how to interview for people who build well with AI. I haven't quite gotten there yet — but I'm scanning resumes and portfolios for little prototypes that exhibit taste, empathy, and principled thinking." He has removed the old signal (the whiteboard) and has a new one he is settling on (the portfolio of weekend prototypes, judged for taste, empathy, and principled thinking) — but he is explicit that the new signal is still being built. The selection problem is real and unsolved. He is pointing at the answer and admitting the question is still open.
Where the Thesis Is Sharper and Where It Is Softer
This is the section where I push back, because a research post that only agrees is not a research post. The thesis is strong, but it has three soft spots, and naming them makes it more useful, not less.
1. The selection problem is genuinely hard, and he admits it
The old coding interview, for all its faults, had one property that is hard to replace: it was a live, controlled, same-day signal on a narrow, well-understood skill. You could watch a person think for forty-five minutes and form a judgment. The new signal — "a portfolio of little prototypes that exhibit taste, empathy, and principled thinking" — is better at measuring what actually matters, but it is also far harder to falsify and to score consistently. Taste is not a thing you can whiteboard. A portfolio can be polished by the model itself, which means the model is now both the candidate's tool and, potentially, the thing obscuring whether the candidate actually understands what they are shipping. There is a real risk that the new interview measures presentation fluency — the ability to produce a polished, working artifact — rather than the judgment to know which artifact to build and why. Felix's instinct, to look for "principled thinking," is the right one, but it is also the hardest to operationalize, and it is the one most vulnerable to being faked by the very tool that is now doing the building. The industry has traded a noisy but objective signal for a rich but subjective one, and that trade is not obviously a net improvement for every hiring context. For the people who are good at demonstrating, it is a liberation. For the people who are good at thinking but bad at demonstrating, the bar has moved in a direction that is harder to calibrate. That is the real, unresolved cost of "hunger beats tenure."
2. Survivorship bias is doing a lot of work in the anecdote
The Notion offline-mode story, the Ji Pei TVs story, and the Claude Code Desktop weekend story are all winners. They are the three stories that worked. They are, by construction, the ones that made it into the post. We do not know, from this piece, about the hundred offline-mode ideas, the fifty TV dashboards, and the thousand weekend prototypes that were built, shown, and quietly shelved — the ones where the fresh perspective was real, the prototype was good, and the organization simply said no, because the business goal was not actually there, or the timing was wrong, or the senior engineer who saw it was right that the data model would not hold. "Hunger beats tenure" is true in the cases where the hungry person aimed at a real goal and the organization was in a mode to accept a bet. It is not a law that hunger, aimed at a real goal, will win. The post is a story of the wins, and a wise reader should hold the losses in the same hand. The economic shift — "execution isn't expensive anymore" — makes it cheaper to be wrong, which is the real, defensible claim. It does not make being wrong irrelevant. The cost of a weekend is now a weekend, but the cost of the organization adopting a bad idea, or of a junior burning their one shot of credibility on a great idea aimed at the wrong goal, is still real.
3. "Junior" is the wrong word, and he knows it — but the fix is harder than the reframe
Felix is refreshingly honest that his title is a misnomer: "This post is my best advice for junior engineers, though 'junior' is the wrong word. It's really for engineers without social capital, status, or power." That is a more accurate frame, and it is a more uncomfortable one, because it means the post is not about people with two years of experience. It is about people who lack the network, the track record, and the standing to get a room to listen. That is a much larger group than "junior engineers." It includes the mid-level engineer at a big company who has been there four years and still has no voice. It includes the experienced engineer at a new company who has no history there. It includes the outsider, the contractor, the self-taught person, the person who is brilliant and under-credentialed. The advice — pick a real business goal, build a weekend prototype, show it — is aimed at that group. And the reason it works for them is not that they are young. It is that the economic cost of proving themselves has dropped below the cost of asking for permission. That is the deeper, more durable insight, and it is the one that generalizes beyond "junior engineers" to anyone in a position where their best evidence is a thing they could build this weekend instead of a memo they'd have to get approved to write. The reframe is correct. The implication — that the lever for the under-credentialed is now "show a working thing" rather than "argue a credible case" — is a shift in how status is earned that is as significant as the death of the whiteboard, and it is the part of the post that will outlast the specific news that one manager stopped a specific test.
What This Means for the Next Generation of Engineers
Strip the Anthropic-specific details and the post makes four claims with real, durable consequences, and they apply well beyond hiring at one company.
1. The apprenticeship compressed, which changes how expertise is acquired
The old path to "knowing the frameworks" was four to six years of doing the work, of being corrected, of internalizing the idioms. The model is a compressed version of that apprenticeship: it gives you, on day one, access to a fluent practitioner's output, without the years of correction that used to be the price. That is the genuinely liberating part, and it is real. But it also means the thing that used to be the scarce, earned part of seniority — the framework fluency — is now partially available to everyone, and therefore no longer a differentiator. The scarce, earned part is now the stuff that did not compress: taste, judgment, the ability to ask the right question, and the judgment to know when the model is wrong. The next generation of engineers will not be differentiated by how well they know the framework. They will be differentiated by how well they know when to trust the framework, the model, and each other. That is a harder, more senior skill to have at twenty-four, and it is now the skill the profession is selecting on. The apprenticeship did not disappear; it moved from "learn the tools" to "learn to judge the tool."
2. The unit of organizational change dropped from a quarter to a weekend
For most of the history of software companies, the unit of change was the roadmap slot: a quarter, a team, a PRD, a bet that had to clear a committee. That unit of change was calibrated to the cost of execution. Now the unit of change is the weekend prototype, and the cost of execution has fallen to match. That is not a small thing. It means the feedback loop between "I have an idea" and "I have evidence" has compressed from months to days, and it means the people who can run that loop — the hungry, the fresh, the under-credentialed — can now generate evidence at a speed that the old committee process was not designed to absorb. The organizations that figure out how to accept weekend-prototype evidence, how to turn a Friday-night demo into a Monday decision, will move faster than the ones that still require a PRD to enter the building. This is the operational counterpart to the hiring change, and it is where the real competitive differentiation will live.
3. The newcomer is a structural asset, not a developmental stage
James March's 1991 result, which Felix correctly invokes, is that organizations need a continuous influx of the naive to stay from ossifying. The standard reading is that this is a personnel-planning problem: hire some new people so you don't all think alike. Felix's version is sharper and more actionable: the newcomer's value is not a vague "fresh perspective" that you then have to extract through a slow onboarding. It is a specific, repeatable behavior — asking the question the room is too senior to ask — and the organizations that get the most from it are the ones that create a path from "asked the naive question" to "got to build the answer" fast, before the newcomer's naiveté wears off and they become, as Felix put it, the old-timer who scoffs. The Ji Pei story is the cautionary side: the organization had the answer (the TVs) but the person who asked was a year after the person who'd been told it couldn't be done. The speed between "naive question" and "working prototype" is the variable that determines whether the newcomer's advantage is captured or lost. That is a management insight, not just a career one, and it is one of the more durable ideas in the piece.
4. The profession's entry ritual is being re-standardized around taste, not hand skill
For twenty years, the entry ritual was the whiteboard, and the entire preparatory industry around it — the algorithms books, the problem banks, the interview-prep courses, the "I solved 300 LeetCode problems" resume line — was calibrated to that ritual. Felix is explicit that the ritual is over, and that the new ritual is "a portfolio of little prototypes that exhibit taste, empathy, and principled thinking." That is a re-standardization in progress. The next generation of engineers will not be prepared for a whiteboard. They will be prepared to build and show. The preparatory industry will shift, slowly, from "how to pass the interview" to "how to build a portfolio of things that show taste." And the people who understand that shift early — the ones who treat every side project as a piece of evidence for the new ritual, who build to show rather than to ship — will have an advantage that is, in a sense, the exact opposite of the old one: the old advantage was knowing the answers the whiteboard would ask. The new advantage is building the things the portfolio will show.
The three takeaways
Bottom Line
Felix Rieseberg has written a short piece that is doing a lot of quiet work. On the surface, it is an engineer at Anthropic saying he stopped the whiteboard and here is his advice for the new generation. Under the surface, it is a report that the economic foundation of how software companies evaluate and promote people has shifted, and that the shift is being made visible by a specific, measurable technology — a model that is now better at the React challenge than the candidate. The "hunger beats tenure" frame is the emotional hook, but the real argument is more structural and more defensible: the thing that used to gate impact — accumulated framework knowledge — has been partially externalized into a model, so the gate has moved, and it has moved to taste, judgment, and the willingness to build evidence rather than ask for permission. The post is at its best when he is honest about the limits of his own position: he became the old-timer in a year, the selection problem is genuinely unsolved, and he is explicitly still figuring out the new signal. That honesty is what makes it a useful artifact rather than a victory lap. And the proof case — two relatively new engineers, a weekend, eight days to a public version of the most popular product in the company's suite — is not an anecdote. It is the thesis running itself, and it is the strongest possible evidence that the world he is describing is not a prediction. It is already the way things get made. The next generation of engineers will not be sorted by how well they can manipulate the machine. They will be sorted by how well they can decide what to build, how well they can judge the tool that builds it, and how fast they can turn a naive question into a working thing. The whiteboard is gone. The portfolio is what is left. And for the first time, the portfolio is a fair test.
References
- Felix Rieseberg — "Hunger beats tenure: Advice for junior engineers" (source post, Oct 27, 2026) [felixrieseberg.com]
- Felix Rieseberg — About Me (Anthropic EM, Electron co-maintainer, ex-Notion/Stripe/Slack/Microsoft) [felixrieseberg.com]
- James G. March — "Exploration and Exploitation in Organizational Learning," Management Science 37(3), 1991 (source of the "influx of the naive and ignorant" principle) [PDF]
- Claude Code by Anthropic (the product built per the playbook) [claude.com]
- Patrick McKenzie (mzen) — "engineers are hired to create business value, not to program things" (2011, cited in post) [signalvnoise.com]
- Felix Rieseberg — "How to be more ambitious: A tutorial for humans with models" (related, Oct 13, 2026) [felixrieseberg.com]
- Electron (Rieseberg co-maintainer) [github.com]
Source post read in full on October 29, 2026 (8,441 chars). The James March (1991) principle, the Patrick McKenzie (2011) "business value" quote, and the Orson Welles quote are as attributed in the source post; the March paper is the canonical source for the "influx of the naive and ignorant" organizational-learning result. The Claude Code Desktop weekend-prototype story is reported first-person by the author (Felix Rieseberg), an engineering manager at Anthropic who led engineering for Claude Code Desktop; the named engineers (Anthony Morris, Alice Zhao) are credited as in the source. The critical-analysis section (Sections 1–3 of "Where the Thesis Is Sharper and Softer," and the implications) is this author's own analysis and is clearly distinguished from the source's claims.