Getting tech work onto a feature roadmap

WHAT THIS TESTS The interviewer wants to see that you can advocate for technical work in the currency leadership uses: outcomes, risk, and cost. Engineers who argue purity lose; engineers who argue impact win the roadmap slot.

A GOOD ANSWER COVERS Translate the debt into business consequences. Quantify slower delivery (features that now take longer because of the debt), reliability cost (incidents, on-call hours, churn from outages), and risk (security or scaling cliffs). Then attach the work to the roadmap rather than competing with it: show that the upcoming feature is cheaper or safer to build after the refactor, so the investment pays for itself in the very features the business wants. Finally propose a sustainable model, such as a standing allocation of capacity each cycle or a fix-as-you-touch policy, so debt is managed continuously instead of requiring a heroic stop-the-world project.

COMMON WRONG ANSWERS Framing it as the code is messy or doesn't follow best practices, which means nothing to a PM. Demanding a multi-month refactor freeze with no incremental value. Failing to connect the work to a concrete upcoming deliverable. Presenting no measurement of the current cost of the debt.

LIKELY FOLLOW-UPS How much capacity would you reserve and why? How do you measure debt's cost today? What if leadership still says no this quarter?

ONE CONCRETE EXAMPLE The next three roadmap features all touch a tangled checkout service. You show that each currently takes about 50 percent longer and causes recurring payment incidents. You propose refactoring the service first, framed as making the upcoming revenue features faster and the payment flow more reliable, and you ask for a steady 20 percent capacity allocation so the system does not decay again. The argument is about delivery speed and revenue, not clean code.