Tight Deadline / Competing Priorities

The question — "Tell me about a time you had to deliver under a very tight deadline with competing priorities." Variants: "Describe a time when you had more work than time — how did you handle it?", "Tell me about a time you had to make hard trade-offs to ship on time."

What they're assessing — Prioritization and scoping under pressure; explicit trade-off decisions rather than heroics; proactive stakeholder communication about what is being deferred and why; composure when the plan changes.

STAR-L scaffold

Fill in your own story:

• Situation — What was the project or release? What made the timeline unrealistic — scope creep, a sudden change, a dependency slip? What were the stakes if you missed?
• Task — What were you responsible for delivering? Who were the stakeholders relying on you?
• Action — How did you triage the work? What framework or criteria did you use to decide what was must-have vs. deferrable? Who did you communicate with, what did you tell them, and when? Use "I" and name specific behaviors (e.g., "I listed every open task, rated each by business impact vs. effort, then called the PM to walk through what we could realistically cut").
• Result — What shipped? What was explicitly deferred? Did you hit the deadline? Quantify where you can (features cut, hours saved, incident avoided, customer impact avoided).
• Learned — What changed in how you scope or communicate early? What do you now do differently when you see a timeline risk forming?

Pitfalls / red flags

• Glorifying crunch: "I just worked weekends until it was done" — this signals poor planning and no trade-off thinking.
• No prioritization framework: not being able to articulate why certain things were cut first.
• Silently cutting quality without telling stakeholders — interviewers look for explicit, proactive communication.
• Presenting a story where everyone agreed and nothing was hard — the tension is the point.

Example (generic — replace with your own)

Situation: Three weeks before a committed customer demo, the product roadmap was expanded to include two new feature areas — roughly doubling the original scope. The sales team had already promised the demo date to a strategic prospect.

Task: I was the lead engineer responsible for the backend and coordination with two frontend engineers. It was clear we could not build everything in three weeks without sacrificing correctness.

Action: I listed every open task and scored each one: does this break the demo if absent, and how long will it take? I identified a core of five features that were demo-critical and nine that were either cosmetic or could be faked with static data for the demo. I set up a 30-minute call with the PM and sales lead, walked them through the triage, and proposed that we ship the five real features fully, mock two others as UI-only, and explicitly defer the remaining seven to the next sprint. They agreed. I updated the task board to mark deferred items clearly and sent a written summary to avoid later confusion.

Result: We delivered the five critical features on time with full test coverage. The demo went smoothly and the prospect signed. The seven deferred items shipped in the following sprint without incident.

Learned: I learned that timeline problems almost always have a scope solution, not just an effort solution. I now flag scope-vs-time mismatches as soon as I see them — ideally in planning — rather than waiting until the deadline is close. I also learned to document trade-off decisions in writing so there is no ambiguity later about what was intentionally deferred.