This month, I laid the traditional coding interview to rest. As a hiring manager at Anthropic, I stopped asking candidates to do them. It had a good run: 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.

That’s no longer true. 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.

The coding interview was, despite its ubiquity, never popular. 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. Plenty of ink has been spilled to describe how AI is a challenge for junior developers, especially those trying to land a job. Now that I’ve seen junior people work with AI for a bit, I have a more hopeful take: Impact is less bounded by how many years of accumulated knowledge in frameworks and libraries you’ve gathered.

I’m seeing engineers who are comparatively new fly past people who are probably better coders and have been around much longer. Hunger beats tenure.

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.

All vision, no voice

First, know both your advantage and handicap.

Fresh eyes, even naive ones, have long been considered powerful. When I joined Stripe, founder Patrick Collison implored us newcomers to pay close attention to things that seem odd to us. His bet was that newcomers would spot friction and opportunities that old-timers had long stopped noticing.

In 1991, James March wrote that organizations depend on “maintaining an influx of the naive and ignorant”. When Orson Welles was asked how he got the confidence to try shots nobody had tried, he said: “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.”

When I joined Notion, one of my interviews involved designing an offline-mode architecture. I was baffled to hear that they considered it a “trick” interview, since an offline mode was deemed impossible. The data model was too complex for easily syncing an entire Notion workspace, and downloading individual pages was a user experience CEO Ivan Zhao would never allow. The data model complexity turned out to be true; the founder resistance didn’t. People considered it such common knowledge that nobody had checked. I, an ignorant newcomer, didn’t know better than to just ask.

It’s easy to read anecdotes like this one and see people making bad decisions. I cannot overstate how hard it is to spot these mistakes when you’re the one making them. Shortly after joining Notion, I wanted to outfit teams with large TVs to display live dashboards. I ran into organizational walls, failed, and didn’t care enough to start a whole fight.

A year later, Ji Pei joined as a new hire with 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.

The only problem with all that ignorant power: Nobody cares what you think. 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. Org charts tend to change at a glacial pace, so even companies that believe in AI often expect junior people to simply execute their tasks faster rather than ambitiously go after business goals.

Well, good news: Execution isn’t expensive anymore.

What to do

(1) Pick business impact over backlog: In pre-AI-coding 2011, Patrick McKenzie wrote “engineers are hired to create business value, not to program things.” Attach yourself, he advised, to the parts of a company that make money. Start there: Understand what your company is actually trying to accomplish (or, at a larger one, what your group or department is). Then find the right altitude — understanding what kind of goals your manager’s manager has is often a useful proxy.

(2) Pick a radical idea: Come up with a few ideas that would, if successful, dramatically improve the chances that your organization achieves those goals. Be ambitious!

(3) Build it over a weekend: I have seen small groups and solo engineers fly past the usual process of writing product requirements documents (PRDs), getting buy-in, and lobbying for time with designers or product managers by building a working prototype.

(4) Focus on one good idea: In my experience, junior people often make the mistake of cramming multiple ideas into a single prototype, hiding three excellent ideas among 20 bad ones. If your prototype involves the creation of a new programming language, a backend, and also somehow mobile apps, you’re not going to be successful. The point of creating a working prototype is to communicate an idea so well that leadership quickly understands both the opportunity and that you’re the one who can run with it.

(5) Lean into your fresh perspective: If you’re working on something user-facing, you have a unique amount of empathy for users and thus a much better sense for how the product works or doesn’t work for them. My colleagues at Slack and Notion had a hard time internalizing what using Slack or Notion is like as an external user.

If you’re working on infrastructure or tooling, you have the benefit of never having learned all the reasons things are considered “impossible”.

The future is bright

I don’t think the coding interview is going to come back. 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.

At the same time, as a longtime hater of promotions by tenure, I can’t help but be optimistic. I’ve already seen my fair share of popular apps and products made this way.

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.

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. If you have figured out something better, I'd love to hear how.

The image for this post is by J. M. W. Turner, “The Fighting Temeraire” (1839)