Navigating Ambiguity and Adaptive Planning Questions

As a junior engineer you don't have the standing to arbitrate the API contract dispute, and you shouldn't try to. What you can control is decoupling your own progress from the outcome, and turning an abstract disagreement into a concrete cost that someone with authority will actually act on.

Technical workaround: build against your own contract, not either team's proposal. Define a small type or interface you own inside your own service, and write a thin adapter that maps whichever upstream shape wins into it. For example, if the disagreement is whether a field comes back as a string enum like status of 'APPROVED' or 'REJECTED' versus a boolean like approved true or false, define your own internal shape, say isApproved as a boolean, and write a ten-line adapter function mapping either upstream option into it. This lets you write and test the majority of your feature logic against a stub of your own type today, and swap the adapter's implementation in under an hour once the contract is settled, instead of being fully blocked.

Political steps, sized to your level. First, don't try to settle the technical disagreement yourself; instead, make the cost concrete to whoever can actually decide. Tell your manager or the relevant tech lead: 'this contract disagreement is blocking my ship date for X, committed for [date].' An abstract disagreement between two teams is easy to let sit; a concrete deadline at risk is not. Second, find out who actually has decision rights over this specific contract, since a stalled disagreement between two teams is very often really a missing-ownership problem, not a technical one. Third, offer to write a neutral one-page comparison of the two proposed contracts, their pros and cons, since disagreements often stall for lack of a written artifact people can react to, not because nobody has an opinion. Fourth, propose a deadline with a default: 'if there's no decision by [date], I'll default to [an existing convention already used elsewhere in the codebase] to stay unblocked.' A concrete default is usually easier for people to react to and resolve than an open-ended debate.

What separates a strong answer from a mediocre one. A mediocre answer either goes silent and waits for someone else to resolve it, or unilaterally implements against whichever contract they personally prefer and hopes nobody notices. A strong answer shows a specific decoupling technique that keeps real progress moving without picking a side, and a clear, deadline-bound escalation path appropriate to a junior engineer's actual authority, not an attempt to resolve something above their pay grade.

The same shape applies outside engineering: a product manager whose launch decision is blocked because two data teams disagree on what counts as an 'active user' could similarly adopt a local, explicitly-labeled provisional definition to keep moving, and escalate with the same default-if-no-decision deadline, rather than waiting indefinitely for a metric committee to agree.

Direct answer

My framework has five stages: frame the decision explicitly before touching any evidence, gather
evidence in proportion to how reversible and time-sensitive the decision is, generate at least a
few real options rather than debating the first idea, choose using a rule I set in advance, and
review the outcome against what I predicted, not just against how it felt in the moment. I involve
people who hold unique information early, one accountable decision-maker at the actual choice
point, and stakeholders with veto power only at defined checkpoints, not at every step. I adjust
the framework itself over time by keeping a short log of past decisions and checking my forecasts
against what actually happened.

Structured elaboration

1. Frame the problem. Before gathering any evidence, I write down what's actually being
decided, whether it's reversible or hard to undo (a useful shorthand some teams use is "one-way
door" versus "two-way door," meaning some decisions are cheap to reverse if wrong and some are
not), the deadline, and what a good outcome looks like. This step exists specifically to stop
motivated reasoning later: if I define success after I already have a preferred answer, I'll bend
the definition to fit it.

2. Gather evidence proportional to reversibility and cost of delay. For a reversible, low-cost
decision, I time-box evidence-gathering tightly and act on partial information. For a hard-to-undo
or high-stakes one, I spend more, but I still prioritize the cheapest piece of evidence that would
most change my mind (its value of information) over evidence that's easy to get but wouldn't
actually shift the decision either way.

3. Generate real options, not just judge the first idea. I force myself to write at least
three options, including the status quo and, where possible, a smaller reversible pilot version of
the bold option, because anchoring on the first idea that comes to mind is a well-documented bias
and a second or third option often turns out cheaper to test.

4. Choose with a pre-set rule. Either a weighted comparison against the criteria from step one,
or a hard gate on a must-have criterion (for example, a safety or compliance requirement that no
amount of upside on other criteria can override). I write the decision and the specific conditions
that would make me revisit it down before moving on.

