TL;DR: Explain why the date matters, show the gap between available capacity and required work, and recommend a scope or schedule the team can defend. Preserve required acceptance checks and make the effect on the customer commitment explicit.
How to approach it
Choose a real project where you can explain both the commercial constraint and the engineering plan. Identify what your estimate included, what it omitted and who could change scope. Separate a demo commitment from permission to serve production traffic.
A strong answer
Ask what must happen on the date. A customer demonstration, a contractual migration and retirement of an unsupported dependency have different consequences if they slip. Understanding the reason lets you propose an alternative that preserves the useful outcome instead of arguing about a date in isolation.
Use a small work breakdown to show the gap. In a fictional planning exercise, two engineers each have five working weeks available, giving ten engineer-weeks before deductions for other commitments. Four independent features require three engineer-weeks each, and integration plus load testing requires two more: fourteen engineer-weeks in total.
Even with perfect parallelism, fourteen divided by two gives a seven-week lower bound. It is not a seven-week delivery promise. Dependencies, specialist availability and integration failures can extend elapsed time. If one engineer also owns an on-call shift, count that commitment rather than assuming every hour remains available for project work.
Compare plans that the decision owner can actually choose:
| Plan | Scope and schedule | Evidence still needed |
|---|---|---|
| Full release later | Four features; at least seven weeks under the exercise assumptions | Dependency schedule and uncertainty allowance |
| Smaller release on the date | Two features plus the stated two weeks of integration work total eight engineer-weeks | Confirm omitted features are separable and acceptance still fits |
| Demonstration on the date | A bounded demonstration with explicit limitations | Customer agreement that it is not production readiness |
Recommend the smaller release if those two features meet the customer need and can be separated cleanly. Describe what “complete” means: permitted users, data handling, recovery behavior and the tests that must pass. Removing a feature may also remove useful integration coverage, so recalculate the work rather than assuming every cut saves its nominal estimate.
A possible fictional conversation is: “The full plan needs fourteen engineer-weeks against ten available. I recommend delivering the two agreed workflows on the date and scheduling the others after acceptance. Before I commit, we need to confirm that authentication and the data migration do not depend on the omitted features.” This gives the manager a recommendation and a specific uncertainty to resolve.
Adding people is another hypothesis to test. A specialist who owns an independent blocked task may help; several new engineers may consume scarce onboarding time and leave the critical path unchanged. Show which task changes duration before claiming that headcount solves the schedule.
After agreement, update the delivery record and the people who rely on it. Track an early milestone that can disprove the revised plan, such as completion of a migration rehearsal. If it fails, raise the changed forecast promptly. Do not wait until the release date to reveal that the assumptions no longer hold.
What interviewers probe next
“Was the original estimate your mistake?” If so, name the omitted work or mistaken dependency assumption. Explain how the revised estimate was checked and what changed in the next planning cycle.
“Leadership still wants the original date and scope.” Present the unresolved gap to the authorized decision owner. Do not represent an unsupported forecast as a commitment, and do not silently omit mandatory checks. Seek an explicit change to scope, schedule or feasible capacity.
“How do you know the compromise worked?” Compare delivered behavior with the agreed acceptance boundary and report deferred work. A successful demo alone does not show that the production commitment was met.
Common mistakes
A headcount calculation without dependencies confuses effort with elapsed time. Draw the longest dependent sequence before giving a delivery date.
Repeated overtime can hide an invalid plan. Include the actual staffing cost and follow-up work instead of describing personal exhaustion as proof that the estimate was achievable.
For rehearsal, change one assumption: the integration work now needs the same specialist as the migration. Explain why the arithmetic lower bound stays the same while the schedule may grow.