TL;DR: Show the full arc: you understood why the date mattered, made the trade-off explicit in options rather than refusal, negotiated scope or resources, and delivered predictably afterwards. The two failing answers are silent heroics (accepting, then missing) and flat refusal without alternatives.
How to approach it
Pick a story where the deadline pressure was real and the other side had legitimate reasons. Structure it as: what drove the date, why you believed it was unrealistic (with numbers), the option set you presented, and the outcome plus relationship aftermath. The aftermath matters more than candidates expect.
A strong answer
Start with their constraint, stated fairly. "Sales had committed a demo to a customer on the fifteenth; contractually nothing broke if we slipped, but the account team had built a renewal narrative around it." Showing you understood the business driver before disagreeing is the first signal being read.
Make "unrealistic" quantitative, not emotional. The strong version measures the gap: "In this hypothetical plan, two engineers each have five weeks available, or ten engineer-weeks. Four independent features need three engineer-weeks each, plus two engineer-weeks of integration and load testing: fourteen in total." Weak versions say "it felt rushed", which gives leadership nothing to act on. If you have velocity data or past-incident evidence of what cutting testing costs, cite it here.
Present options, not refusal. This is the beat that separates practitioners from complainers:
| Option | What ships | Risk taken |
|---|---|---|
| Full scope, later date | Everything tested | At least 7 weeks total if work parallelizes |
| Core subset on date | Demo-critical path only | Remaining work scheduled visibly |
| Everything on date | All features | Testing compressed; defect risk named |
"I said I could not promise all four features safely by the fifteenth, but could commit hard to the two the demo actually needed, with the rest targeted for week seven under those assumptions. Sales picked option two because it matched what the demo required anyway." The resolution came from making trade-offs explicit so the business could choose with open eyes. That is the actual skill: engineers who convert schedule pressure into scoped choices get trusted with bigger decisions.
Close with the aftermath and what you changed. Did it land? What did you adjust afterwards? Strong endings include a systemic fix: estimation buffers added to planning, a spike done earlier next cycle, an agreement that commitments distinguish "demo-ready" from "production-ready". If you were wrong (the deadline was achievable), say so plainly and say what you misjudged; that version scores well too.
What interviewers probe next
"When would you refuse outright?" Safety, compliance and data integrity, where shipping the wrong thing costs more than the deadline. Have a concrete threshold; vagueness reads as never-having-faced-it.
"What if leadership insisted on the original plan?" Document the risk and seek a decision from its authorized owner. Execute an accepted, permitted plan with the agreed tests; pause and escalate if it would violate a mandatory safety, security or legal constraint. The written risk record is professional duty, not cover-laying, and interviewers can tell which one you mean.
"Was this just bad estimation?" Possibly! Owning the estimating error if it was yours ("my estimate ignored integration testing") is stronger than blaming the asker.
Common mistakes
Narrating a war story where you were the lone hero saving the date through all-nighters. That reports a planning failure as a triumph and signals you will burn out or burn out your team.
Framing the other side as unreasonable. The interviewer identifies with managers; a candidate who paints stakeholders as idiots fails the collaboration read regardless of the technical merit.
No numbers anywhere. Deadline disputes live or die on quantified gaps; their absence suggests the pushback was vibes.