Describe a situation where you made an important business decision without consulting your manager.
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can exercise judgment and ownership when the usual approval path is unavailable, unnecessary, or too slow. Interviewers want to understand how you balanced autonomy with risk: did you make a thoughtful decision in the business's interest, or did you bypass your manager carelessly? The strongest answers show sound reasoning, appropriate escalation boundaries, and proactive communication after the fact.
“Tell me about a time you had to make a significant call without being able to get your manager's input first.”
“Have you ever made a business-critical decision on your own? Walk me through what happened.”
“Describe a situation where you chose not to wait for your manager before acting on an important issue.”
“What's an example of using your own judgment on a high-stakes decision instead of escalating immediately?”
Key Insights
- You do not get points for simply acting alone. You need to show why it was appropriate not to consult your manager in that moment, and how you contained risk while still moving the business forward.
- A good answer is rarely about rebellion. Strong candidates frame the decision as responsible judgment under constraints, not as proving they could operate without oversight.
- You should make clear what made the decision a business decision, not just a technical preference. Connect your choice to customer impact, revenue, cost, timing, risk, or team capacity.
What interviewers probe atlevel
Top Priority
The best junior answers show independence without pretending every decision should be made solo.
Good examples
🟢My manager was in transit and we had already discussed the general principle for customer-impacting issues, so I made a bounded call within that guidance.
🟢I knew this was within the decision space my lead had encouraged me to own, and the cost of delay was higher than the cost of acting.
Bad examples
🔴I did not ask my manager because I wanted to prove I could handle things on my own.
🔴My manager usually asks a lot of questions, so I skipped that and made the call myself.
Weak answers frame autonomy as avoidance of oversight; strong answers show calibrated independence within understood boundaries.
Interviewers want to see that you did not guess blindly; even as a junior engineer, you should show how you gathered enough signal to make a safe call.
Good examples
🟢I checked recent customer tickets, confirmed the issue was affecting active users, and compared the expected effort before deciding to shift my work.
🟢I talked to the on-call engineer and reviewed usage data so I could tell whether delaying the release was a reasonable tradeoff.
Bad examples
🔴I trusted my instincts because I had worked on the code before and did not think I needed more input.
🔴I made the decision quickly since waiting would have slowed things down, and I assumed the business impact would be positive.
Weak answers rely on confidence; strong answers show lightweight but real validation before acting.
At junior level, the story should be meaningful but still within a reasonably bounded area where independent judgment was appropriate.
Good examples
🟢During a support surge, I chose to pause a low-value enhancement and spend two days fixing a customer issue affecting renewals, then informed my lead with the rationale.
🟢I noticed a release would break onboarding for a new customer segment and decided to hold my team's part of the rollout until we had a safer default, even though it delayed a minor planned improvement.
Bad examples
🔴I decided to rename a feature before launch without asking my manager because I thought it sounded better for customers.
🔴My manager was busy, so I chose which small bug to fix first and considered that an important business decision.
Weak stories inflate routine execution choices; strong stories involve a real tradeoff with visible business impact, even if the scope is still modest.
Valuable
Even when you act quickly, you should show that you kept people informed rather than surprising them.
Good examples
🟢After making the call, I sent a concise update explaining what I changed, why I did it, and what I was watching for.
🟢I informed my lead the same day and made it easy for them to see the reasoning and any remaining risks.
Bad examples
🔴I told my manager in our next one-on-one since the issue was already handled by then.
🔴I did not want extra opinions, so I only shared the decision after the change was live.
Weak answers normalize surprise; strong ones show prompt, transparent communication that preserves trust.
Example answers atlevel
Great answers
In my first year, I was working on an onboarding flow when I noticed support tickets from trial users who were getting stuck at the payment step. My manager was in an all-day offsite, and the release with a new reporting feature was scheduled for that afternoon. I checked the ticket volume, confirmed with the on-call engineer that the issue was current, and realized the reporting feature was much less urgent than fixing onboarding, so I asked to hold my part of the release and spent the day on a safe fix. I sent my lead and manager a note explaining the tradeoff, the expected customer impact, and my rollback plan if the fix behaved badly. The fix reduced the ticket volume over the next two days, and my manager later told me the important part was that I acted within a clear customer-impact principle instead of waiting for permission.
At my previous role building features for a K–12 learning app, I noticed our error logs included unredacted student identifiers and the logs were being shipped to a third‑party aggregator. My manager was out at a conference and I couldn't reach them, but I knew exposing student data could violate our privacy policy and harm our users. I quickly pushed a small change to mask identifiers in the logging function and flipped the aggregator export off in our configuration, then opened a ticket describing the risk, the exact code change, and a plan to run a short audit of other loggers. I also emailed my manager and the privacy officer to explain what I did and why, and left the change behind a feature flag so we could revert it if needed. The fix prevented further sensitive data from leaving our systems and the team later used my ticket to build a permanent, automated log-redaction check.
Poor answers
I made an important business decision when my manager was busy and I decided to keep a release moving instead of asking a lot of questions. I had a pretty good sense that the feature would help users, so I did not want to slow things down waiting for approval. I shipped it and then mentioned it in our next one-on-one. It worked out fine, so I think that showed I can be independent.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late October, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.