Four mistakes engineers make on the 13-day project.

Stage 3 of the OpenTalent screening is a 13-day real-world project. The candidate picks one of three open-ended briefs in their specialization, ships a deliverable, and writes it up. We’ve now reviewed roughly 2,400 submissionsover the past three years, and one of the more useful patterns we’ve noticed is that the projects that fail tend to fail in the same four ways. They are not execution failures. They are decision failures — and they are catchable in the first 48 hours if you know to look for them.

This piece is the long version of the panel advice we already give candidates the morning they receive their brief. If you’re considering applying to the network — or already mid-screen and reading this in week one — most of the value here is in which things to do early and which not to do at all.

The four mistakes, briefly, before we dig in:

1. Scope inflation. Picking a problem big enough to feel impressive and then failing to deliver any of it well.
2. No hypothesis. Submitting a tour of techniques rather than an answer to a specific question.
3. Write-up as recap, not argument. Documenting what you did instead of arguing for what you found.
4. No eval.Submitting work with no honest way to know whether it’s any good.

The fourth is the one that has grown most in our data — six years ago maybe 30% of submissions had a proper eval; this year roughly 70% do. That’s a real improvement. The other three have moved barely at all.

// 01Scope inflation

This is the single most common failure mode. About 42%of submissions that don’t make it through the panel have a scope-inflation problem — even though the brief explicitly tells candidates to narrow.

The instinct behind scope inflation is recognizable. The candidate wants the project to look like it justifies the offer band; the offer band is a senior IC frontier-lab role; senior IC work looks ambitious. So they pick an ambitious-sounding problem and try to deliver enough of it to demonstrate the ambition.

That logic gets the prior backward. Senior IC work at frontier labs is, in practice, mostly narrow shipping. The work that wins those teams promotions is the work that picks a tight question and answers it with rigor — not the work that proposes to solve everything. Panels grade for the disposition that actually predicts senior IC performance. Picking a smaller problem and finishing it cleanly is the dominant strategy.

The recover move, if you’re on day 3 and realize you’ve scope-inflated: cut. Ruthlessly. Pick the single most interesting sub-problem inside your original plan and treat the rest as future work in the write-up. Panels reward this. We’ve reversed our debrief verdict on the strength of a candidate’s day-7 email saying “I’ve narrowed the scope, here’s what I’m cutting, here’s why” more times than is comfortable.

// 02No hypothesis

This is the failure mode that frustrates panel members most directly, because it makes the work harder to evaluate. When the submission is a chronological tour, the panel has to assemble the implicit thesis on the candidate’s behalf — and that’s not the panel’s job. About 31% of failed submissions in our data are no-hypothesis submissions.

Strong senior IC engineers operate hypothesis-first by default, and the project is a probe for that disposition. We’re not asking whether you can implement three things in two weeks (you can; most candidates can). We’re asking whether your first instinct when given an open-ended brief is to convert it into a specific, falsifiable, testable claim. That instinct is what the panel is grading.

The recover move, if you’re at day 9 and realize you’ve toured rather than argued: state a hypothesis now, retroactively, and present your existing work as evidence for or against it. Write the hypothesis at the top of the write-up. Frame everything that follows as supporting or contradicting that hypothesis. This is not deception — it’s the act of converting your week of work into research. The panel cares much less about whether the hypothesis was your first thought and much more about whether the final submission is hypothesis-driven.

// 03Write-up as recap, not argument

The write-up gets graded harder than the code in many cases. This surprises candidates, but it shouldn’t. The panel’s question isn’t could you have done the work— by the time we’re reading your submission, the work exists. The question is can you communicate it to a skeptical reader fast. That’s most of the senior IC job. The 13-day project is a sample of how you’ll write your team’s design docs, your release post-mortems, your half-year reviews. Bad write-ups predict bad design docs more reliably than almost any other signal we have.

The recover move, if you’re on the last day and realize your draft is a recap: throw it out. Write the headline finding in one sentence at the top. Spend two paragraphs making the case for it. Use the rest of the document to support the case, not to narrate your time. Cut every sentence that begins with “next, I…” or “on day…” — those are recap markers. Submit the shorter document. Candidates routinely panic about the write-up being too short; in three years of reviews, we have never marked down a submission for being too brief.

// 04No eval

Of the four mistakes, this is the one trending the right direction. Six years ago we’d see eval-free submissions in roughly 70% of senior IC project reviews. This year that number is down to ~30%, and a meaningful chunk of the remainder include at least a single-number eval. That’s progress.

What we still rarely see — and what would meaningfully distinguish your submission — is eval rigor commensurate with the claims being made. If your submission claims that method A beats method B, the eval should have: a baseline that A and B are both compared against, a held-out set neither method has seen, multiple seeds where stochasticity matters, and a brief discussion of what failure modes the eval might be missing. None of this is hard; almost none of it is present in the average submission.

The recover move, if you’re on day 12 and don’t have a real eval: build one. Even one hour of focused eval work — held-out set, baseline number, multi-seed variance — substantially upgrades the rest of the submission. It also signals research instincts that nothing else in the project can signal. We have moved candidates from “borderline reject” to “advance” on the strength of a clearly described day-12 eval that the candidate added under time pressure.

// 05What we’d add for 2026

One mistake we’d put on the list if we were drafting it today, less than a year after the four above were finalized: using AI tools without saying how. Most strong candidates are now using Claude or Cursor or one of their cousins during the 13-day project, and that’s fine. What’s not fine is pretending they didn’t. Panels can tell, and the pretense is a worse signal than the usage.

If you used an AI tool, say so in the write-up — briefly, in the methodology section. “I used Cursor for the boilerplate of the training loop; the training logic and the eval were written from scratch; I used Claude to draft three different versions of the data-curation script and picked the one that survived my tests.” That kind of disclosure is what senior IC engineering work looks like in 2026, and the panel grades it that way. The candidates who hide it are evaluated against the candidates who don’t, and the comparison isn’t flattering.

If you’re heading into Stage 3 in the next quarter, the interview guides include the per-track scope advice we give privately. The screening overview lives on the Top 3% page. Next week’s piece will be on the seven failure modes of production tool-using agents. Subscribe at the bottom of the blog page for it.