What do interviewers evaluate in Velocity in Ambiguity questions?

Interviewers listen for signals like: Have you shipped something real on a compressed timeline where the requirements were genuinely unsettled? Do you have machinery for ambiguity - named assumptions, reversible-versus-irreversible sorting, timeboxes - or just tolerance for it? When the ground shifted (a requirement flipped, a model changed, a launch moved up), did you re-plan cleanly or thrash?

gitGood.dev

OpenAIAdvanced Premium

Velocity in Ambiguity (OpenAI Culture)

OpenAI ships at frontier pace into problems nobody has solved before - requirements shift weekly and the spec doesn't exist. Interviewers test whether you produce velocity or need certainty.

About this theme

OpenAI's engineering culture is defined by the combination of two pressures that most companies only face one of. The first is speed: the company is famous for compressed timelines, launches that assemble in weeks, and a bias toward shipping and iterating in public. The second is novelty: much of what's being built has no precedent - the requirements can't be fully specified because nobody has operated this class of system before, model behavior shifts under your feet between checkpoints, and a research result can invalidate a quarter's assumptions in a day. Velocity in ambiguity is the resulting trait: the ability to make real forward progress - not motion, progress - when both the goal and the ground are moving. Interviewers probe for the mechanics, not the vibe. Anyone can say they're comfortable with ambiguity; strong candidates can show the machinery they use to convert it into decisions: choosing the assumption to bet on and writing it down, distinguishing reversible from irreversible choices and spending deliberation only on the latter, timeboxing investigation, building the thinnest thing that generates real information, and re-planning without whiplash when the ground shifts. They also probe the failure mode on each side. Candidates who need a spec, a mature process, or a settled roadmap stall out - but so do candidates who confuse velocity with recklessness, shipping fast by skipping the checks that were actually load-bearing. The bar is judgment at speed: knowing which corners are safe to cut this week and which ones are how you end up on the front page.

What interviewers are evaluating

→Have you shipped something real on a compressed timeline where the requirements were genuinely unsettled?
→Do you have machinery for ambiguity - named assumptions, reversible-versus-irreversible sorting, timeboxes - or just tolerance for it?
→When the ground shifted (a requirement flipped, a model changed, a launch moved up), did you re-plan cleanly or thrash?
→Do you build thin things that generate information, or do you build big things on unvalidated guesses?
→Do you know which corners are safe to cut at speed - and can you name ones you deliberately didn't cut?
→Can you keep others oriented while things are moving - communicating what's decided, what's assumed, and what's still open?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about the most ambiguous project you've delivered. How did you decide what to build?
?Describe shipping something on a timeline you initially thought was impossible.
?Tell me about a time requirements changed dramatically mid-project. What did you do?
?How do you decide when you have enough information to act?
?Tell me about a bet you made under uncertainty that was wrong. How did you recover?
?Describe cutting scope to hit a date. How did you choose what to cut?
?Tell me about a time you moved fast and it went badly. What do you do differently now?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: shipping the integration while the target moved

Prompt: "Tell me about the most ambiguous project you've delivered. How did you decide what to build?"

Situation: My company decided to build a customer-support copilot on top of a frontier model API, and leadership wanted it live for our biggest customer in six weeks - announced, in fact, before engineering had scoped it. The ambiguity was total: the model provider had a major version deprecation scheduled mid-project with behavior changes we couldn't test in advance, our customer couldn't articulate acceptance criteria beyond 'it should sound like us,' and nobody - including us - knew what failure modes mattered until we saw them. Halfway through, the provider also changed the pricing of the tier we'd planned on, breaking our unit-economics assumption.
Task: I was the tech lead of four engineers. The job was to ship something real and safe in six weeks into a space where the requirements were unspecifiable up front, without betting the customer relationship on guesses.
Action: I ran the project on explicit ambiguity machinery rather than a plan that would be fiction by week two. First, I split every open question into two piles: decisions that were cheap to reverse (prompt structure, retrieval approach, UI shape) and decisions that were expensive to reverse (data retention policy, whether agent responses could go to customers unreviewed, the API contract we exposed internally). The reversible pile got decided same-day by whoever was closest to it, recorded in a running decisions doc with the assumption it rested on. The irreversible pile - there turned out to be only three items - got real deliberation. Second, since 'sounds like us' wasn't a spec, I made the customer generate one without asking them to: in week one we shipped a throwaway harness that replayed 50 of their real historical tickets through three different configurations, and had their team grade outputs side by side. Their grades became the eval set - the spec was extracted from reactions to concrete artifacts, not from a requirements meeting. Third, I timeboxed the unknowns: two days on the retrieval question with a decision at the end of it regardless, because a defensible-now answer beat an optimal-later one. When the deprecation landed in week four and response behavior shifted measurably, the eval set caught it in an afternoon and we re-tuned against it in two days - the thing I'd built for specification turned out to be our regression net. When the pricing change broke our cost model, I cut the always-on summarization feature (reversible, low-graded in evals) rather than the human-review gate (irreversible if wrong) - and I wrote a half-page to stakeholders saying exactly what was cut, why, and what would bring it back.
Result: We shipped in six weeks and two days, human-review gate intact. The customer's own graders scored the shipped configuration at 87% acceptable-or-better against the eval set they'd built, and the copilot handled 40% of their tier-1 volume within a quarter. The decisions doc meant the two engineers who joined post-launch onboarded off it in days rather than archaeology. The eval-set-as-spec pattern and the reversible/irreversible split became how the team ran every subsequent AI project - and the summarization feature I'd cut shipped calmly a month later, priced against the new reality.

