Countering a PM's suboptimal technical proposal

WHAT THIS TESTS This probes collaboration and influence. PMs own the what and why; engineers own the how. The interviewer wants to see that you can push back on the how without seizing the what, and that you keep the user's problem as the shared anchor rather than turning it into a turf fight.

A GOOD ANSWER COVERS Start by confirming the user problem and its success metric so you are not arguing past each other. Make clear you support the goal. Then separate the problem from the specific solution the PM proposed, since they often conflate the two. Present your alternative in business language: what it costs now, what the PM's version costs later in maintenance and slowed feature velocity, and where the two converge. Offer a path that ships value on a comparable timeline while avoiding the worst debt.

COMMON WRONG ANSWERS Saying you would just refuse to build it or escalate over the PM's head immediately. Arguing on technical aesthetics rather than user and business impact. Proposing a much larger rewrite that solves the debt but blows the timeline, which is just trading the PM's mistake for your own.

LIKELY FOLLOW-UPS What if the PM still disagrees after your proposal? When is taking on the debt actually the right call? How do you make the future cost of debt visible to non-engineers?

ONE CONCRETE EXAMPLE Suppose the PM wants a quick feature that writes denormalized data directly across three services. You agree the user needs the feature this sprint, then show that the proposed approach creates dual writes that will cause inconsistency bugs within months. You propose publishing one event consumed by the other services, which ships in the same sprint, solves the same user need, and avoids the consistency debt. You quantify the alternative as one extra day now versus weeks of incident time later.