Tech debt vs features: how to decide and how to answer

In this article

1. Before you start
2. Why interviewers ask this
3. What each one is
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

Why interviewers ask this

The tech debt question tests whether a manager treats debt as a moral stance or as a budget. A candidate who says "we always keep quality high" or "the business decides" has not said how much debt is acceptable, how to measure its cost, or how to argue for the work. It is reported in interviews at large technology companies in several shapes: how you balance debt against the feature roadmap, how much debt is acceptable, and how you decide which bets to place when resources are limited.

A weak answer takes a side. A strong answer treats the choice as a budget with an interest rate: it names how it measures the cost of debt, funds the high-interest items first, and explains the trade to product in their units. The engineering manager interview guide places the question among the other planning topics.

What each one is

Interest

Interest, in this metaphor, is the extra effort every later change in the affected code costs because of the debt, which is paid each time the code is touched and not on a calendar.

Payback period

A payback period is the number of weeks a paydown project takes to recover its own cost, found by dividing its cost by the engineering time it saves each week and counted from the week the paydown lands.

Technical debt in plain words

Technical debt is like putting a repair on a credit card. The car runs today, but every trip now costs a little extra until you pay the card off. In a 1992 report to the Object-Oriented Programming, Systems, Languages and Applications conference (OOPSLA), Ward Cunningham wrote that "shipping first time code is like going into debt" and that every minute spent on not-quite-right code counts as interest (Cunningham, 1992). The analogy breaks on timing. A card charges interest every month, but code charges it only when someone works in it (Fowler, 2019).

Fowler's example makes the interest countable: a confusing module turns a feature that would take four days into one that takes six, so the interest is two days per feature. Cleaning the module first takes five days, which pays back after 2.5 features, so after three similar features you are ahead.¹ If nobody touches that module again, the cleanup never pays, so the first question is how often the code changes. What you now know: debt costs a number, and the number depends on use.

Feature work in plain words

Feature work is new behaviour that users or the business asked for, and it earns value as soon as it ships. It is the part of the roadmap customers see, and its value is real and often dated: a launch window, a contract, a competitor's move. The analogy is spending on the business rather than on repairs. Its weakness is that it hides its cost. A feature built on bad structure ships on time and then slows every feature after it.

Reported time use shows why the choice cannot be ignored. In a 2018 survey by Stripe and the Harris Poll of more than 1,000 developers and more than 1,000 senior executives in five countries, developers reported spending 17.3 of a 41.1-hour week on maintenance work such as debugging and refactoring, 13.5 hours of it on technical debt and 3.8 on bad code. That is 42 percent, 33 percent and 9 percent of the week.¹ These are self-reported averages, not a measurement of any one team (Stripe, September 2018).

How the two differ

The two kinds of work buy different things and fail in different ways, so the comparison is about timing and risk, not about which is more virtuous. Debt paydown pays later and risks becoming a rewrite; feature work pays now and risks slowing everything after it. A manager's job is to price both in the same units, engineer-weeks and weeks of delay, so product and engineering argue about numbers instead of values. The table lists the dimensions interviewers usually probe. Read it row by row: where the two columns point in opposite directions, the trade-off is real, and the decision should say which row matters most for the coming quarter and why.

Text description of the diagram

• The paydown lands in week 4 and breaks even in week 16.
• The feature ships in week 12 and misses its window by 2 weeks.

Worked example

The example compares three illustrative paydown items for one team over a 26-week plan, and then prices a feature against the best of them. Assume 3 engineers work each item, so the build time in weeks is cost divided by 3. Savings start the week the paydown lands and repeat every week afterwards; all figures are made up. The break-even week is build weeks plus cost divided by weekly saving, and the net in the plan is saving times the weeks left after the build, minus cost. The arithmetic is in assets/data/debt-arithmetic.py.¹

The billing rewrite looks good on weekly saving alone, but its 8-week build pushes break-even to week 28, two weeks past the plan, so it nets -2.4. It is a candidate for the next plan, or for a smaller scope. The report code is the opposite case: it saves almost nothing because almost nobody changes it, so even a moderate cost never returns. That is Fowler's point that messy but rarely touched code can be left alone.¹

Text description of the diagram

• The flaky deploy pipeline costs 12 engineer-weeks and saves 22.0 in the 26-week plan, a net of +10.0.
• The billing module rewrite costs 24 and saves 21.6 (net -2.4); the rarely changed report code costs 40 and saves 1.3 (net -38.7).

A feature against the best paydown

Now add an illustrative feature that needs the same 3 engineers: 24 engineer-weeks, which is 8 weeks of build, with a dated window at week 10. Two orders are possible.¹

• Pipeline first. The paydown lands in week 4, the feature ships in week 12 and misses its window by 2 weeks. The paydown saves 1.0 engineer-week from week 4 and ends the plan at +10.0.
• Feature first. The feature ships in week 8, inside its window. The pipeline paydown lands in week 12 instead of week 4, so 8 weeks of savings (8.0 engineer-weeks) are forgone and its net falls from +10.0 to +2.0.