Why this works

What makes this strong: (1) the machinery is explicit and reusable - reversible/irreversible sorting, same-day decisions on the cheap pile, timeboxed unknowns, assumptions written down - which is what separates operating in ambiguity from merely surviving it; (2) the spec problem is solved the frontier way: extract requirements from graded concrete artifacts, which then doubles as the regression net when the model shifts - exactly the shape of problem OpenAI teams face; (3) speed never eats the load-bearing check - under two separate shocks, what got cut was the reversible feature, never the safety gate, and each re-plan came with a crisp communication. Velocity with judgment, demonstrated rather than claimed.

WEAK

Weak: needs the ground to stop moving

Prompt: "Tell me about a time requirements changed dramatically mid-project. What did you do?"

Situation: I was building a reporting feature and about halfway through, product changed the requirements significantly - a different data model and a new set of stakeholders with their own asks.
Task: I needed to figure out how to deal with a project that kept changing under me.
Action: Honestly, my first step was to push back on the process. I told my manager we needed a proper spec before I wrote more code, because building against moving requirements is how you waste engineering time. I paused development and scheduled sessions with the stakeholders to get everything nailed down - it took about three weeks to get a document everyone signed off on. I also asked that any future changes go through a formal change-request process so this couldn't happen again. Then I built exactly what the spec said.
Result: We delivered about six weeks later than originally planned, but what we shipped matched the signed-off spec, so I consider it a success. The change-request process protected the timeline from there on - though the stakeholders did complain that the final reports were missing things they'd realized they needed during the freeze.

Why this is weak

Why weak: (1) the response to ambiguity was to stop and demand certainty - three weeks of zero progress purchasing a spec, when a thin end-to-end slice shown to stakeholders in week one would have surfaced the same requirements while shipping something; (2) the process armor worked as designed and still produced the wrong thing - the closing complaint ('missing things they realized during the freeze') is the tell that freezing requirements doesn't remove ambiguity, it just delays its arrival until after launch; (3) 'I consider it a success' with a 6-week slip and unmet needs shows the candidate's definition of success is spec-compliance, not outcomes. In an environment where the spec cannot exist yet, this operating style stalls out entirely.

Common pitfalls

×Responding to ambiguity by manufacturing certainty - demanding specs, freezing requirements, adding process - instead of generating information by building.
×Claiming comfort with ambiguity without machinery. 'I'm adaptable' with no named assumptions, timeboxes, or reversibility sorting is a vibe, not a skill.
×Confusing velocity with recklessness - stories where 'fast' meant skipping the check that turned out to be load-bearing, told without that lesson.
×Thrashing dressed as agility: changing direction weekly without writing down what changed and why, leaving the team disoriented.
×Deliberating equally over everything. Spending the same care on a reversible prompt tweak as on an irreversible data-retention call shows no triage.
×No wrong bet in your history. Operating fast under uncertainty produces wrong bets; claiming none means you either moved slowly or aren't reflecting.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'how did you know you'd made the right call?', the honest answer is you didn't - explain how you made it cheap to be wrong instead.
→If asked 'what would you have done with twice the time?', name the corner you cut knowingly and its real cost - proving the cut was a decision, not an accident.
→If asked about a bet that went wrong, show fast detection and cheap reversal, not just the mistake - the recovery mechanics are the actual answer.
→If asked 'how did your team stay oriented?', point to the artifact - a decisions doc, a weekly what-changed note - because velocity without shared context is private velocity.
→If asked 'when would you slow down?', have the irreversibility answer ready: data deletion, external commitments, safety gates. Knowing where the brakes are is what licenses the speed.

Related behavioral themes

Ambiguity

General

Tested at Google, Anthropic, OpenAI, and any senior+ loop. Strong candidates show how they get curious; weak candidates show how they get anxious.

Bias for Action

Amazon LP

Speed matters. But the principle is reversible-vs-irreversible reasoning, not 'I work fast.' Get this distinction wrong and the answer reads as reckless.

Move Fast

Companies that test this theme

OpenAI

Software Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →