How do you decide what to test when deadlines are tight?

Tight deadlines force a real prioritisation conversation. The signal interviewers want is that you have a framework, not vibes.

The cleanest framing is risk-based testing. For each candidate area, estimate two things: how likely it is to break (recently changed code, complex logic, weak unit coverage, integration points, third-party dependencies) and how bad it is if it does (revenue path, data loss, security, regulatory). Multiply, sort, work top-down until you run out of time.

A few practical moves that signal seniority:

• Make the trade-off visible. Don't quietly skip tests; write a one-page list titled "What I'm not testing this release and why." That document is for the PM and the eng manager, and it puts the trade-off where it belongs.
• Test the path the user follows on release day. Smoke the golden path end-to-end before going wide on edge cases.
• Invest in monitoring instead of more pre-release testing. If you can't test it, instrument it — error rates, latency, business KPIs — so a regression is visible within minutes, not a customer email later.
• Push back on dates that imply zero testing. "We can ship Friday with this risk profile" is a fair conversation; "we can ship Friday with full coverage" usually isn't.

The lesson interviewers reward: prioritisation isn't about doing less, it's about being honest about what you're choosing not to do and why.