Behavioral: how do you handle tight deadlines
Show a process: clarify the real must-haves vs. nice-to-haves, negotiate scope (not quality) early, break work into shippable increments, communicate risk to stakeholders before it's a crisis, and protect the non-negotiables (correctness, security, accessibility). End with a STAR example where scoping — not heroics — saved the deadline.
Tight-deadline questions test prioritization and communication under pressure — not whether you can work weekends. The wrong answer is "I just grind harder." The right answer is a repeatable process.
The process
- Clarify what 'done' actually means. Separate must-haves from nice-to-haves. Half of deadline pressure is scope that was never pinned down.
- Negotiate scope, never quality. You can cut features; you can't cut correctness, security, or accessibility and call it done. Make this trade-off explicit with the PM.
- Slice into shippable increments. Ship the core flow first; layer enhancements. A working 70% beats a broken 100%.
- Surface risk early. The moment you see the deadline is at risk, say so — with options. Stakeholders hate surprises far more than bad news.
- Cut the right corners deliberately. Maybe skip an animation, defer an edge case behind a flag, hardcode a config — but document it as known debt, don't hide it.
STAR example
Situation: A campaign landing page had a hard launch date tied to a marketing spend; design landed late, leaving ~4 days. Task: Ship something solid by launch without shipping something broken. Action: I listed the page sections with the PM and split them into "needed for launch" (hero, CTA, form) and "can follow" (testimonials carousel, animations). I built the must-haves first behind a feature flag, kept the form fully validated and accessible, and flagged on day 2 that the carousel wouldn't make it — the PM was fine deferring it. Result: Launched on time with the core experience solid; the carousel shipped two days later. No quality compromises on the parts that mattered, and the PM later said the early heads-up was what made it manageable.
What interviewers want to hear
- You manage scope, you don't just absorb pressure.
- You communicate risk before it's a crisis.
- You never quietly cut quality — trade-offs are explicit and owned by the PM.
- "Heroics" (all-nighters) is a failure mode, not a strategy.
Senior framing
The senior answer reframes a "tight deadline" as a scope and communication problem, not a work-harder problem. You make trade-offs visible, ship incrementally so there's always something demoable, and treat sustained crunch as a sign the planning broke — not a badge of honor.
Follow-up questions
- •What corners are you NOT willing to cut under deadline pressure?
- •How do you tell a PM the deadline won't be met?
- •How do you avoid accumulating tech debt under pressure?
Common mistakes
- •Answering 'I work longer hours' — signals poor prioritization.
- •Cutting quality silently instead of negotiating scope openly.
- •Waiting until the deadline to reveal it's slipping.
- •No concrete STAR example.
Edge cases
- •Deadline is genuinely immovable AND scope can't be cut — escalate; that's a planning failure to surface, not absorb.
Real-world examples
- •Marketing launch dates, contractual deadlines, demo days, conference releases.