How do you prioritize under a deadline?
What is being assessed
The ability to cut scope and communicate transparently, not "I'll get it all done, I'll work nights". A mature answer is about agreements and risks, not heroics.
Answer skeleton
- The criterion: impact on the user and the release / effort. First what the release cannot ship without (blockers, crashes, legal), then the key scenario; nice-to-haves go to the next version.
- Scope, not quality: cut functionality, not tests and reviews — otherwise the deadline moves by a week of bug fixing.
- Early escalation: raise a risk the moment it is visible, not the day before release; offer options (less scope / more time / more people — the last one usually doesn't work).
- Transparency: the "in / out" list is agreed with product in writing; a feature flag for what didn't make it.
- Protecting focus: minimal context switching, pairing on the critical path.
Example answer
S: Two weeks before a release tied to a marketing campaign, three features remained: a new onboarding, PDF export and dark mode.
T: Work out what could realistically ship and agree it with product.
A: I estimated the remainder with the team: onboarding 6 days, export 5, dark mode 4, plus a week of regression testing. It didn't fit. I brought product a matrix: onboarding is mandatory (the campaign lands on it), export is used by 3% of users, dark mode can ship later behind a flag. We recorded in the tracker what was in and what was out. Export was finished behind a flag without being enabled.
R: The release shipped on campaign day with no critical bugs; export was enabled a week later by flipping the flag. Next time product came with priorities up front on their own.