Tell me about a time when you didn't have enough data to make the right decision.

What alternative approaches did you use to inform your decision (proxies, expert input, analogies)?

How did you communicate the uncertainty to stakeholders?

What safeguards or validation mechanisms did you put in place?

• What was the impact of your decision?
• How did you measure whether it was the right call?
• What did you learn about decision-making under uncertainty?
• How has this experience influenced your approach since?

Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, I was asked to recommend which user onboarding flow we should A/B test next. Our analytics tool had only been implemented for three weeks, so we had limited historical data about user behavior. The product manager needed a recommendation by end of week to include it in the next sprint planning.

Task: As the engineering intern supporting the growth team, I needed to propose which of three potential onboarding variations would most likely improve our activation rate. The challenge was that we only had partial funnel data and no prior test results to reference. I was responsible for providing a data-informed recommendation despite these gaps.

Action: I first documented what data we did have: three weeks of incomplete funnel metrics and qualitative user interview notes from the previous month. I reached out to our customer success team and compiled themes from their recent onboarding calls with new users. I also looked at case studies from similar companies in our space to understand common friction points. I created a simple scoring matrix that weighted factors like implementation complexity, potential impact based on qualitative signals, and risk level. I presented my recommendation along with clear caveats about the data limitations and suggested we plan for early monitoring.

Result: The product team moved forward with my recommended onboarding flow focused on reducing initial form fields. After two weeks, we saw a 12% improvement in completion rates. More importantly, I learned to triangulate multiple imperfect data sources and be transparent about confidence levels. This approach earned me a return offer, and my manager noted that my structured thinking under uncertainty was a key strength.

Sample Answer (Mid-Level) Situation: As a software engineer at a B2B SaaS company, I was leading the technical implementation of a new API rate limiting system. Three weeks before our planned release, our largest customer requested a custom rate limit tier that would require significant architectural changes. We had no usage data for this customer's upcoming integration because they were migrating from a competitor, and they couldn't provide detailed projections. Our standard tiers were designed based on data from existing customers, but this deal represented 15% of our annual revenue target.

Task: I needed to decide whether to build a flexible custom tier system that could accommodate unknown usage patterns or push back and convince the customer to start with our standard enterprise tier. The decision had to be made within three days to avoid delaying the deal. As the technical lead, I owned both the recommendation and the implementation approach.

Action: I scheduled calls with the customer's engineering team to understand their use case qualitatively, even without exact metrics. I analyzed usage patterns from our three most similar existing enterprise customers to establish reasonable bounds. I worked with our sales engineer to understand the competitor's architecture and made educated estimates about likely usage patterns based on that system's constraints. I then proposed a middle-ground solution: implement a configurable tier system with reasonable buffers that could be adjusted post-launch without code changes. I created a one-page technical brief outlining the assumptions, risks, and monitoring plan, which I reviewed with both product and sales leadership.

Result: We implemented the flexible tier system and onboarded the customer successfully. Their actual usage fell within our estimated range, and the configurable system we built became the foundation for three additional custom enterprise deals worth $800K in the following quarter. I learned to use proxy data creatively and build in adaptability when facing uncertainty. This experience shaped my approach to architectural decisions, leading me to design for flexibility in high-uncertainty scenarios.

Sample Answer (Senior) Situation: As a senior engineering manager at a healthcare technology company, I was leading a team building a new patient scheduling system. Six weeks into development, our compliance team informed us that upcoming healthcare regulations might significantly impact our data retention and privacy requirements. The regulations were still in draft form with ambiguous language, and final versions wouldn't be published for four months—well after our committed launch date to three hospital systems. Rebuilding the architecture later would cost an estimated $400K and cause a six-month delay.

Task: I needed to decide whether to pause development and wait for regulatory clarity, proceed with our current design and risk costly rework, or proactively over-engineer for worst-case compliance scenarios. The decision impacted not just my team but our contractual commitments and the company's expansion into two new states. As the engineering leader, I owned the technical strategy and needed to balance technical debt, risk mitigation, and business commitments.

