How do you prioritize tech debt against new features?

What's really being asked

This question assesses your business acumen, influence, and strategic thinking. It's not about the technical details of the refactor. The interviewer wants to see if you can translate engineering concerns into business language (cost, risk, speed) and act as a strategic partner to the product team, not just a feature factory. They are testing your ability to advocate for long-term health over short-term gains.

The full answer

A strong answer has four parts. First, reframe the problem from "technical debt" to "business impact." Use metrics like "feature lead time has increased by 30% in this area" or "bug rate for this service is 2x the team average." Second, quantify the cost of inaction. Explain that not fixing this will make future features X% slower or delay the product roadmap by Y weeks. Third, propose a concrete, non-disruptive solution. Instead of a "stop the world" refactoring sprint, suggest allocating a fixed capacity, like 20% of every sprint, to this work. This makes it a predictable, budgeted cost. Fourth, describe a visualization technique. This could be a "health metric" dashboard (showing bug counts, test coverage, CI/CD times) or a simple "pain vs. gain" quadrant chart to help the PM prioritize.

The mistakes people make

A major red flag is an "us vs. them" mentality, complaining that "product never lets us fix anything." This shows a lack of ownership and influence. Another weak answer is being vague, saying "it will make things faster" without providing data. Demanding a dedicated "refactoring sprint" without a compelling, urgent reason (like a P0 security flaw) is often seen as naive and disruptive to business goals. Finally, failing to offer a solution and only presenting the problem is a junior-level response.

What usually comes next

Be ready for "How would you measure the success of this refactoring work?" (Answer: improved lead time, lower bug count, faster CI builds). Or, "What if your Product Manager says no to the 20% allocation?" (Answer: Negotiate a smaller scope, find a specific upcoming feature that is blocked by the debt and tie the fix to that feature's success, or escalate the risk with data).

A concrete example

"In my last role, our checkout service deployment time had crept from 15 minutes to over 45 minutes, delaying releases. I tracked this metric for a month and presented it to my PM. I explained that this 30-minute delay, twice a week, cost us 4 hours of engineering time per month and created a risk of failed deployments during peak hours. I proposed we dedicate one engineer's time for two sprints, roughly 10% of our capacity, to modernize the deployment pipeline. The PM agreed because the cost was small, predictable, and the risk to our release schedule was clear. We completed the work and brought deployment time down to 12 minutes."