How do you decide between paying down technical debt and shipping a feature?

#Reframe the Question Before You Answer It

The binary framing — debt versus feature — is usually the trap, and refusing it is the first thing a senior answer should do out loud. The job isn't picking a side of a values argument ("clean code matters" versus "ship fast"); it's turning a vague tension into a capacity-allocation decision with numbers attached. Say this explicitly in the interview: "I don't think about it as debt-versus-feature, I think about it as which of these has a better return this quarter, and here's how I'd measure that."

#Categorize the Debt First

Not all debt is the same, and treating it as one undifferentiated pile is where these arguments go in circles. I sort it into three buckets: debt we took on knowingly to hit a real deadline, with the shortcut written down somewhere; debt we didn't know was debt when we wrote it, because the constraints changed under us; and debt that's really just a preference dressed up as a problem — code that works fine and would only look nicer refactored. Only the first two are worth spending a debate on; the third is where a lot of junior-to-mid engineers waste political capital.

#Price It in the Business's Currency

Convert the debt into three numbers a PM or an EM can act on without a computer science degree: the velocity tax (how many extra story points does every feature in this area cost because of the shortcut), the incident cost (how many pages, rollbacks, or hotfixes trace back to it in the last two quarters), and the onboarding tax (how long before a new hire is safely productive touching this code). Concrete example: a shared networking layer doing untyped JSON parsing was causing roughly one crash-inducing regression per release cycle and adding a day to every feature that touched a new endpoint — that's not "this code is ugly," that's a quantified, recurring cost with a number attached to it.

#Make the Trade Explicit With Stakeholders

Bring a one-pager, not a Slack message: cost of doing nothing over the next two quarters, against the cost of a scoped one-to-two-week paydown, in terms stakeholders already track — delivery dates, incident count, on-call load. Negotiate as "this feature slips by four days" or "we ship a reduced scope on the original date," never as an open-ended request to "let me refactor this." Open-ended asks lose to concrete feature dates every time, and rightly so — nobody can evaluate an open-ended ask.

#Prefer Interest Payments Over Debt Jubilees

Advocate for incremental paydown folded into every feature that touches the area — the boy-scout rule applied deliberately — plus periodic, small, dedicated slices for the load-bearing pieces, rather than always asking for a standalone quarter-long rewrite. Standalone rewrites are a hard sell, they compete directly against roadmap commitments, and they have a well-earned reputation for running long. I chipped away at a legacy Objective-C bridging layer module by module over a year, attached to feature work that was touching it anyway, and it was never once a line item anyone had to defend on its own.

#Know Where the Hard Line Is

Some debt isn't a developer-taste question at all — it's a business risk, and treating it as a negotiation is the wrong instinct. Security vulnerabilities, crash-prone code in a checkout or payment path, accessibility gaps that carry legal exposure, anything that risks App Store rejection — for these, the job is to escalate as a risk statement to whoever owns that risk, not to relitigate it as a technical opinion, and to be willing to block a release over it.