Young People Lack a Voice? 5 Tips from an Anthropic Engineering Manager｜5Y View

Last week, we shared Felix Rieseberg's Our Ambitions Are Still Too Small in the Age of AGI. This time, he turns his attention to young people with ideas but no voice.

In the past, whether an idea could get off the ground often depended first on clearing hurdles of seniority, resources, and layers of approval. Today, two engineers who had recently joined Anthropic built a prototype of Claude Code's graphical interface over a single weekend, and about eight days later, the first public version was live. When the cost of validating an idea drops dramatically, the way young people fight for opportunity changes: instead of waiting for everyone to sign off, put forward a work that deserves to be seen.

Felix Rieseberg is an engineering manager at Anthropic. He previously led engineering for Claude.ai, Cowork, and Claude Code Desktop, and is a co-maintainer of open-source projects including Electron.

By Felix Rieseberg

This month, I said goodbye to traditional coding interviews. As the person responsible for hiring at Anthropic, I no longer ask candidates to do these tests. They once served a purpose: whether someone could quickly define a problem and find an elegant, concise solution, while limited in predictive power, gave us insight into a candidate's abilities and helped us gauge how they might perform after joining the team.

But today, this testing approach no longer holds up. Asking you to solve a small React problem is as meaningless as testing you on assembly language; Claude already far surpasses human engineers at both. What makes for a striking contrast: the people who contribute most to the team are not necessarily the ones who excel at these tests.

Coding interviews are ubiquitous but have never been popular. Yet if they truly disappear, senior engineers will likely still feel a pang of nostalgia, because it means our profession is changing. There's already been plenty of discussion about how AI impacts junior developers, especially job seekers. But after observing young engineers using AI for some time, I've become more optimistic: how much a person can contribute is increasingly less constrained by how many years they've spent accumulating knowledge of frameworks and codebases.

I'm seeing some newcomers rapidly surpass veterans who may write better code and have more experience. This intrinsic hunger to "get something done" transcends seniority.

These suggestions are written for young engineers, but "young" isn't quite right. Who I really want to address are the engineers who don't yet have connections, status, or a voice.

First, understand your strengths and limitations.

A newcomer's perspective, even if somewhat naive, has real value. When I joined Stripe, founder Patrick Collison repeatedly reminded us: pay attention to things that strike you as odd. He believed that newcomers can spot problems and opportunities that old hands have long since taken for granted.

In 1991, James March wrote that organizations need to "continuously incorporate naivete and ignorance." When someone asked Orson Welles why he dared to attempt shots no one had ever filmed before, he replied: "Ignorance, sheer ignorance. There is no confidence to equal it. I suppose when you know an industry, you become cautious and careful."

When I interviewed at Notion, one round asked me to design the architecture for offline mode. I later learned this was apparently a "trap question": everyone had decided offline mode couldn't be done. There were two reasons: the data model was too complex to sync an entire workspace; and if you only downloaded a single page, CEO Ivan Zhao would never accept that user experience. The first reason was true, the second wasn't, yet everyone had treated "the founder won't agree" as common sense without asking. As a newcomer, I didn't know about any of this, so I just asked.

It's easy to spot the flaws in these judgments when you're observing from the outside, much harder when you're the one caught up in them. Not long after joining Notion, I wanted to install large-screen TVs for the team to display real-time data dashboards. The idea met internal resistance, didn't happen, and I didn't think it worth making a fuss over.

A year later, Ji Pei, who had just joined, proposed the same idea. I dismissed it, advising him not to waste his energy — I'd already tried. But he had already asked. The next day, the TVs arrived. In just one year, I had become the veteran telling the newcomer "don't bother."

But however sharp a newcomer's perspective may be, there's one practical obstacle: nobody listens to you. Most tech companies rely on layers of managers to break down business goals into concrete tasks. Whether an idea can move forward is often decided by a small handful of people. In the past, execution was costly — you had to accumulate seniority and earn trust before the organization would invest resources in your ideas. Organizational structures change slowly too. Even companies that believe in AI often only expect young people to complete tasks faster, rarely anticipating that they'll proactively tackle larger business problems.

The good news is that building out an idea is no longer expensive.

(1) Keep your eyes on business goals, not just your to-do list. As early as 2011, before AI-assisted programming existed, Patrick McKenzie (software entrepreneur, technical business writer, known online as patio11, formerly at Stripe) said: "Companies hire engineers to create business value, not to write programs." He advised engineers to get close to the parts of the business that make money. First figure out what the company is trying to achieve. If it's a large company, start with your team or department's goals. Then look upward: what is your boss's boss concerned about? This usually helps you find the right level at which to think about problems.

(2) Find an idea bold enough. Around these goals, come up with a few proposals that, if executed, would significantly move the business forward. Be bold.

(3) Build it in a weekend. I've seen small teams, and solo engineers acting alone, produce working prototypes directly, skipping the lengthy process of writing requirements documents, fighting for support, and coordinating time with designers and product managers.

(4) One prototype, one good idea. A common mistake newcomers make is cramming too many ideas into a single prototype. Three good ideas buried among twenty bad ones will still get lost. If your prototype needs to invent a programming language, build a backend, and develop a mobile app all at once, it probably won't get built. The purpose of a prototype is to let managers quickly see two things: this opportunity is worth pursuing, and you have the ability to carry it through.

(5) Make use of the fresh perspective you haven't yet lost. When building user-facing products, newcomers often better understand how ordinary users feel, knowing what's intuitive and what's difficult. My colleagues at Slack and Notion, by contrast, struggled to step outside their internal perspective and understand the experience of external users.

When building infrastructure or tools, newcomers have an advantage too: you haven't yet heard all the explanations for why something can't be done.

I don't think traditional coding interviews are coming back. Once, many people bought Introduction to Algorithms, hoping it would land them a good job and a better life. Today, that selection method is exiting the stage, and software engineering has ascended another level of abstraction — hard not to feel some nostalgia.

But I've always disliked seniority-based promotion, so I can't help feeling optimistic. I've already seen quite a few popular apps and products born this way.

At Anthropic, people had grown accustomed to using Claude Code in the command line. Two recently joined engineers, Anthony Morris and Alice Zhao, built a graphical interface prototype over a single weekend. About eight days later, the first public version was live. The outcome was hardly surprising: a well-made Claude Code GUI proved popular.

How do you interview to find people who are genuinely skilled at getting things done with AI? I suspect I'm not the only manager puzzling over this. I don't have a complete answer yet. But when looking at resumes and portfolios, I watch for those small prototypes, seeing whether they demonstrate taste, understanding of users, and principled thinking. If you have a better approach, I'd love to hear it.

The accompanying image for this article is The Fighting Temeraire, painted by J. M. W. Turner in 1839.

Original article: https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/