Skip to content
Personal Employment ComputerModel J-79 · Insights
← Jobby Insights

What junior engineers should show in an AI-built prototype

Apply Felix Rieseberg's prototype advice to one CSV import problem: make user choices, failure checks, tradeoffs and your own understanding visible.

Published · Updated

A cardboard channel with an olive metal gate, two wooden balls, a terracotta block in a side pocket and a curved offcut.
Original conceptual illustration of a small prototype with a visible exception path. It depicts no measured experiment or software interface.

What Felix's advice supports

In his October 27, 2026 essay, Anthropic hiring manager Felix Rieseberg says he stopped giving traditional coding interviews. He is looking for small prototypes that show taste, empathy and principled thinking, while acknowledging that he has not settled the replacement assessment. This describes his hiring practice, not an Anthropic-wide policy. His accounts of newer engineers surpassing longer-serving colleagues are anecdotes, not proof that experience has stopped mattering.[1]

His useful constraint is one good idea tied to an organizational goal. Start by observing a user's friction, then check your interpretation with that person when possible. Newness can prompt a useful question; it does not establish that you understand the user. For the exercise below, the proposed goal is less time repairing imports without silently changing records. Any business benefit remains unmeasured.[1]

Choose the behavior before building

Imagine a support worker preparing CSV files for import. Choose between two prototypes before reading the explanation: one automatically repairs odd values and imports every row; the other previews rows and holds uncertain cases for a person. Keep this fictional exercise local and preview-only. It needs no accounts, live database writes, synchronization or dashboard.[1]

Freeze four input rows. The first has unique identifier 0017 and date 2026-04-03. The second has unique identifier 0018 and date 03/04/2026, which could mean March 4 or April 3. Two different rows share identifier 0042 and have unambiguous dates. Keep identifiers as text. Save the exact fixture, then process it by hand and record the steps as your baseline.[1]

Declare the required outcomes before asking AI to build anything. Accept the first row unchanged, including its leading zeros. Hold the second until a person verifies the intended date; the fixture supplies no answer. Hold both conflicting 0042 rows pending an explicit human choice. A preview that rejects everything also fails. Correct acceptance and correct rejection both matter.[1]

Make the failure and tradeoff visible

Suppose a generated parser converts 0017 into the number 17. This is a hypothetical bug, not an observed result. Compare the preview with the first required outcome: the identifier changed, so the check fails even if the interface looks finished. After correcting the parser, rerun the same fixture. Keep this regression case when you add another input.[1][4]

The preview deliberately defers automatic repair. It keeps uncertainty visible and prevents a duplicate from silently overwriting another row, at the cost of more human review. Explain that rejected alternative during the demonstration. If you run the exercise, compare the whole manual and assisted workflows using the same inputs and correctness rules. Include review and correction time. Record an actual failure and its repair before claiming a saving.[1][3]

What the research adds

MIT Sloan's November 2024 account of research coauthored by Kevin Cui and Mert Demirer reports higher weekly completed-task output across three company experiments with GitHub Copilot code completions. This supports the possibility of output gains. Task counts do not measure revenue or time saved, and the analysts did not inspect the produced code's quality. It does not establish that juniors outproduce seniors.[2]

METR's February 2026 experimental follow-up supplies a caution about measuring gains. Developers declined no-AI work or withheld tasks they expected AI to accelerate, and concurrent agents complicated time measurement. METR calls the resulting current-effect estimate unreliable. Its evidence cannot supply a dependable productivity multiplier for your prototype.[3]

Understanding needs a separate check. Anthropic's January 2026 account describes a randomized trial with 52 Python users unfamiliar with Trio. The AI-assisted group scored worse on an immediate comprehension quiz; the completion-time difference was not statistically significant. This short chat-assistant study did not test agentic tools, lasting expertise or hiring outcomes.[4]

Demonstrate a decision you can explain

Close the assistant and explain the identifier, date and duplicate-handling paths. Diagnose the leading-zero failure unaided. Show which choice serves the user and what remains untested. Follow the employer's assessment and AI-use rules. A weekend is an optional scope limit, not a commitment test; production reliability, integration, security and maintenance still require work. Start with the frozen rows and expected outcomes before adding features.[1][4]

Sources

  1. Hunger beats tenure: Advice for junior engineersFelix Rieseberg,
  2. How generative AI affects highly skilled workersMIT Sloan,
  3. We are Changing our Developer Productivity Experiment DesignMETR,
  4. How AI assistance impacts the formation of coding skillsAnthropic,