Technical debt work competes with features, so an appeal to “code quality” rarely wins. A strong answer ties the debt to concrete costs — incidents, slow delivery, onboarding friction — and proposes incremental fixes rather than a rewrite.
Before you start
You should have an example of advocating for or doing debt work. This article gives a structure for it.
Step-by-step walkthrough
Step 1: Quantify the cost
Translate the debt into outcomes the business cares about: how many incidents it caused, how much slower a change is, how long onboarding takes. Numbers turn a preference into a business case and give a basis for prioritization.
Step 2: Propose incremental work
Instead of asking for a rewrite, propose a small improvement you can ship alongside feature work, such as fixing the worst module or adding the missing test coverage. Incremental work is easier to approve and shows results quickly.
Step 3: Tie it to a near-term goal
Connect the fix to something already prioritized, such as unblocking a planned feature or reducing a recurring incident. Debt work framed as enabling the next goal competes far better than debt work framed as cleanliness for its own sake.
Worked scenario
A concise STAR answer pairs the cost with a small fix.
Situation: A legacy billing module caused three incidents and slowed every change.
Task: Reduce the risk without stopping feature delivery.
Action: Tracked the incident cost, proposed splitting the worst path into a service
behind a flag, and shipped it over two sprints alongside features.
Result: Incidents dropped and the next billing change took half the time.Walk through the example
The answer quantifies the cost (three incidents, slow changes), proposes an incremental fix (extract the worst path behind a flag) and shows a measurable result. It never asks for a big-bang rewrite, which is what usually gets debt work deprioritized.
Common mistake
Appealing to code quality in the abstract, which loses to features every time, or asking for a large rewrite that blocks the roadmap and gets rejected. Another is doing debt work quietly without connecting it to outcomes, so it reads as unproductive.
Verify the behavior
Confirm your story quantifies a cost and proposes an incremental step. Check that the result is measurable. Be ready for a follow-up where the proposal was rejected and how you adapted.
Interview exercise
What if the business rejects your debt work?
Answer and reasoning
Ask what would change their mind — usually a quantified risk or a near-term goal it blocks — and reframe the work in those terms. If it is still rejected, do the smallest safe slice as part of related feature work, such as adding tests where you touch the code. The aim is to reduce risk within the constraints, not to win the argument.
Continue learning
Compare trade-offs in Quality trade-offs and prioritization in Prioritization. Read the Martin Fowler on technical debt and try the Behavioral interview questions.