Q10 of 32 · Behavioural
Describe a situation where you had to push back on shipping a feature.
Short answer
Short answer: Pick a case where you raised concerns based on evidence and risk, not vibes. Show how you framed the trade-off in business terms (impact vs delay), gave decision-makers a clear option, and respected the outcome — even if it wasn't yours.
Detail
Pushing back is a craft. Done badly it positions QA as the gatekeeper-who-says-no; done well, it positions you as a partner who surfaces real risk.
STAR walkthrough — sample answer:
Situation: A previous team I was on planned to ship a major change to how user preferences synced across devices. The release was scheduled for a Friday afternoon — there were marketing reasons (a partner announcement on Monday).
Task: I'd been running E2E tests through the week and had found three issues: one cosmetic (fixed), one that affected device-pair limits (not fixed yet), and one I couldn't reproduce reliably but had seen twice — preferences appearing inconsistently across devices for users with more than 5 active sessions.
Action: I didn't say "we shouldn't ship." I went to the eng lead and PM with three things:
- What I'd seen — clear description, repro steps where I had them, screenshots.
- What I didn't know — the unreliable repro, my best guess at the population affected, the worst-case impact (preferences silently wrong for active power users).
- Options — (a) ship Friday accepting the risk, (b) push to Monday morning to investigate, (c) feature-flag the new sync path off and roll it out to a 5% sample after the announcement.
The PM was surprised but appreciated the framing. We picked option (c) — the marketing window was preserved, the sync path went out to 5% over the weekend, and we caught the bug in the canary slice on Saturday morning when one of those 5%-cohort users hit the issue. Hotfix went out before broader rollout.
Result: No customer-facing impact, no missed marketing window, and the team's confidence in the feature-flag rollout pattern increased — we used it twice more in the next quarter on similar high-risk releases.
What I learned: the ask isn't "say no to shipping," it's "give the decision-maker a clear set of options with the risks framed honestly." That repositions QA from gate to advisor.
Why this works: framed the conversation in business terms (marketing window vs risk), offered options not ultimatums, respected that the call belonged to PM and eng lead, and the outcome legitimised the practice for future releases.