Tell me about a strategic decision you had to make without clear data or benchmarks.
Asked at:
DoorDash
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you operate when certainty is unavailable and waiting for perfect information is not an option. They want to see how you frame ambiguity, make reasonable assumptions, manage risk, and take responsibility for the consequences of a directional choice. At higher levels, they are also listening for whether the decision matched the scope of your role and whether you created a path to learn quickly after committing.
“Describe a time you had to make an important call even though the data was incomplete or unreliable.”
“Tell me about a decision where you couldn't wait for certainty and had to move forward anyway.”
“Have you ever had to choose a direction without a clear benchmark for what good looked like? What did you do?”
“What's an example of a bet you made when the evidence was mixed or missing?”
“Walk me through a situation where you had to use judgment instead of hard data to decide on a path.”
Key Insights
- You do not need a dramatic bet-the-company story, but you do need a decision that actually mattered. If the choice was trivial or easily reversible, it will be hard to show judgment under uncertainty.
- Do not answer this as if the point is that you were right. The stronger story is usually about how you made a sound decision process despite incomplete information, including what assumptions you made and how you reduced downside risk.
- You should make the uncertainty legible. Name what data was missing, why it was missing, what signals you used instead, and how you planned to learn after the decision rather than pretending you somehow had certainty.
What interviewers probe atlevel
Top Priority
A strong answer shows that you did not just make a choice; you made it in a way that kept the blast radius manageable.
Good examples
🟢Because we were unsure about the right behavior, I added the new path behind a flag so we could test it safely before making it the default.
🟢I chose a simpler first version and kept the old behavior available so we could compare issues and avoid blocking the release if my assumption was wrong.
Bad examples
🔴I picked the more complete implementation even though we weren't sure users needed it, because it seemed better to finish it all at once.
🔴I chose to replace the old code path immediately so we wouldn't have to maintain two versions.
Weak answers treat uncertainty as a reason to gamble; strong answers pair decisions with containment and reversibility.
Pick a decision with real local impact, even if the scope was small; interviewers are looking for ownership relative to your level, not executive strategy.
Good examples
🟢On a feature I owned, we had no benchmark for whether to build a generalized workflow or a one-off version, and I had to recommend the simpler path because the deadline was close and the feature was still unproven.
🟢I was responsible for a migration step in a small service, and there wasn't good data on usage patterns, so I chose a backwards-compatible rollout approach that traded speed for lower risk to users.
Bad examples
🔴I had to choose between two logging libraries for a side tool, so I picked the one I had used before and moved on.
🔴There wasn't much guidance on naming our API fields, so I decided to keep the old naming style because it seemed simpler.
Weak answers choose low-stakes preferences; strong answers show a real product, delivery, or reliability tradeoff that mattered within a junior-sized scope.
Valuable
Even at junior level, interviewers want to know whether you checked if the call worked rather than assuming it did.
Good examples
🟢After release, I checked the error reports and asked the support contact whether the simplified flow reduced confusion, which helped confirm the smaller version was the right first step.
🟢I followed up with my lead and compared the issues we saw against the risks I had expected, and that helped me make a better call on the next feature.
Bad examples
🔴After I made the choice, we shipped it and nobody complained, so I took that as success.
🔴I don't remember exact results, but the project moved forward, which was what mattered.
Weak answers equate completion with success; strong answers verify outcomes and extract a reusable lesson.
Example answers atlevel
Great answers
On a small onboarding feature I owned, we had to decide whether to build a flexible setup flow that covered several future cases or a much simpler version for the current release. We didn't have user data yet because this feature was brand new, so I looked at support tickets from similar parts of the product and talked with a designer about where new users were most likely to get stuck. Based on that, I recommended the simpler version first, with the new behavior behind a flag so we could expand it later if needed. That let us ship on time without replacing the old path immediately. After release, I checked the support feedback and error reports for two weeks, and the simpler path handled the common cases well, so we kept it and only added one missing edge case later.
On a small mobile feature I owned for a health-focused app, we had to decide whether to add analytics now so we could learn how people used it, or wait because our privacy rules meant we couldn't collect identifiable data without explicit consent. There were no benchmarks to tell me which approach was safer or more useful, so I talked with our product manager, legal counsel, and a senior engineer to map the risks and benefits. I recommended sending only a tiny set of anonymous, aggregated events that couldn't be tied to a person, and pairing that with a clear opt-in prompt for richer tracking later. I also wrote a short implementation checklist so the team would avoid accidentally logging any personal data. After the release we got just enough high-level insight to prioritize two small usability fixes, and there were no privacy incidents or user complaints — which reassured us to expand tracking only after testing the opt-in flow.
Poor answers
I had to make a strategic decision on a feature when we didn't really have benchmarks, and I chose the more complete implementation because it seemed better to do it once. I didn't want to spend time on a temporary version that we'd just throw away. We shipped it, and overall it was fine because nobody raised major issues after that. I think it showed that I'm comfortable making decisions quickly.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid November, 2025
DoorDash
Manager
Early January, 2025
Amazon
Mid-level
Early November, 2024
Amazon
Mid-level
Tell me about a strategic decision you had to make without clear data or benchmarks. How did you make your final decision? What alternatives did you consider? What were the tradeoffs of each? How did you mitigate risk?
Hello Interview Premium
Your account is free and you can post anonymously if you choose.