Give me an example of when you had to make an important decision and had to decide between moving forward or gathering more information.
Asked at:
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess judgment under uncertainty: can you tell when you know enough to act, and when the risk is high enough that you should slow down and learn more first. They are also looking for how you frame tradeoffs, not just whether the outcome was good. Strong answers show calibrated decision-making, appropriate urgency, and ownership of the consequences.
“Tell me about a time when you had to make a call before you had complete information.”
“Describe a situation where you had to balance acting quickly against doing more investigation.”
“Have you ever had to decide whether you knew enough to proceed? What did you do?”
“Walk me through an important decision where the harder part was figuring out whether to move now or learn more first.”
“What's an example of a time you chose to pause for more information instead of charging ahead, or the reverse?”
Key Insights
- You do not need a dramatic all-or-nothing story. A strong answer often shows how you reduced uncertainty just enough to make a sound decision, rather than waiting for perfect information.
- Be explicit about what made the decision hard: conflicting signals, time pressure, irreversible cost, customer impact, or team dependencies. If you skip that, the story can sound like routine execution rather than judgment.
- Do not present speed as automatically virtuous or caution as automatically virtuous. Interviewers want to see that you matched the amount of investigation to the stakes, reversibility, and timeline.
What interviewers probe atlevel
Top Priority
Show that when you needed more information, you knew how to get it efficiently instead of just waiting for someone else to tell you what to do.
Good examples
🟢I identified the one assumption I was missing, ran a quick test to check it, and used that result to decide.
🟢I asked a more experienced engineer a very specific question about the tradeoff, which gave me enough context to move forward confidently.
Bad examples
🔴I wasn't sure, so I posted a question in chat and waited until someone responded before doing anything else.
🔴I read a lot of documentation and examples, but I didn't narrow down which question I was trying to answer before spending the time.
Weak answers make uncertainty someone else's problem or wander broadly; strong answers show targeted steps to answer the specific unknown.
Even at junior level, you should sound like you were responsible for thinking through the choice and following it through, not just obeying instructions.
Good examples
🟢I brought my recommendation to my lead with the tradeoffs I saw, then carried out the next steps and tracked whether the choice held up.
🟢I owned the part of the decision in my scope, made sure the change was monitored, and surfaced results back to the team.
Bad examples
🔴My lead suggested we should probably move ahead, so I did that and considered the decision made.
🔴I raised the concern to my manager and waited for them to tell me whether I should continue or investigate more.
Weak answers outsource judgment; strong answers show appropriate independence and follow-through for the candidate's level.
Valuable
You do not need executive polish, but you should show that you made your reasoning understandable to the people depending on your work.
Good examples
🟢I explained that I was pausing briefly because there was one production risk I wanted to rule out, and I gave a clear update once I had the answer.
🟢When I moved forward, I summarized the tradeoff in simple terms so my lead knew what I had checked and what uncertainty remained.
Bad examples
🔴I just told my teammate I was going ahead because I felt pretty good about it, and I didn't get into all the details.
🔴I asked for more time to investigate, but I didn't explain what I was trying to learn or when I expected to decide.
Weak answers leave others guessing about rationale and timing; strong answers make the decision process legible and actionable.
Even in a straightforward story, show that you learned how to judge when to act and when to investigate a bit more next time.
Good examples
🟢The experience taught me to identify the one or two questions that actually matter before asking for help or diving into research.
🟢I learned that I don't need complete certainty for reversible decisions, but I do need to be more careful when customer-facing behavior could change.
Bad examples
🔴It worked out, so I took that as confirmation that my original instinct to move quickly was right.
🔴We ended up delaying, but at least we were safe, so I think gathering more information is usually the better choice.
Weak answers overgeneralize from outcome; strong answers extract a reusable decision principle.
Example answers atlevel
Great answers
In my first few months on a backend team, I was asked to update how we retried failed requests to a partner service. I could have just copied the pattern from another job, but I noticed this flow was customer-facing, so if I got it wrong we could accidentally create duplicate actions. I spent about an hour checking logs from recent failures and asked a senior engineer one focused question about how idempotency worked in our system. That gave me enough information to change the retry behavior safely without turning it into a big research task. I shipped it with extra logging, watched the first day of results, and saw the failure rate drop without creating duplicates. The main thing I learned was that I don't need total certainty, but I should pause and validate the one assumption that could make a small task risky.
At a small nonprofit where I’m the only frontend engineer, I discovered on launch day that keyboard navigation skipped a critical form control for donors with assistive technologies. I could have slapped a quick tabindex fix and shipped it, but accessibility failures directly undermine our mission, so I took about 45 minutes to reproduce the problem with a screen reader and check the markup in different browsers. I then asked our product manager two quick questions about whether any third‑party scripts controlled that form, which helped me avoid a superficial fix that would soon be overridden. With that confidence I pushed a focused change behind a short rollout and monitored error reports and support messages; donations stayed steady and we got zero accessibility complaints after. I learned to balance acting quickly with a handful of practical checks when users’ ability to use the product is at stake.
Poor answers
I had to decide whether to move forward on a bug fix or gather more information, and I chose to just implement it because the issue seemed straightforward. I didn't want to slow things down by asking too many questions, especially since the team was busy. After I merged it, a teammate pointed out there was another edge case, so we made a quick follow-up change. Overall I think moving quickly was the right call because we got the main fix out fast.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late January, 2025
Mid-level
Mid January, 2025
Meta
Mid-level
Mid November, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.