Tell me about a time when you made a bad decision.

What decision did you ultimately make?

Why did you choose that particular approach?

What assumptions or analysis informed your choice?

How did you implement the decision?

Share the outcome and lessons learned:

• What happened as a result of your decision?
• How did you realize it wasn't working?
• What steps did you take to address the situation?
• What would you do differently now?

Sample Answer (Junior / New Grad) Situation: During my final year capstone project, our team was building a web application for a local nonprofit. We had eight weeks to deliver a working product, and I was responsible for choosing our technology stack. The client had mentioned they wanted something "modern and easy to maintain," but didn't have technical staff.

Task: As the team member with the most web development experience, I needed to select the frontend framework and backend architecture. My choices would determine our development speed and the nonprofit's ability to maintain the application after handoff. I considered three options: a simple PHP-based solution, a React frontend with Node.js backend, or a WordPress customization.

Action: I decided to go with React and Node.js because I was excited about the technology and thought it would look impressive in our portfolios. I convinced the team that we could learn quickly and that these were "industry-standard" tools. We spent the first three weeks just setting up the development environment and learning the frameworks. I created detailed documentation assuming the nonprofit could hire developers later.

Result: We barely finished a minimal viable product by the deadline, and the quality suffered because we were learning as we built. Worse, the nonprofit couldn't maintain or update the application because it required specialized knowledge. Six months later, I learned they had to hire consultants to rebuild it in WordPress at significant cost. This taught me that technical decisions must prioritize the client's actual capabilities and constraints, not just what's trendy or good for my resume. Now I always ask "who will maintain this?" before choosing technologies.

Sample Answer (Mid-Level) Situation: As a mid-level engineer at a fintech startup, I was leading the development of a new payment reconciliation feature. We were experiencing rapid growth—our transaction volume had doubled in three months—and the finance team was struggling to keep up with manual reconciliation processes. I had to decide how to architect this feature under aggressive timelines, as the CEO wanted it shipped within six weeks.

Task: I owned the technical design and needed to choose between building a robust, scalable solution from scratch or extending our existing reconciliation script into a more functional tool. The engineering director suggested the incremental approach to meet the deadline, but I felt strongly that we should do it right. I needed to balance business urgency against technical quality and future scalability.

Action: I advocated for building a new microservice with proper database design, automated matching algorithms, and a dedicated admin UI. I presented a detailed architecture proposal showing how it would handle future scale and estimated six weeks for my two-person team. I dismissed concerns about timeline risk, believing our experience would carry us through. We started building with enthusiasm, creating clean abstractions and comprehensive test coverage.

Result: After five weeks, we had completed only 60% of the functionality, and the core matching algorithm still had edge case bugs. We missed the deadline by three weeks, during which the finance team had to hire two temporary contractors to handle the manual workload—costing more than $15,000. While the final system was technically sound, the delay damaged my credibility with leadership. I learned that "perfect" can be the enemy of "good enough," and that iterative delivery often beats big-bang releases. Now I break large projects into phases, shipping incremental value quickly and refining based on real usage. This experience fundamentally changed how I approach scope management and stakeholder communication.

Sample Answer (Senior) Situation: As a senior engineering lead at a SaaS company, I was overseeing our platform's transition to a microservices architecture. Our monolithic application was becoming difficult to scale, and we had six teams constantly creating merge conflicts and deployment bottlenecks. The executive team had approved a two-year transformation initiative with significant budget, and I was responsible for defining the migration strategy and service boundaries.

Task: I needed to decide whether to adopt a gradual "strangler fig" pattern—slowly extracting services from the monolith—or to do a comprehensive re-architecture where we'd design the ideal service structure upfront and migrate systematically. This decision would affect 40+ engineers across multiple teams, our ability to ship features during the migration, and our overall technical debt trajectory. I had to balance risk, business continuity, and long-term architectural vision.

Action: After consulting with the team, I decided on the comprehensive re-architecture approach. I spent six weeks with senior engineers designing what I believed was an elegant domain-driven service structure with 12 distinct services. I created a detailed migration plan with clear service boundaries, got buy-in from engineering leadership, and allocated two teams to begin building the new services while others maintained the monolith. I established strict API contracts and planned for a "big switch" cutover after six months. I believed this would give us the cleanest architecture and prevent the messy intermediate states of gradual migration.

Result:

Sample Answer (Staff+) Situation: As a Staff Engineer at a major e-commerce platform, I was leading our technical strategy for the mobile engineering organization—approximately 80 engineers across iOS, Android, and backend-for-frontend teams. We were experiencing significant challenges with our mobile release velocity and quality, with app store approval times and manual testing creating 4-6 week release cycles. The VP of Engineering asked me to develop a strategy to improve our mobile development efficiency and time-to-market while our competitors were shipping updates weekly.

Task: I needed to define a multi-year mobile platform strategy that would address our velocity issues, improve code sharing between iOS and Android, and reduce our testing burden. The key decision was whether to invest heavily in our native mobile architecture with shared business logic layers, or to adopt a cross-platform framework like React Native or Flutter that promised code reuse and faster development. This was a $2M+ investment decision affecting hiring, team structure, and our ability to deliver on product roadmap commitments. I needed to build consensus across mobile engineering, product leadership, and the executive team.

Action: After three months of research, competitive analysis, and proof-of-concepts with both approaches, I championed React Native as our strategic direction. I presented data showing that other companies had achieved 50-70% code reuse and significantly faster feature development. I convinced leadership that consolidating on one codebase would let us reallocate 15-20 engineers to feature development rather than platform maintenance. We committed to a 14-month migration where new features would be built in React Native while we gradually converted key screens from native code. I personally drove the architecture, established the migration plan, and coached teams on the transition. I positioned this as a transformational opportunity to modernize our entire mobile development practice.

Common Mistakes

• Deflecting blame -- Saying "the decision was actually right, but external factors made it fail" rather than owning the mistake
• Choosing trivial examples -- Picking minor decisions that don't demonstrate real judgment or stakes
• No clear lesson learned -- Failing to articulate what you would do differently or how it changed your approach
• Being defensive -- Over-explaining your reasoning to justify the decision rather than acknowledging the error
• Lacking specifics -- Speaking vaguely about "a project that didn't work out" without concrete details about the decision, impact, or recovery
• Not showing recovery -- Focusing only on the failure without explaining how you addressed the situation or mitigated damage