Tell me about a time when you had to balance technical debt with new feature development.

Illustrative answer

This is a fictional example with a concrete technical-debt tradeoff.

We were adding a new import format, but the existing importer mixed parsing, validation and database writes in one module. Previous changes had caused regressions because it was hard to test those responsibilities separately. I was the engineer estimating the new feature.

I compared adding another branch to the module, rewriting the importer and first creating a small tested boundary around parsing and validation. I showed the product owner examples of the current regression risk and the effort and uncertainty of each option. A full rewrite would have delayed the requested format considerably.

We agreed to extract the narrow boundary and keep the existing write path for this release. I added representative fixtures for the old formats, malformed records and the new format, and checked the resulting records against the agreed behavior. We reduced the first release's optional formatting choices to fit that work, with the owner's approval.

The checked formats passed the agreed cases, and the new format shipped in the revised scope. The write path still needed work, so I recorded that remaining debt with an owner and a trigger for review. I learned to connect debt work to a concrete delivery risk and testable improvement rather than argue for a fixed percentage of every sprint or claim that all debt had been eliminated.

Follow-up to practice

What evidence would have justified postponing the feature entirely?