How do you justify API refactoring over new features to stakeholders?

WHAT THIS TESTS: This question tests whether you can translate internal software quality into a language that product and finance understand. The interviewer wants to see business acumen, not just engineering opinion. You need to show that brittle systems create a measurable tax on delivery and that you know how to negotiate scope to pay down that tax without halting the roadmap.

A GOOD ANSWER COVERS: First, frame technical debt using the metaphor Ward Cunningham coined exactly as Martin Fowler describes it. Explain that cruft is the deficiency in internal quality and the extra time to build new features is the interest. Give concrete numbers such as a feature that should take four days but takes six because of the brittle API. Second, admit that you CannotMeasureProductivity precisely, so you build a proxy dashboard. The data to present includes incident cost in dollars, mean time to resolution, error rate trends, on-call burden measured in engineer-hours per week, and feature lead time regression. Third, propose paying the principal gradually rather than a big-bang rewrite. Fowler notes that spending an extra couple of days on the first feature to remove some cruft reduces the interest rate on future enhancements. Tie every refactor milestone to a product deliverable so stakeholders see continuous value. Fourth, prioritize by activity level. High-churn areas deserve zero tolerance for cruft because the interest payments are crippling, while stable but crufty modules can be left alone.

COMMON WRONG ANSWERS: The biggest red flag is asking for a six-month feature freeze to rewrite the API with no product tie-in. Another mistake is claiming that quality is priceless and cannot be measured. Non-technical stakeholders tune out immediately. A third error is ignoring the operational tax and focusing only on developer happiness or clean code aesthetics.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a product manager who still rejects the refactor. They may also ask what you do if the data shows the API is rarely modified but causes incidents, or how you would structure an incremental strangler fig migration versus a big-bang replacement.

ONE CONCRETE EXAMPLE: Say your API takes six days per feature instead of four because of tangled error handling. You estimate cleanup at five days. If you only build one feature, cleanup is a net loss. But the product roadmap has three similar features this quarter. Paying the five-day principal now saves two days on each of the next three features, yielding a one-day net gain within the quarter. You present the on-call data showing twelve pages per week costing four engineer-hours each, and you propose folding the error-handling cleanup into the first feature so the product team still ships on time while lowering the interest rate for the rest of the quarter.

Source: martinfowler.com