The cost of delay is therefore 2 weeks past a dated window on one side and 8 engineer-weeks of forgone savings on the other. The feature wins when the window is worth more than those 8 engineer-weeks, for example a contract or launch that is lost if missed. The paydown wins when the 2 weeks cost little, because it is positive either way and larger when done early. The decision is the one in the table: price both in engineer-weeks and weeks of delay, then compare.

Trade-offs and edge cases

The right balance depends on the kind of debt and the window you are in.

• Four kinds of debt. Fowler's quadrant has two axes, reckless or prudent and deliberate or inadvertent, which give four kinds (Fowler, 2009). Deliberate and reckless is "we don't have time for design"; deliberate and prudent is "we must ship now and deal with the consequences"; inadvertent and reckless is a team ignorant of design practices that creates a mess without realising; inadvertent and prudent is learning, after the build, how it should have been done, which is inevitable. Treat both reckless kinds as a process or skills failure, and the prudent kinds as choices or costs of learning.
• Risk debt in rarely changed code. Code nobody edits can still be expensive: an end-of-life runtime, a known-vulnerable dependency or an outage-prone component pays its interest in incidents, not in slower changes. Measure it with change fail rate and failed deployment recovery time from the DevOps Research and Assessment (DORA) program (DORA, updated January 2026), and fund it when those incidents cost more than the paydown, even if nobody touches the code.
• Operational work as a comparable ceiling. Google's site reliability engineering (SRE) teams aim to keep toil, meaning manual, repetitive and automatable operational work, below 50 percent of each engineer's time (Google SRE book, 2017). It is a comparable ceiling Google sets for toil, which is not the same as debt, but it shows how upkeep can eat a roadmap.
• Measure interest, not feelings. DORA's five metrics, including change lead time and change fail rate, give a neutral reading of whether debt is slowing delivery (DORA, updated January 2026).
• Open-ended rewrites. Cap a paydown by cost and break-even week before it starts, and stop at the stated scope.
• A shifting strategy. If the product the code supports is being wound down, its debt may never need paying; see when priorities change mid-quarter.
• Hiding debt as features. Name paydown work as a roadmap item, with a payback estimate, so product can weigh it.

Text description of the diagram

• A debt item is funded only when it pays back inside the plan.
• Rarely changed, low-risk code is left alone and noted.

How to answer it in an interview

The spoken structure is: debt is a loan, find the interest with data, fund by payback, leave the rest, and say it in the partner's units.

Common mistakes

1. Taking a side. (wrong) "Quality always comes first." (right) Debt is a budget; fund what pays back and say what you leave.
2. No measure. (wrong) "The code feels messy." (right) "Lead time on this module doubled and it caused three incidents."
3. Hidden paydown. (wrong) "We sneak refactoring into feature tickets." (right) Name it as a roadmap item with a payback estimate.
4. Fixing all the debt. (wrong) "We cleaned everything." (right) Leave rarely changed, low-risk code, as Fowler suggests.
5. An uncapped rewrite. (wrong) "We rebuilt the module over three quarters." (right) State cost, scope and payback before starting.

Follow-up questions

How much tech debt is ok?

Enough that the interest it charges is lower than what a paydown would displace. Compare the engineer-weeks the debt costs each week, and any incidents it causes, with the engineer-weeks and weeks of delay the paydown costs, as in the worked example above.

How do you decide which bets to place when resources are limited?

Rank candidates by value per engineer-week and by how reversible they are, fund the top of the list up to the planned capacity, and say what is left out. How to build a roadmap and prioritise shows the capacity arithmetic.

What do you do when company strategy shifts and your team's work becomes less relevant?

Stop work on code that no longer serves a goal, close out half-finished items and tell the team first; the page on priorities that change mid-quarter covers the sequence.

How do you stop debt paydown from becoming an open-ended rewrite?

Set cost, scope and payback in writing before the work starts, review at a fixed date, and stop when the stated scope is done. Show the result in the same measure you used to justify it.

Can you give an example where you chose features over debt and it hurt?

Give a real case with the cost: a launch window you met while a module slowed later work, what you measured afterwards, and the paydown you then funded. Interviewers value the honest cost more than a perfect record. For the relationship with product, see stakeholder management for engineering managers, and for delivery topics the project, program and agile hub and the product management hub.

Sources

1. The WyCash Portfolio Management System (OOPSLA '92 experience report) — Ward Cunningham (OOPSLA 1992), 1 Oct 1992
2. Technical Debt — Martin Fowler (first published 2003, rewritten 2019), 21 May 2019
3. Technical Debt Quadrant — Martin Fowler, 14 Oct 2009
4. The Developer Coefficient — Stripe and Harris Poll (September 2018), 1 Sep 2018
5. Eliminating Toil, Site Reliability Engineering — Google (O'Reilly Media, 2017), 1 Jan 2017
6. DORA software delivery performance metrics — DORA (Google Cloud), 5 Jan 2026