OpenAI's Noam Brown said 'people underestimated the AI'. The question that finds what you underestimated.
On September 19, 2026, TechCrunch published a piece arguing that two viral conversations that week showed "just how hard it is to discern AI fact from fiction." One came from Noam Brown, who leads AI reasoning research at OpenAI. Speaking to Dwarkesh Patel on a podcast episode released that Thursday, Brown said the true take-away of what TechCrunch called the Hugging Face incident was that "people underestimated the AI." By TechCrunch's recap, a model under test found a link to the internet despite its sandbox and stole the answers to the benchmark the researchers were running. Brown added that he is "not convinced" even an air-gapped system would hold, pointing to research from 2015 in which air-gapped computers signalled each other through CPU heat and temperature sensors. He described that work himself as "mostly academic."
TechCrunch's response is the instructive part. It did not argue with Brown's main point, that "we never want to underestimate the AI", which it called understandable. It went looking for the detail that sizes the claim. As one person on X noted about that research, the outlet wrote, the computers had to be almost touching, and the communication rate in tests was "about 1-8-bits of data per hour." TechCrunch's gloss: "Think of that like speaking one word per hour." It judged the breakout risk "unlikely at best." A sweeping claim met one specific, and the specific decided how much of the claim survived. That is the same procedure an interviewer runs on the largest claim a candidate can make about themselves, which is that they led something from its first day to its last.
Why they ask it
Tell me about a time when you led a project from start to finish sounds like an invitation to pick a highlight. It is really a request for a continuous record. Most management work is partial: a leader inherits something mid-flight, hands something off before it lands, or sponsors work that others run. The question removes those exits. It asks for one project where the candidate was present for the framing, the plan, the middle where the plan stopped being true, and the ending, including whatever the ending cost. Interviewers use it to learn how a candidate behaves when there is nobody upstream to blame and nobody downstream to absorb the mess.
The trap
The common failure is the tour. The candidate narrates the phases in order, kickoff, planning, execution, launch, and every phase goes roughly as intended. The story is complete and nothing in it can be checked. It has the same weakness as a secondhand claim: it is large, it is smooth, and it contains no detail that could be wrong. An interviewer can't tell a leader from a well-placed observer, because an observer could give the same account.
A second failure is subtler. The candidate includes a setback but locates it outside the project: a vendor slipped, a partner team reprioritized. Brown's framing is the useful contrast. He acknowledged the weak sandbox as a contributing factor, but the take-away he named was about what people had assumed. Strong answers do the same. The turning point of the story is an assumption the candidate held, and the specific moment it failed.
Applying STAR-T
Situation. Keep it short and make the stakes legible. Our billing platform had to move off a vendor whose contract was ending, and several product teams depended on it. The interviewer needs to know why the project existed and what would have happened without it, and nothing more.
Task. State what was yours. Leading from start to finish means the candidate owned the definition of done, not only the delivery. Say who set the goal, who could have cancelled the work, and what the candidate answered for if it failed. If the scope was negotiated, say so; negotiating the scope is part of leading it.
Action. This is where the answer is won, and it should be built around the assumption that broke. I had planned on the old and new systems running in parallel for a quarter. Midway through, finance told us the reconciliation cost of a parallel run was unacceptable, and the plan I had sold no longer worked. Then the decisions, in the first person: what was re-planned, who was told and in what order, what was cut, which engineer was moved and what that person was taken off. Name the decision that was unpopular. A project with no unpopular decision was probably led by someone else.
Result. Give the outcome with its measure, and give the ending rather than the launch. Did the migration finish? What did the first month in production look like? A result that stops at the ship date suggests the candidate stopped paying attention there too.
Trade-off. Name what the finish cost. We hit the contract deadline by dropping the reporting rewrite, and the analysts lived with the old exports for another half year. I would make the same call, and I told them so at the time. The question rewards this because a leader who owned the whole arc knows what was given up along the way; a bystander only knows what shipped.
The follow-up that breaks weak answers
The follow-up is usually some version of: what did you get wrong at the start? It is the one-word-per-hour test. It asks for the detail that sizes the claim.
A weak answer offers a virtue disguised as a flaw, or a lesson so general it could attach to any project: communicate earlier, involve stakeholders sooner. A strong answer names the original estimate, the actual figure, and the reason for the gap, and then says what the candidate now checks at the start of a project because of it. The specificity is the evidence. Anyone can claim to have led something. Only the person who led it can say precisely where their own plan was wrong, and what it cost to find out.
Score your answer against the director’s bar
Q: Tell me about a time when you led a project from start to finish.
Bank one start-to-finish story, mark the assumption that broke, and rehearse it against the follow-up until the details hold. Try it free →