How do you manage work under tight deadlines

Clarify scope and the real constraint, ruthlessly prioritize must-haves vs nice-to-haves, communicate tradeoffs early, cut scope before cutting quality on critical paths, and protect against burnout-driven bugs. Use STAR with a concrete example.

5 min read·~6 min to think through

Tight deadlines are a prioritization and communication problem, not a "work faster" problem. Strong answers show a process and a real example.

The process

Clarify what's actually fixed. Is the date immovable? Is scope? Is quality? Usually only one truly is — find out which, because that determines everything.
Break down and estimate. Decompose into small tasks so you can see what's real. Vague work hides risk.
Ruthlessly prioritize. Separate must-have (the launch fails without it) from should-have and nice-to-have. Sequence by value and risk — do the riskiest unknowns first so surprises surface early, not on the last day.
Cut scope, not corners. On critical paths, protect quality — bugs in a rushed core feature cost more than they save. Defer or simplify features, not correctness. A smaller thing that works beats a bigger thing that doesn't.
Communicate early and with options. The moment you see the deadline is at risk, raise it — with choices: "We can ship A and B by Friday, or A, B, and C by Wednesday next week. Which do you want?" Surfacing it late is the actual failure.
Reduce friction. Pair on blockers, ask for help, cut meetings, get fast review turnaround.
Protect sustainability. Crunch produces bugs and rework. Short bursts are fine; sustained crunch is a planning failure to flag.

STAR example (shape)

Situation: "We had a 2-week window to ship a payments feature for a partner launch."
Task: "I owned the frontend; the original scope wasn't realistic in the time."
Action: "I broke it down, identified the core checkout flow as must-have and the saved-cards UI as deferrable, and proposed that split to the PM with explicit tradeoffs. I front-loaded the payment-provider integration since it was the biggest unknown."
Result: "We shipped the core flow on time and fully tested; saved cards followed a week later. The launch hit its date with zero payment bugs."

What interviewers listen for

Ownership, calm prioritization, proactive communication (not last-minute), and that you protect quality where it counts instead of being a hero who burns out and ships bugs.

Follow-up questions

•Tell me about a time you had to tell a stakeholder a deadline would slip.
•How do you decide what to cut?
•What do you do when the deadline is genuinely impossible?
•How do you keep quality up under time pressure?

Common mistakes

•Saying 'I just work harder/longer' — shows no process and invites burnout.
•Not communicating risk until it's too late to act on it.
•Cutting quality on critical paths instead of cutting scope.
•No concrete example — staying abstract makes the answer unconvincing.

Performance considerations

Edge cases

•The deadline is truly impossible no matter what's cut.
•Stakeholders who won't accept any scope reduction.
•Deadline pressure caused by upstream dependencies slipping.
•Repeated 'emergency' deadlines signaling a planning problem.

Real-world examples

•Splitting a feature into a shippable core and a fast-follow to hit a partner launch date.
•Front-loading the riskiest integration so unknowns surface in week one, not week two.

Senior engineer discussion

Senior answers reframe the deadline as a negotiation over the scope/time/quality triangle and show they drive that conversation with data and options rather than absorbing pressure silently. They mention sequencing by risk, protecting correctness on critical paths, and treating chronic crunch as a planning signal to escalate — leadership, not heroics.