← All questions
Technicalwarm-up
How would you handle technical debt on your roadmap?
How to approach it
Treat technical debt as a product risk with costs you can describe, such as slower releases or more bugs, not as an engineering wish list.
How a strong answer opens
“I treat technical debt as a product risk with costs we can describe, like slower releases and more bugs. So I'd start by asking engineers which debt slows them down most.”
Outline of a strong answer
Try answering out loud for a few minutes before you open this.
- Ask engineers to list debt and its effect on speed and quality
- Translate into user and business impact
- Set aside a steady share of capacity
- Tie debt work to features where possible
- Track progress with release speed and bug counts
Where this question usually goes wrong
Treating debt as an engineering wish list to squeeze in when there's time, or promising unlimited time with no link to impact.
Learn the method
Technical trade-offs in Module 6, Technical for PMs.
The full kit has worked answers in full, start to finish, for every round type. $129 once.
More technical questions
- What is a cache, and what could go wrong if your product relies on one?
- Should we build our mobile app natively or with a cross-platform framework?
- What's the difference between latency and throughput, and how would each show up for users?
- How would you design a URL shortener, at the level a PM needs?
- How would you design the backend for a photo-sharing app's news feed?