Tell me about a time when you worked against tight deadlines and didn't have time to consider all options before making a decision.
Asked at:
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 speed matters more than perfect information. They want to see whether you can make a sound decision under uncertainty, calibrate risk, and keep moving without becoming reckless. Strong answers show judgment: you identified what mattered most, chose an approach that was good enough for the moment, and managed the consequences of that choice.
“Describe a situation where you had to make an important call before you had all the information you wanted.”
“Tell me about a time you had to choose a path forward quickly and couldn't fully analyze every alternative.”
“Have you ever had to ship or decide under serious time pressure? How did you handle the tradeoffs?”
“What's an example of a decision you made with incomplete information because waiting would have put the deadline at risk?”
Key Insights
- You do not need a story where you were magically right on the first try. A strong answer often shows that you made a bounded decision, reduced risk, and adjusted quickly as new information came in.
- You should explain why the deadline was real and consequential. If the time pressure sounds artificial or self-created, the story often reads as poor planning rather than strong judgment under pressure.
- When you had to move fast, interviewers care a lot about how you narrowed the decision space. Show the small amount of analysis you did have time for, what assumptions you made, and how you contained downside risk.
What interviewers probe atlevel
Top Priority
At junior level, interviewers want to see that you can avoid paralysis, use available guidance, and make a practical decision without pretending you had complete certainty.
Good examples
🟢I didn't have time to explore every path, so I compared the two most realistic options, checked my assumptions with my teammate, and chose the lower-risk one that fit the deadline.
🟢I narrowed it down to the simplest change that solved the immediate issue and avoided touching unrelated parts of the system since I knew that would increase risk.
Bad examples
🔴I just picked the first option that seemed okay because we were in a rush, and I figured we could clean it up later if needed.
🔴There wasn't time to think through it, so I went with what I personally preferred and started coding.
Weak answers confuse speed with impulsiveness; strong answers show a deliberate shortcut in analysis, not no analysis at all.
Valuable
You don't need a huge stakeholder story at junior level, but you should show that you surfaced uncertainty early instead of silently making risky assumptions.
Good examples
🟢I quickly checked with my teammate or lead to confirm the tradeoff before moving, so we were aligned on why we were choosing speed over completeness.
🟢I was upfront that I hadn't evaluated every option, explained what I was choosing and why, and made sure someone else knew the main risk.
Bad examples
🔴I just made the change and mentioned it later in standup because there wasn't time to ask everyone first.
🔴I didn't want to bother anyone, so I handled it myself and assumed the team would be fine with the decision.
Weak answers hide uncertainty; strong answers communicate enough for shared situational awareness.
Even at junior level, a strong answer owns the result and shows you learned how to make better fast decisions next time.
Good examples
🟢I owned the decision and followed through after release, and I came away with a clearer sense of when to ask for a quick second opinion versus deciding on my own.
🟢The experience taught me to separate must-check risks from nice-to-have analysis, which has helped me make faster decisions without feeling rushed.
Bad examples
🔴It worked out in the end, so I think the main lesson was that you sometimes just need to move fast.
🔴The deadline was the reason we had issues, but overall I did what I was told and got it done.
Weak answers either dodge ownership or learn the wrong lesson; strong answers show accountable reflection that improves future judgment.
Example answers atlevel
Great answers
In my internship, we found a bug in our signup flow two days before a student demo, and I was asked to help fix it. I didn't have time to evaluate every possible cleanup, so I focused on the two most likely causes, checked my thinking with a more experienced engineer, and chose the smaller code change that only affected the failing step. I tested the main user path and one rollback path because I knew we couldn't risk breaking the whole flow right before the demo. I also posted a short note in our team chat explaining what I changed and what I wasn't fully sure about. The fix held during the demo, and afterward we did a fuller cleanup of the underlying issue. What I learned was that under time pressure, it's better to make a narrow, reversible decision than to rush into a broad fix.
At a small consulting shop I was the engineer assigned to deliver a client-facing reporting widget the day their marketing campaign went live, and half the features in the spec were still undecided an hour before launch. I didn't have time to evaluate every possible approach, so I negotiated with our project manager to drop the nonessential visualization options and focus on a fast, well-tested core report that covered the campaign’s primary KPI. I wrote a small automated test suite for the main path, added a fallback that showed raw data if the fancy UI failed, and sent the client a clear note about what we’d delivered and what we’d deferred. The campaign launched on schedule and the client appreciated getting the key insight on time; we later brought back the additional visuals as a scheduled follow-up. I learned that under tight deadlines, explicitly trading scope for reliability and communication keeps both the product and the client relationship intact.
Poor answers
On a class project, we had to finish our feature the night before presenting, so I just picked an approach and implemented it. There were probably other options, but we didn't really have time to compare them, and I think moving quickly was more important. I pushed the changes and told my teammates the next morning what I had done. It worked for the presentation, so overall I think that was the right call.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid November, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.