Tell me about a time you delivered a frontend feature under tight deadlines. How did you prioritize and execute?
STAR answer: a real feature with a hard date. Emphasize how you scoped down to must-haves, sliced into shippable increments behind a flag, communicated risk early, and protected non-negotiables. The result should show you hit the date without quietly sacrificing quality.
This is the STAR-specific version of the tight-deadline question — they want a concrete story, so lead with one.
The spine of a good answer
Scope → slice → communicate → protect non-negotiables → ship → reflect.
STAR example
Situation: We had two weeks to ship a self-serve onboarding flow before a sales push, and the API it depended on wouldn't be ready until day 8. Task: As the frontend owner, I had to deliver a working, polished onboarding flow on time despite a blocked dependency. Action: I broke onboarding into 4 steps and identified which were API-dependent. I built the UI, validation, and step navigation against a typed mock layer matching the agreed API contract, so I wasn't blocked. I kept the work behind a feature flag and demoed progress every couple of days so the PM could course-correct early. When the real API landed on day 8, swapping the mock for the real client was a one-file change because I'd coded against the contract. I cut one nice-to-have (progress autosave) and flagged it as fast-follow. Result: Shipped on day 13, one day early, fully validated and accessible. Autosave followed the next sprint. The mock-against-contract approach became how our team handles blocked dependencies.
What interviewers listen for
- A specific feature, dates, and constraint — not a generic "I've worked under deadlines."
- You removed a blocker (mocking the contract) instead of waiting.
- You scoped explicitly and communicated the cut.
- Incremental demos kept stakeholders aligned.
- The result is concrete and you extracted a reusable lesson.
Common trap
Don't tell a story whose moral is "I worked nights and barely made it." That signals poor planning. The moral should be "I made the deadline manageable by scoping, unblocking, and communicating."
Senior framing
The senior version shows you treat a deadline as a planning and dependency problem. Coding against an agreed contract so a missing API doesn't block you, slicing so there's always something demoable, and negotiating the one cut openly — that's engineering judgment, not endurance.
Follow-up questions
- •How do you code against an API that doesn't exist yet?
- •What did you cut, and how did you decide that was safe to cut?
- •What would you have done if the API contract changed when the real API landed?
Common mistakes
- •A vague story with no specifics, dates, or measurable result.
- •The moral being 'I worked overtime' rather than 'I planned and scoped'.
- •Not mentioning communication with stakeholders.
- •Claiming nothing was cut and quality was perfect — sounds unrealistic.
Edge cases
- •If the real API contract differed from the mock, an anti-corruption/adapter layer absorbs the difference.
Real-world examples
- •Onboarding flows, checkout features, campaign pages, dashboard launches with hard dates.