How do you quantify the cost of technical debt?

What's really being asked

This tests your ability to translate a technical problem into the language of business—specifically, cost, time, and return on investment. The interviewer wants to see if you can move beyond complaining about "bad code" and build a data-driven case that a non-technical stakeholder, like a Product Owner, can understand and act upon. It's a test of influence and business acumen, not just technical skill.

The full answer

A strong answer follows a four-step, data-driven approach. First, calculate the ongoing cost of the debt by measuring the extra time the team spends per sprint or per feature because of it. Second, create a standard estimate for the one-time cost to fix it. Third, calculate the breakeven point by dividing the fix cost by the ongoing cost (e.g., 40-hour fix / 8 hours lost per sprint = 5 sprints to break even). Fourth, present this data to the Product Owner, framing it as a clear investment: "If we invest 40 hours now, we will save 8 hours every sprint going forward, paying for itself in 5 sprints."

The mistakes people make

The most common red flag is making an emotional or purely technical appeal. Answers like "The code is a mess and developers hate it" or "We need this for long-term health" are weak because they aren't quantified. They position engineering as a cost center complaining, rather than a partner proposing a smart investment. Another mistake is demanding a fixed percentage of every sprint (e.g., "we need 20% for tech debt") without justifying the ROI of the specific work being proposed.

What usually comes next

"What if the PO understands your calculation but still de-prioritizes the work due to external pressure for a feature?" This probes your negotiation and compromise skills. A good response involves breaking the refactor into smaller pieces that can be done alongside features or negotiating to get the first, highest-impact piece done.

"How would you handle this if the 'cost' is not time, but something harder to measure, like increased bug count or developer morale?" This tests your ability to find proxies for cost. You can point to bug density in that module versus others or a rising Change Failure Rate (a DORA metric). For morale, you can anecdotally mention developer frustration but tie it to a business risk like attrition.

A concrete example

A team identifies that a legacy billing module requires 4 extra hours of manual testing per sprint due to its brittleness. The work to refactor and add a proper test suite is estimated at 24 hours. The breakeven point is 24 hours / 4 hours per sprint = 6 sprints. The pitch is: "This debt costs us half a developer-day every sprint. If we invest 3 days now, we'll break even in 3 months. After that, we permanently gain 4 hours of feature development capacity in every future sprint."