Tell me about a time you did something without discussing with your manager first
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests judgment around autonomy: when you chose to act independently, how you assessed risk, and whether you still kept your manager appropriately informed. Interviewers are usually not looking for rebellion; they want to understand whether you can distinguish between decisions you should make yourself and decisions that need alignment. Strong answers show initiative plus communication discipline, not just speed or confidence.
“Describe a time you made an important call without checking with your manager first.”
“Have you ever acted before getting your boss's input? What was the situation?”
“Tell me about a situation where you had to use your own judgment instead of waiting for your manager.”
“What's an example of a decision you made independently that you later explained to your manager?”
“When have you chosen to move forward without prior approval from your manager?”
Key Insights
- You do not need a dramatic act of defiance. The best stories usually show sound judgment about where your decision rights started and stopped, and how you managed the downside.
- Make the risk tradeoff explicit. Explain why waiting for your manager would have been costly, what you did to keep the decision reversible, and how you informed them once action was underway.
- Avoid telling a story whose punchline is simply 'I was right.' The stronger signal is that you acted independently in a way that protected the team, respected context, and built trust afterward.
What interviewers probe atlevel
Top Priority
For juniors, independence is strongest when paired with small blast radius, verification, and a fallback if the choice is wrong.
Good examples
🟢I tried the change in a test environment first, added a simple check to confirm the behavior, and only then applied the fix and messaged my manager.
🟢I chose a temporary workaround that could be easily undone, documented what I changed, and asked for review afterward in case there was a better long-term fix.
Bad examples
🔴I made the fix directly in production because it was the fastest path and I didn't think the change was big enough to need extra checks.
🔴I merged the update before full testing because I wanted to avoid bothering my manager for approval.
Weak answers celebrate speed alone; strong answers show the candidate understood that independent action is only responsible if the downside is controlled.
At junior level, interviewers want to see initiative within clear bounds, not freelancing on high-risk decisions you were not ready to own.
Good examples
🟢My manager was in meetings and a test environment issue was blocking me, so I gathered the relevant logs, tried the approved recovery steps, and restored the environment before updating them.
🟢I noticed a bug in a low-risk internal tool, confirmed the fix pattern with existing code and a teammate, and shipped a small patch rather than waiting a day for my manager to review the plan.
Bad examples
🔴I changed the deployment process on my own because it seemed inefficient, and I figured my manager would hear about it later if it worked.
🔴My manager was offline, so I decided to rewrite part of the feature instead of asking anyone since I wanted to move fast.
Weak answers confuse independence with bypassing guardrails; strong answers choose action in situations where the risk is bounded and the candidate's authority is credible.
Valuable
Interviewers like to see that once you acted on your own, you stayed with the consequences instead of treating the action as a one-off.
Good examples
🟢I monitored the result, confirmed the blocker was actually gone, and wrote down what I changed so others could follow it later.
🟢I checked back with the teammate who was affected to make sure my solution solved the real issue and didn't create new confusion.
Bad examples
🔴I made the change and then handed it off since the important part was getting it done quickly.
🔴After I fixed the issue, I assumed the team would let me know if there were any problems.
Weak answers stop at action; strong answers include verification, cleanup, and responsibility for the full outcome.
Be straightforward about why you acted alone; interviewers notice when a candidate tries to dress up impatience as leadership.
Good examples
🟢I knew this was within my working area, the risk was limited, and waiting would have blocked others for the day, so I made the call and updated my manager right after.
🟢I didn't consult first because my manager was unavailable and the issue was time-sensitive, but I stayed within the documented process and asked for feedback afterward.
Bad examples
🔴I didn't ask my manager first because I usually know what they would say anyway.
🔴There wasn't really time to discuss it, and honestly I prefer to just make decisions myself.
Weak answers sound self-justifying; strong answers candidly explain the constraints and show awareness of the boundary they chose not to cross.
Example answers atlevel
Great answers
On a recent project, my manager was out for the afternoon and a broken test environment was blocking both me and another new engineer. I checked our team docs, compared the recent changes, and found that a configuration value had been updated incorrectly. Because the fix was small and matched our normal process, I corrected it in the test environment, reran the checks, and confirmed both of us were unblocked. Right after that, I sent my manager a message explaining what I changed, why I felt it was safe, and asking them to let me know if they would have preferred a different approach. They told me that was the right level of initiative and asked me to add the recovery steps to the team notes, which I did.
Last month we had a new intern scheduled to start at noon and I noticed our onboarding docs were out of date, while my manager was in back-to-back meetings and unreachable. I walked through the repo like a brand-new teammate, discovered a missing environment variable and an outdated dev-start command that would have eaten up the newcomer's first afternoon, and decided to fix the docs and add a small start-up script. I opened a pull request with the updated README, the script, and a short explanation of what I changed, then personally paired with the intern to confirm they were up and running in about 30 minutes. I messaged my manager and the team channel immediately explaining my changes and why I acted, and my manager later asked me to fold the steps into our official onboarding checklist, which I did.
Poor answers
My manager was busy and I didn't want to wait, so I just changed the way our feature was implemented. It worked on my machine and I was pretty sure it was the better approach anyway. I told my manager in our next one-on-one and showed them the progress I'd made. They had a few questions, but overall I think it was good that I kept things moving.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early November, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.