Delivery, Planning & Decisions Under Uncertainty — Interview Questions

How to use this lesson

Delivery questions test judgement and ownership. Strong answers show:

• how you reduce uncertainty (spikes, pilots, reversible decisions);
• how you trade scope, time and quality explicitly;
• how you communicate those trades.

Always quantify the outcome.

Q1. Give an example of a significant decision you made without all the information you needed.

Short answer: The framework:

• classify the decision as a one-way door (irreversible, so gather more data) or a two-way door (reversible, so decide fast and iterate);
• identify the key unknowns, and time-box a way to reduce them (a spike, a pilot, a proof of concept, a benchmark);
• define the decision criteria and exit conditions up front;
• decide with about 70% of the information (Bezos's heuristic);
• write it down (an ADR), including the assumptions;
• monitor, and revisit.

An example: "We needed to choose a search engine for a new catalogue, with limited data on future query patterns. I ran a two-week pilot with OpenSearch against real production queries (latency, relevance, ops cost), and designed a search abstraction port, so switching later would be cheap. We launched on time, and the abstraction later let us add vector search without rewrites."

Q2. Describe a challenging project you led: your role, and the outcomes.

Short answer: Pick a project with real complexity (technical, organisational, or both), and structure it:

• Situation and stakes: "a legacy order platform (a monolith, Oracle) causing about 2 incidents a month and blocking a new market launch".
• Your role: technical lead or architect; what you personally owned.
• Actions:
  • the strangler-fig migration plan, with incremental milestones;
  • risk management (dual-running, reconciliation);
  • stakeholder alignment (a phased roadmap);
  • team enablement (training, pairing);
  • observability first.
• Results with numbers: "migrated 70% of the traffic in 9 months; p99 latency from 1.8 s to 300 ms; incidents from 2 per month to 0.3 per month; the new-market launch was unblocked on schedule".
• What you'd do differently: shows reflection (for example "we underestimated the data migration; next time I'd prototype the data sync first").

Q3. How do you prioritise tasks with tight deadlines and limited resources? How do you prioritise in general?

Short answer:

• Start from the goal: what outcome must be true by the deadline? Define the must-haves (MoSCoW), and the critical path.
• Score the work by impact vs effort (or cost of delay / duration, WSJF), with risk-first ordering: do the unknown and risky items early.
• Limit work in progress, and swarm on the critical items.
• Say no or not-now explicitly, with a visible backlog, so nothing is silently dropped.
• Re-plan frequently (daily standups focused on flow, and a weekly risk review).
• Protect quality and on-call capacity, and budget for unplanned work (for example 20%).
• Communicate the trade-offs to stakeholders ("to hit the date, we drop X or delay Y").

Q4. Tell me about a time you had to recover a project. What steps did you take?

Short answer:

1. Stop and assess: the real status (not the reported status), a burn-down versus the remaining scope, the root causes (unclear scope, technical blockers, dependencies, team capacity), and the risks.
2. Re-baseline: agree on a realistic plan, with a reduced or phased scope, a clear definition of done, and milestones every 1–2 weeks.
3. Remove blockers: escalate the dependencies, add the needed expertise (temporarily), and cut the non-essential work.
4. Improve execution: smaller increments, earlier integration, daily visibility of progress and risks, and automated tests and CI, so the progress is real.
5. Communicate transparently: a revised plan with stakeholders, and frequent updates leading with risk.
6. Rebuild morale: quick wins, and recognition.
7. A retro afterwards, to prevent recurrence.

The example structure: "We were 6 weeks behind on a payment integration... I re-scoped to card payments first (UPI in phase 2), secured a provider contact for weekly syncs, and added contract tests against their sandbox... We shipped phase 1 two weeks late, but with zero payment incidents, and phase 2 a month later."

Q5. What's your approach to handling scope creep?

Short answer:

• Prevent it: a clear problem statement and acceptance criteria, an explicit non-goals list, and stakeholder sign-off on the MVP.
• Detect it: changes arrive as "small tweaks". Keep a visible backlog, and track changes against the baseline.
• Handle it: don't say a flat no. Say "yes, and here's the trade-off":
  • estimate the impact (time, cost, risk);
  • offer the options: swap it with an item of similar size, defer it to a later phase, or extend the timeline;
  • have the product owner decide, with that visibility.
• Distinguish genuine discoveries (a regulatory requirement: must adapt) from nice-to-haves.
• Iterative delivery makes the changes cheaper: release early, and gather feedback before gold-plating.

Learn it in depth → Handling Scope Creep

Q6. Describe a time you had to adapt quickly to changes in a project.

Short answer: Structure: the change → your fast assessment → re-planning → enabling the team → the outcome. For example: "Midway through a project, the security team mandated moving from session authentication to OAuth2 with our corporate IdP. I did a one-day impact analysis (the affected services, the libraries, the testing), proposed a plan (a shared auth starter, with the migration done service by service behind a gateway), ran a half-day workshop on Spring Security resource servers, and paired on the first service. We absorbed the change with a two-week slip instead of the feared two months, and the starter became the company standard."

The message: calm assessment, reuse over reinvention, and team enablement.

Q7. How do you align technical goals with business objectives?

Short answer:

• Understand the business drivers: revenue, cost, risk and compliance, speed to market, customer experience. Join product planning, and read the OKRs.
• Frame technical work in business terms: "migrating to event-driven order processing cuts the order-confirmation time from 30 seconds to 2 seconds, and removes a whole class of incidents costing about X hours a quarter", rather than "we want Kafka".
• Invest proportionally: a portfolio balance (for example 70% features, 20% platform or tech debt, 10% exploration), adjusted to the business needs.
• Tie them to measurable outcomes: SLOs, DORA metrics, cost per transaction, conversion.
• Make the trade-offs visible (technical-debt interest).
• Revisit them quarterly with product and leadership.

Q8. Describe a time your strategic thinking significantly influenced a project's outcome.

Short answer: Show seeing second-order effects and changing the direction. For example:

• "Product wanted a dedicated service per partner integration (12 planned). I proposed a generic integration framework (configuration-driven adapters, plus a canonical model) after analysing that about 80% of the logic was shared. It took 6 extra weeks up front, but onboarding each new partner dropped from 8 weeks to 1–2, and we onboarded 15 partners that year, instead of about 5."
• Or: "I pushed for progressive rollout with feature flags before a big launch, which let us detect a payment-gateway issue with 2% of traffic, instead of 100%."

Include how you persuaded people (data, prototypes, an RFC), and the measurable result.

Q9. What role do you typically play in project planning? How do you plan sprint deliverables?

Short answer:

• In planning:
  • clarify the requirements and non-functional needs (scale, latency, security, compliance);
  • propose the architecture options with trade-offs (an RFC or design document);
  • identify the risks and unknowns early, and plan spikes;
  • break epics into thin vertical slices;
  • estimate with ranges;
  • map the dependencies (other teams, vendors);
  • define the milestones and release strategy (flags, phased rollouts);
  • plan for observability and the operational readiness checklist.
• For sprint deliverables:
  • start from the sprint goal (an outcome, not a list);
  • pull the ready stories (clear acceptance criteria, dependencies resolved);
  • size by capacity (vacations, on-call, and a buffer for unplanned work);
  • include tech debt items;
  • end with a shared commitment;
  • revisit mid-sprint if the risks materialise.

Learn it in depth → Facilitating Sprint Planning

Q10. How do you evaluate the return on investment of adopting a new technology or tool?

Short answer:

• Define the problem, and the success metrics first: what hurts today (for example, "builds take 20 minutes", or "we spend 30% of on-call time on X")?
• Costs:
  • licences or cloud spend;
  • migration effort;
  • learning curve;
  • operational burden (who runs it, and upgrades it);
  • integration work;
  • lock-in and exit costs;
  • security or compliance reviews.
• Benefits: time saved × people × frequency, incidents avoided, revenue enabled, performance gains, and hiring or market factors.
• Risks: maturity, community and vendor health, fit with the existing stack, and team skills.
• Validate with a time-boxed pilot or proof of concept on a real use case, measuring against the metrics, before committing. Compare it with "improve what we have".
• Decide and document (an ADR, with a review date).

An example: adopting Testcontainers cost about 2 weeks, and removed a shared, flaky staging database, which cut the integration-test failures by 80%.

Q11. How do you handle project delays?

Short answer:

1. Detect them early (track the critical path and the leading indicators, not just the percentage complete).
2. Understand the cause (estimation, scope, dependency, technical).
3. Assess the options: cut or phase the scope, add focused help (Brooks's law warns that adding people late slows things down), remove blockers, parallelise, or move the date.
4. Communicate immediately, with the impact and the options, to the stakeholders (no surprises).
5. Execute the chosen plan, and track it more tightly.
6. Learn from it in a retro (buffers, better slicing, earlier integration).

Follow-up questions this topic invites — and their answers

Q: What is an ADR, and why use one? A: An Architecture Decision Record: a short document (context, decision, alternatives, consequences), stored with the code. It preserves the reasoning, helps onboarding, and makes revisiting decisions deliberate instead of accidental.

Q: How do you estimate when there's a lot of uncertainty? A: Use ranges (best, likely, worst), or three-point estimates. Do a spike on the unknowns, then re-estimate. Use relative sizing and historical velocity. Communicate the confidence levels, and update the estimates as you learn (a "cone of uncertainty").

Q: What's a good way to slice work thinly? A: Vertical slices that deliver end-to-end value (UI, API and database for one narrow use case), rather than horizontal layers. Split by workflow step, business rule variation, data type, or happy path first, then edge cases.

Q: How do you handle a stakeholder who keeps adding "small" requests? A: Log every request visibly, estimate each one, and review them together weekly, with explicit trade-offs against the committed goals, so the cumulative impact is transparent and the prioritisation is shared.