Action: I assembled a cross-functional task force including our legal counsel, compliance officer, product leader, and a principal engineer. We conducted a structured analysis by creating three architectural scenarios: minimal compliance (current requirements only), moderate (incorporating likely regulatory changes), and maximal (worst-case interpretation). I hired a healthcare regulatory consultant for a two-day engagement to pressure-test our interpretations. We quantified the development cost, rework risk, and timeline implications for each scenario. I then proposed a hybrid approach: build the core system with a modular data layer that could be swapped out, implement the moderate compliance tier, and allocate 20% buffer in our timeline for adjustments. I personally presented this recommendation to our CTO and CEO with a risk matrix and mitigation plan.

Result: When regulations were finalized, they fell between our moderate and maximal scenarios. Because we'd built modularity into the system, we completed necessary adjustments in three weeks rather than the projected six months, spending only $50K in additional engineering time. All three hospital systems launched on schedule, and our compliance-first architecture became a competitive differentiator that helped us win two additional contracts worth $2.3M. This experience taught me that the right decision under uncertainty often isn't about having perfect data—it's about architecting for adaptability and making reversible choices where possible. I now routinely incorporate "decision reversibility" as a key factor in technical planning.

Sample Answer (Staff+) Situation: As a Staff Engineer at a global e-commerce platform, I was leading the technical strategy for our infrastructure modernization, which would impact 200+ engineers across eight countries. We needed to decide whether to migrate our monolithic application to microservices or invest in modularizing the monolith. The challenge was that we had no clear data on team productivity impacts—existing case studies from other companies showed wildly inconsistent results ranging from 50% productivity gains to 40% losses. Our business demanded we commit to a three-year technical roadmap that would influence $15M in infrastructure spending and hiring plans.

Task: As the technical strategy lead, I was responsible for making a recommendation to the executive team that would shape our architecture for the next five years. The decision needed to account for uncertain team scaling, evolving product requirements, and unknown developer productivity impacts. I had to synthesize limited internal data, contradictory external evidence, and diverse stakeholder opinions into a coherent strategy that managed risk while positioning us for growth.

Action: I designed a six-week structured decision-making process that acknowledged our data constraints upfront. I formed three parallel workstreams: one conducted focused experiments by having two teams prototype the same feature in both architectural approaches, another synthesized learnings from 15 architecture leaders at similar-scale companies through structured interviews, and a third analyzed our specific organizational constraints like team distribution and hiring pipeline. Rather than seeking a single "right answer," I framed our choice as managing different risk profiles. I created a decision framework that weighted factors like reversibility, incremental value delivery, and learning velocity. I facilitated two working sessions with engineering directors to pressure-test assumptions and identify hidden risks. Finally, I presented three options to the exec team: pure microservices, modular monolith, or a "strangler fig" hybrid approach that allowed us to learn and adapt.

Common Mistakes

• Waiting for perfect data -- Don't focus on why you couldn't decide; show how you moved forward despite gaps
• No risk mitigation -- Failing to discuss safeguards or validation approaches makes you seem reckless
• Hiding uncertainty -- Strong candidates acknowledge data gaps transparently to stakeholders
• No learning loop -- Not explaining how you validated your decision afterward or what you learned
• Purely gut-based -- Show you used proxies, analogies, or other systematic approaches, not just intuition
• All process, no outcome -- Balance the explanation of your decision process with concrete results

Result: When regulations were finalized, they fell between our moderate and maximal scenarios. Because we'd built modularity into the system, we completed necessary adjustments in three weeks rather than the projected six months, spending only $50K in additional engineering time. All three hospital systems launched on schedule, and our compliance-first architecture became a competitive differentiator that helped us win two additional contracts worth $2.3M. This experience taught me that the right decision under uncertainty often isn't about having perfect data—it's about architecting for adaptability and making reversible choices where possible. I now routinely incorporate "decision reversibility" as a key factor in technical planning.