Quantify tech debt and pitch it to a PM

WHAT THIS TESTS The interviewer wants to see you bridge the engineer-PM gap. Technical debt with no current user impact will lose every prioritization fight unless you express it in the PM's currency: risk, cost, and velocity. This is a communication and quantification skill as much as a technical one.

A GOOD ANSWER COVERS Quantify the risk as probability times impact. Estimate the likelihood of a failure and its cost: lost revenue during downtime, churn, a regulatory penalty, or engineering hours. Connect the debt to observable trends, such as feature lead time creeping up, a rising share of sprint capacity spent on related bugs, or escalating on-call pages. Then propose, do not demand. Offer scoped, incremental remediation with milestones, state the cost of acting now versus the compounding cost of waiting, and frame it as protecting future roadmap velocity. Give the PM a decision, not an ultimatum.

COMMON WRONG ANSWERS Saying the code is ugly or that good engineers would fix it. Requesting a months-long rewrite with no measurement or phasing. Treating debt as purely an engineering concern instead of a business risk the PM co-owns.

LIKELY FOLLOW-UPS How do you estimate the probability of the failure? How do you phase the work so the team still ships features? What leading indicators would you track to show the debt is worsening?

ONE CONCRETE EXAMPLE A legacy job queue silently drops messages under load. You estimate a sixty percent chance of a customer-visible incident within two quarters as traffic doubles, costing roughly a day of revenue plus reputation. You show feature velocity in that subsystem has fallen thirty percent over six months. You propose a three-sprint phased migration interleaved with feature work, and the PM now has a quantified trade-off to schedule.