Making the case for reliability over a risky feature

WHAT THIS TESTS The interviewer wants persuasion grounded in business outcomes and data, plus the maturity to find a sequenced compromise rather than a flat refusal. Leadership decides; your job is to give them an evidence-based tradeoff.

A GOOD ANSWER COVERS Anchor on the strategy leadership already set: reliability this quarter. Then quantify why it matters in their terms, recent incidents, churn correlated with slow performance, SLA penalties, and expansion revenue lost when large customers hit limits. Show the proposed feature's specific performance risk to existing paying customers, and that shipping it on a shaky platform could harm the same revenue sales is chasing. Crucially, do not just say no: propose a sequence. Harden the platform or add capacity first, then deliver the feature safely behind a feature flag and a gradual ramp, or scope a lighter version that avoids the risk. Present options with cost and risk for each so leadership can choose with eyes open.

COMMON WRONG ANSWERS Arguing from engineering preference or that reliability is just more important, with no numbers. Refusing the feature outright and antagonizing sales. Presenting only the downside with no path to also satisfy the revenue goal. Ignoring the strategy that was already agreed.

LIKELY FOLLOW-UPS What data would you gather to quantify the reliability cost? How would you ship the feature later without the risk? What if leadership overrules you?

ONE CONCRETE EXAMPLE You show that last quarter two outages correlated with the loss of a large account and rising churn, and that the proposed feature adds heavy queries that load-testing shows would push p95 latency past the SLA at peak. You propose hardening the database and adding capacity in weeks one to six, then launching the feature behind a flag with a ramp in weeks seven to nine. Leadership sees both the revenue goal and the reliability strategy can be met in sequence, and chooses with full information.