Practice an Estimation Conversation With Unknown Dependencies
Practice an engineering estimate with unknown dependencies by stating assumptions, identifying decision checkpoints and updating the range as evidence improves.
TL;DR
- In this fictional engineering estimation interview practice, you are asked when an integration can ship.
- Do not present an uncertain planning assumption as a confirmed release commitment.
- Check whether you distinguished active work from waiting, identified meaningful assumptions and offered a concrete path to better evidence.
The practice prompt
In this fictional engineering estimation interview practice, you are asked when an integration can ship. The core implementation is familiar, but access to a partner test environment is pending and the error behavior has not been documented.
The interviewer wants a date. Your task is to communicate what can be estimated now, what depends on unresolved information and how you will reduce that uncertainty.
Avoid both false precision and an unhelpful refusal to estimate anything until every detail is known.
Related reading: Best AI Interview Assistant Software for Project Managers.
Separate effort from elapsed time
Your team's implementation effort is not the same as the calendar time required for access, review and partner responses. Explain those components separately.
Use a dependency map rather than adding arbitrary padding to a single number. The map should show which work can proceed while the external dependency remains unresolved.
| Component | Current evidence | Next checkpoint |
|---|---|---|
| Core implementation | Familiar bounded task | Confirm the actual interface |
| Test access | Request pending | Obtain an owner and expected response |
| Failure behavior | Undocumented | Run or review a representative failure |
| Release review | Team process known | Reserve qualified review capacity |
Do not invent a numeric estimate unless the exercise provides enough context. If you use illustrative numbers, label them and explain what they assume.
State assumptions as conditions
An estimate should identify the facts that would make it valid. For example, it may assume that the partner interface matches the available documentation and that access arrives before a certain decision point.
Name the consequence if an assumption fails. This is more useful than a disclaimer that “things might change.”
Ask which commitment the stakeholder actually needs: a planning range, a launch decision or a date they can promise externally. Those uses may require different confidence and approval.
Propose a discovery checkpoint
Choose a small step that can reduce the most consequential uncertainty. In this scenario, confirming the interface and exercising the failure path may improve the estimate more than writing additional happy-path code.
Set a time or event for updating the estimate. Explain what new evidence will be available and who owns obtaining it.
Our system design preparation guide can help you rehearse requirement clarification. Keep this answer centered on the estimate's dependencies and decision purpose.
Respond to pressure for a single date
A practice partner can ask, “What date should I put on the slide?” Offer a clearly labelled planning date if the scenario permits one, with the conditions and checkpoint attached. Do not present an uncertain planning assumption as a confirmed release commitment.
If the required confidence is unavailable, explain the choice: delay the commitment, reduce scope or accept a defined risk through the appropriate owner.
Then have the partner remove the access dependency but reveal a new data-mapping problem. Update the estimate rather than treating the first number as a promise that cannot change.
Evaluate the rehearsal
Check whether you distinguished active work from waiting, identified meaningful assumptions and offered a concrete path to better evidence.
Avoid a range so broad that it provides no decision value without explanation. If uncertainty is that large, say which question must be answered to narrow it.
A strong estimation answer is useful now and revisable later. It gives stakeholders a planning basis while preserving the difference between a conditional estimate and an authorized commitment.