Tell me about a time you did something without discussing with your manager first

What specific decision did you make independently?

What analysis or judgment process did you use?

How did you communicate with your manager afterward?

How did you mitigate potential risks?

• What was the measurable impact of your decision?
• How did your manager react?
• What did you learn about exercising independent judgment?
• Would you handle a similar situation the same way?

Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, I was working on fixing bugs in our customer onboarding flow. My manager was on vacation for a week, and our only point of contact was for absolute emergencies. On day three of his absence, I discovered a bug that was preventing approximately 15% of users from completing account verification.

Task: As the engineer who had been assigned to this area, I needed to decide whether to wait four more days for my manager to return, escalate to his manager (whom I'd never worked with directly), or fix the issue myself. The bug was causing real customer impact, with support tickets piling up, but I'd never deployed a fix to production without approval before.

Action: I spent two hours thoroughly testing my fix in staging environments and documenting the root cause, impact, and solution. I verified the change was low-risk—a simple validation logic error—and wouldn't affect other systems. I then deployed the fix and immediately sent a detailed email to my manager explaining what I'd found, why I couldn't wait, and what I'd done. I also posted in our team Slack channel to keep everyone informed and monitored production closely for the next 24 hours.

Result: The fix resolved the issue immediately, and the support ticket volume dropped by 80% within hours. When my manager returned, he thanked me for taking initiative and said he would have made the same call. He appreciated the thorough documentation, which he used in our sprint retrospective as an example of good incident response. I learned that sometimes waiting for permission costs more than taking calculated risks, especially when I'd done my due diligence first.

Sample Answer (Mid-Level) Situation: I was leading the backend development for a new API service at a SaaS company when our cloud infrastructure costs suddenly spiked by 40% over three days. This happened during our fiscal year-end planning when my manager was in back-to-back budget meetings with senior leadership. Our infrastructure was costing an extra $15,000 per month, and the problem was actively getting worse.

Task: I needed to identify and resolve the cost spike quickly before it ballooned further and impacted our quarterly financial targets. The challenge was that optimizing our infrastructure typically required architectural review meetings and manager sign-off, especially for changes that could affect service reliability. However, waiting another week for the normal approval process meant potentially $50,000+ in unnecessary costs.

Action: I immediately pulled our infrastructure metrics and identified that a recent deployment had introduced an inefficient database query pattern that was triggering excessive read replicas. I designed a fix that involved adding proper indexing and query optimization without changing any core architecture. I tested thoroughly in staging, consulted with two senior engineers for a technical review, and documented a rollback plan. I then implemented the fix during off-peak hours and sent my manager a detailed write-up of the problem, my analysis, the solution I'd deployed, and the monitoring plan I'd put in place.

Result: The infrastructure costs dropped back to normal levels within 24 hours, ultimately saving the company approximately $180,000 annually. My manager appreciated both the initiative and the diligence I'd shown in getting peer review and preparing rollback options. This experience led to me being given more autonomy over infrastructure decisions and eventually led to my promotion to senior engineer. I learned that taking initiative means not just acting independently, but ensuring you've de-risked the decision appropriately first.

Sample Answer (Senior) Situation: As a senior engineer at an e-commerce platform, I was working on our checkout system when I discovered a race condition that could theoretically allow customers to complete purchases without payment processing in edge cases. My manager was traveling internationally for a conference with spotty connectivity, and our SVP of Engineering was also unavailable. This was a Friday afternoon, and I estimated we had maybe 24-48 hours before someone might exploit the vulnerability, especially since similar bugs had recently been discussed on security forums.

Task: I had to decide whether to wait until Monday for proper authorization to take down a critical revenue-generating service, attempt to reach leadership through emergency channels (potentially disrupting their important commitments for what might be a false alarm), or take action to secure the system based on my own assessment. The stakes were high either way—we processed millions in transactions daily, but an unnecessary service disruption would also be costly and damage trust in my judgment.

Action: I spent three hours doing a thorough security analysis and determined the vulnerability was real but hadn't been exploited yet based on our transaction logs. I assembled a small team of engineers I trusted, briefed them on the situation, and we developed a hotfix that would close the vulnerability without requiring downtime. I implemented additional monitoring to detect any exploitation attempts and deployed the fix during our lowest-traffic period at 3 AM. I documented everything extensively and sent detailed reports to my manager, the security team, and our VP of Engineering. I also stayed online for 12 hours monitoring the deployment and prepared a full incident report before anyone asked for it.

Result: The fix prevented what could have been a six-figure or seven-figure security incident, and no exploitation occurred. When my manager returned, he commended my judgment and later shared the incident in an engineering all-hands as an example of senior-level ownership. The security team worked with me to establish new protocols for similar situations, giving senior engineers more explicit authority to act in security scenarios. This incident demonstrated my readiness for a staff-level role, which I received six months later. I learned that true ownership means being willing to make difficult calls when you have the expertise and context, while still ensuring you're not acting recklessly.

Sample Answer (Staff+) Situation: As a Staff engineer at a cloud infrastructure company, I identified a critical architectural flaw in how we were approaching our multi-region deployment strategy that would fundamentally limit our ability to scale beyond our current growth projections. This discovery came during a period when our CTO and my direct manager were consumed with preparing for a major product launch that was three weeks away. The existing plan had already been approved at the executive level and had significant momentum, with multiple teams already beginning implementation work.

Task: I faced a decision that would have major organizational impact: continue with the approved plan that I believed was strategically flawed, or halt momentum on a multi-team initiative without explicit executive approval. The approved architecture would work for the launch but would require a costly re-architecture within 12-18 months. However, stopping or pivoting the current work would delay the launch and undermine several months of planning. I had to weigh the short-term business needs against long-term technical sustainability without the air cover of leadership approval.

Action: I spent a weekend creating a comprehensive analysis that included detailed technical documentation, cost projections for both paths (including the cost of re-architecture later), risk assessments, and a proposed alternative architecture. I then made the call to schedule an emergency technical review meeting with principal engineers and engineering directors across all affected teams, explicitly framing it as "Staff Engineer escalation" rather than waiting for my manager's involvement. I presented my findings and proposed we pause implementation for one week while we evaluated the alternative approach. I simultaneously sent a detailed written memo to the CTO and my manager explaining what I'd done and why. I took full ownership of the decision to pause work, making clear this was my call and my responsibility.

Result: The emergency review validated my concerns, and the leadership team decided to adopt the alternative architecture I'd proposed, accepting a two-week launch delay. This decision prevented what would have been an estimated $2-3M re-architecture project within the following year and positioned us to scale to 10x our current capacity. The CTO later told me this was exactly the kind of judgment and courage he expected from staff-level engineers. This incident led to me being asked to establish an architectural review process that empowered senior technical leaders to raise strategic concerns, which became a key part of our engineering culture. I learned that at the staff level, sometimes your job is to make the organizationally difficult call that no one else wants to make, even when it's uncomfortable and you're putting your reputation on the line.

Common Mistakes

• Justifying recklessness -- Acting without approval should be the exception, not the norm, and requires sound judgment about when waiting would be worse than acting
• Not showing appropriate risk mitigation -- Failing to explain how you de-risked the decision, sought peer input, or prepared contingency plans makes you seem impulsive rather than decisive
• Poor communication afterward -- Not explaining how you informed your manager promptly and thoroughly suggests you were hiding something rather than taking ownership
• Unclear stakes -- Not articulating why waiting for approval wasn't viable makes it hard for interviewers to assess your judgment
• No learning or reflection -- Failing to discuss what you learned or whether you'd handle it the same way makes you seem like you haven't grown from the experience
• Blaming manager availability -- Focusing too much on your manager being unavailable rather than on your decision-making process can come across as making excuses

Result: The emergency review validated my concerns, and the leadership team decided to adopt the alternative architecture I'd proposed, accepting a two-week launch delay. This decision prevented what would have been an estimated $2-3M re-architecture project within the following year and positioned us to scale to 10x our current capacity. The CTO later told me this was exactly the kind of judgment and courage he expected from staff-level engineers. This incident led to me being asked to establish an architectural review process that empowered senior technical leaders to raise strategic concerns, which became a key part of our engineering culture. I learned that at the staff level, sometimes your job is to make the organizationally difficult call that no one else wants to make, even when it's uncomfortable and you're putting your reputation on the line.