Pushing back on a costly, low-value feature

WHAT THIS TESTS: Whether a senior engineer can disagree with product using data and shared language, and reduce risk with a cheap experiment instead of either caving or stonewalling. Interviewers want collaboration, not a veto.

A GOOD ANSWER COVERS: First, quantify the cost: a rough estimate in engineer-weeks, plus the opportunity cost of what those weeks would otherwise ship. Second, quantify the benefit with the Product Owner: pick the metric the feature is supposed to move, then estimate reach and impact (even a rough RICE-style guess makes the assumption explicit). Third, express it as a ratio cost per expected unit of value so this feature can be compared against other backlog bets on the same scale. Fourth, propose lower-cost experiments to test the underlying hypothesis before a full build.

COMMON WRONG ANSWERS: 'It's too expensive, we shouldn't do it' with no numbers. Building it quietly while resenting it. Treating your estimate as fact rather than a range with assumptions.

LIKELY FOLLOW-UPS: What if product disagrees with your value estimate? (Make the assumption explicit and agree on what evidence would change it.) How accurate must the estimate be? (Accurate enough to compare options the decision, not the number, is the point.)

ONE CONCRETE EXAMPLE: Product wants a fully personalized recommendation engine (est. 8 engineer-weeks). Instead, you propose a one-week experiment: a hand-curated 'recommended for you' shelf shown to 10% of users. If click-through doesn't move, you've saved seven weeks; if it does, you build the real engine with evidence in hand.