5. Review the outcome against the prediction. I schedule a fixed check-in (30, 60, or 90 days
out, depending on the decision's time horizon) and compare the actual result to what I predicted
at decision time. I deliberately separate "was the process sound" from "did it turn out well,"
because a good process can still produce a bad outcome from bad luck, and a lucky outcome doesn't
retroactively make a sloppy process good; conflating the two (outcome bias) teaches the wrong
lesson.

Who I involve: people who hold information I don't (frontline users, data owners) early, so
their input shapes the options, not just the final vote; one clearly accountable person who
actually makes the call, so it doesn't get diffused into no one owning it; and stakeholders with
real veto power (legal, safety, a dependent team) only at the specific checkpoints where their
concern applies, not in every meeting, which is what turns a decision process into paralysis by
committee.

How I adjust the framework from what I learn: I keep a short running log of past decisions,
what I predicted, and what actually happened, and I look for patterns, most usefully in my own
calibration (for example, if I notice I consistently underestimate how long "quick" evidence
gathering takes, I widen my default time-box going forward).

Concrete example: deciding whether to migrate a nightly batch data pipeline to a streaming
architecture. Framing: partially reversible (cheap to reverse if abstracted behind a clean
interface, expensive if not), no fixed deadline but real cost of delay from stale data. Evidence:
a two-week spike on the single highest-value pipeline (the cheapest sub-slice to test) measured
latency from event occurrence to dashboard availability, same events run through both systems side
by side; it dropped from about eight hours to about twelve minutes, but the new system also showed
20% more retry incidents in week one. Options generated: migrate everything, migrate only the
highest-value pipeline first, or stay on batch but run it more frequently. Chosen with pre-set
criteria (must show a real latency improvement, must not exceed a stated failure-rate ceiling,
must complete within six weeks): migrate the one pipeline first. Reviewed at day 60: latency held,
and the failure rate fell to an acceptable level once the retry bug found in week one was fixed.
The decision was validated, and the team updated its default spike length for future migrations to
two weeks, because that window had usefully forecast the real rollout risk.

Second, shorter example (different discipline): a product manager framing a pricing-page
redesign the same way: frame it as reversible (a page can be reverted), time-box a two-week test
against a pre-set conversion-lift threshold rather than "see how it feels," generate at least a
control-plus-two-variants option set instead of just ship-or-don't, and review the outcome against
the predicted lift 30 days later before deciding whether to make it permanent.

Trade-offs and pitfalls

The common mediocre answer is either no real framework at all (a reflexive gut call dressed up
after the fact as "I weigh the pros and cons"), or a framework so heavy that nobody could actually
run it under real time pressure. A strong answer names its actual criteria and time-boxes, not
vague phrases like "I gather the relevant information" or "I consider the trade-offs," which say
nothing about what evidence would specifically change the decision or how much of it is enough.

Quantitative framework: compare the two paths on expected effort under uncertainty, plus how early value starts landing, rather than picking a default rule of thumb like "always ship the smallest version" (essentially an MVP, minimum viable product, the smallest version that lets you test the core assumption) or "always build the full thing."

Metrics: expected effort, computed as a probability-weighted sum across the possible outcomes, not just the best case. Tolerances and thresholds: require the complex-now path to beat the simple-then-iterate path by a real margin, not a marginal one, before committing to it directly, because early estimates for the complex path tend to run optimistic, so a narrow win shouldn't be trusted.

Worked example, all effort figures in person-weeks of a single engineer-equivalent, kept on that same basis throughout so a team-size assumption doesn't quietly change the comparison:

An undefined spec point has two plausible interpretations, A and B. Stakeholder conversations put roughly 60 percent confidence on A and 40 percent on B, and the two require materially different implementations.

Complex-now (commit to one interpretation immediately): base effort is 8 person-weeks if the guessed interpretation is correct. If it's wrong, which happens with 40 percent probability, an additional 5 person-weeks of rework is needed once the real requirement surfaces, for a total of 13 person-weeks in that case. Expected effort = 0.6 times 8, plus 0.4 times 13 = 4.8 plus 5.2 = 10.0 person-weeks. Value only starts reaching users after the full build, week 8 at the earliest.

Simple-then-iterate (build a minimal version compatible with either interpretation first): the minimal, compatible slice costs 3 person-weeks and ships immediately, generating real usage data that resolves which interpretation is correct, for free, instead of guessing. Because the minimal version was deliberately built to be compatible with both interpretations rather than thrown away, completing it to the full scope once the correct interpretation is known costs the remaining 5 person-weeks (8 total minus the 3 already spent), with no rework tax, since there's no more guessing involved. Total = 3 plus 5 = 8.0 person-weeks, and value starts reaching users at week 3 instead of week 8.

Comparing the two options: simple-then-iterate wins on both dimensions in this example, 8.0 expected person-weeks versus 10.0, a 20 percent lower expected cost, and value lands five weeks earlier. State plainly that these specific numbers, the 60/40 split and the 5-week rework estimate, are ESTIMATES that must come from your own team's judgment in a real case; the reusable part is the structure of the comparison, not these particular figures.

When complex-now is actually the right call: (a) there's effectively only one plausible interpretation, so the probability of guessing wrong is near zero and there's no rework risk to avoid; (b) a minimal version compatible with both interpretations genuinely isn't buildable, some features are all-or-nothing; or (c) the overhead of building in two passes is large enough that it pushes the iterate path's total above the complex-now expected effort, in which case always compute both sides rather than assuming iteration automatically wins.

The same logic applies outside a software build: a team designing an approval workflow with an undefined edge case can ship a simple version that handles the common, well-understood case now, observe which edge cases actually occur in practice, and build the handling for those specific cases afterward, rather than guessing up front which edge cases are worth designing for.

A skeleton to fill in. Situation: briefly set the stakes and the deadline pressure that made waiting for complete data not viable. Task: state the specific decision you had to make and name the specific missing piece, not a vague sense of uncertainty. Action, in four parts: (a) exactly what you identified as missing, named precisely rather than described as "incomplete data"; (b) the explicit assumption you wrote down to fill that gap, specific enough that someone else could check it; (c) a minimal, cheap, fast check or small experiment you ran to reduce the risk of that assumption before committing, not a full study; (d) the decision you actually made. Result: a real outcome with real metrics, plus a lesson specific enough that it changed a subsequent behavior, a checklist item, a threshold, not a generic "I learned to communicate more."

A fully worked instance. Situation: six weeks before a contractual customer commitment date in March of a product's second year, a team had to decide whether to ship a new PDF export feature using on-the-fly rendering or invest in a pre-rendering pipeline, with no data yet on how many customers would need large (500-plus row) exports, the case that would make on-the-fly rendering too slow. Task: decide by March 15 which architecture to commit two engineers and four available weeks to, ahead of the deadline.

Action: the missing piece was named precisely, not "usage data" broadly but specifically the distribution of export sizes among the 40 customers slated to get this feature at launch, which did not exist because the feature had not shipped yet. The assumption was written into the design document explicitly: "assume export size distribution mirrors the existing comma-separated-values (CSV) export feature's distribution, median 80 rows, 95th-percentile (p95, meaning the value only 5% of cases exceed) 600 rows, flagged as unverified for this feature's specific customer behavior." The minimal check: instrumented the existing CSV export with row-count logging for 10 days, half a day of engineering work, which had never existed before. It returned a real, if adjacent, number: observed p95 was actually 850 rows, higher than the assumption. Given that, the team chose the pre-rendering pipeline (the full four weeks), scoped to handle up to 2,000 rows with headroom, with the assumption and the 10-day proxy data documented as the basis, plus an explicit note to revisit the choice if post-launch usage came in far lower.

Result: shipped on time, April 26, for the customer deadline. At 60 days, actual PDF export p95 was 720 rows, within range of the proxy-informed decision. Had the team instead sized on-the-fly rendering to the original 600-row assumption, roughly 15% of customers would have hit timeouts on their largest exports, based on the 60-day distribution. Lesson, stated specifically: the team adopted a standing practice, now a named step in the design-document template ("proxy data check"), of instrumenting the nearest existing analog feature for at least a week before committing to architecture on anything with no usage history, rather than debating projected usage in a meeting.

A shorter version of the same shape shows up outside engineering too. A support-operations lead deciding whether to build a dedicated escalation queue for a new product line, with no historical ticket data for it yet, names the same missing piece precisely (ticket volume for the new line specifically, not "support load" broadly), writes down the assumption (using the closest existing product line's ticket-per-customer rate as a stand-in), runs the same kind of minimal check (tags and counts the first two weeks of real tickets after launch instead of waiting for a full quarter), and adopts the same kind of lasting change (a launch-checklist item: instrument ticket tagging before day one, not after volume becomes a problem).

What separates a strong answer from a mediocre one. A mediocre answer names a real decision and says "we didn't have data, so we made our best guess and it worked out," with no visible mechanism (no named assumption, no cheap validation step) and a vague, unfalsifiable lesson. A strong answer shows the exact missing input, a specific and checkable assumption, real evidence gathered before committing (even if small and imperfect), and a lesson concrete enough that it became a repeatable practice. Interviewers are listening for whether you distinguish "no data" from "no test of the assumption," since the latter is what's actually within your control under time pressure.

Direct answer

Use a STAR structure (Situation, Task, Action, Result), but shape it around five things this question specifically names: the original plan, how you discovered the assumption was wrong, how you revised the approach, how you communicated the change, and what you did afterward to prevent a repeat. A strong answer also shows you chose a revision that tried to protect the delivery commitment rather than defaulting to "we pushed the date," and that your communication included not just the fact of the change but its impact on outcomes and on how future decisions would be made.

STAR skeleton to fill in

• Situation: the plan, and specifically which assumption it was quietly built on.
• Task: what you were responsible for delivering, and by when.
• Action, discovery: what surfaced the assumption was false, and how far into execution you were.
• Action, revision: the alternative you chose, including one option you considered and rejected, and whether you managed to protect the original delivery expectation or had to renegotiate it.
• Communication: who you told, what you told them (not just "the plan changed" but the quantified impact), and what it meant for how they, or you, would make similar calls in the future.
• Result and prevention: the outcome, and the specific, durable process change you made, not just a personal resolution to be more careful.

Worked example instance

Situation: I was building a fraud-screening integration into a checkout flow. The plan assumed the vendor's screening call would return within their documented service level agreement (SLA, a contractual performance guarantee) of 500 milliseconds at the 95th percentile (p95, meaning 95% of calls finish at or under that time), which let us call it synchronously before confirming an order. Task: ship a synchronous fraud check inside a 5-week build, without adding noticeable checkout latency. Discovery: two weeks in, a load test against the vendor's sandbox with 10,000 requests showed a real p95 of 4.2 seconds, 8.4 times the documented SLA (4,200ms divided by 500ms), measured on the same basis as the SLA claim: p95 latency under concurrent load. The synchronous assumption was dead. Revision: rather than slip the ship date, I moved the screening call to run asynchronously after the order was placed, holding the order in a short pending-review state, with an auto-approve fallback under a defined risk threshold if the vendor hadn't responded within 3 seconds, matching the checkout's original latency budget. I considered and rejected simply raising our timeout to 5 seconds and keeping it synchronous, because that would have made every checkout feel slow, not just the small share that actually needed review. Communication: within 24 hours I told the product lead, the risk owner, and engineering: the change affected roughly 3% of orders (our historical flag rate) with up to a 3-second delay to their confirmation instead of zero, and I was explicit about the trade-off it created (a small false-approve risk in exchange for keeping the ship date) and what it meant going forward: our next vendor evaluation would need a load-tested p95 number, not just the vendor's advertised SLA, before we could use it to lock an architecture decision. Result and prevention: we shipped on the original date. I added a load-test-before-build gate to our vendor integration checklist so any assumed external latency or throughput number gets independently verified under realistic load before it's allowed to anchor a design decision.

What separates a strong answer from a mediocre one here

A mediocre answer blames the vendor or the documentation instead of examining why the assumption went unverified, describes the revision vaguely ("we adjusted the approach") without a concrete alternative, and treats communication as simply informing people after the fact rather than explaining the quantified impact and what it changes about future decisions. A strong answer picks a revision that tries to preserve the delivery commitment where reasonably possible, is explicit about the option it rejected and why, and turns the incident into a specific, checkable process change.

Second, shorter example (different discipline): a program manager planning an in-person conference assumed a venue's listed capacity of 500 was accurate. A walk-through three weeks before the event revealed fire code actually capped it at 350. Rather than move the date, she added a second overflow room with a livestream, told sponsors the exact new capacity split and what it meant for marketing claims within a day, and afterward added an on-site capacity verification step to the vendor-booking checklist before any date is announced publicly.

Trap to avoid

Don't answer this as a generic "time something went wrong" story. The question is about a load-bearing assumption specifically, so be ready to say plainly why the plan wouldn't have made sense without it, and don't let the discovery and revision sections blur into a single vague "we figured it out."