Building a cross-product case for shared-lib debt

WHAT THIS TESTS This probes technical judgment plus cross-team influence. A shared library means a local fix has global consequences, and the interviewer wants to see you align three teams through measured risk rather than politics.

A GOOD ANSWER COVERS Start by measuring real exposure per product: which parts of the library each consumes, how a failure would propagate (the blast radius), and what each would pay to migrate. This often reframes the debate, the indifferent team may actually have the largest exposure once you trace usage, and the deferring team may be low risk. Quantify likelihood and severity so the conversation is about numbers, not opinions. Then propose a single coordinated path: one owner for the fix, a versioned migration so products can adopt on a staggered but bounded schedule, and a shared timeline that prevents three divergent forks. Present it to the teams together so the decision is unified and the cost is shared fairly.

COMMON WRONG ANSWERS Deferring to whichever team argues hardest. Letting each product patch or fork the shared library, which multiplies the debt. Assessing the debt abstractly without measuring how each product actually uses it. Forcing an immediate fix on all three regardless of their differing risk.

LIKELY FOLLOW-UPS How would you version the library so teams migrate at their own pace safely? Who should own the shared library long-term? How do you handle the team that refuses to migrate?

ONE CONCRETE EXAMPLE The debt is an unsafe deserialization path in a shared parsing library. You trace usage and find the indifferent team passes untrusted input through it, giving them the highest real risk, while the urgent team only uses a safe code path. With that data, you propose a fixed version, an owner to ship it, and a staggered six-week migration starting with the highest-exposure product. The numbers, not the loudest voice, drive a single agreed plan.