Technical Debt Management

What Interviewers Want to Hear

When asked about technical debt, they're testing: Can you quantify impact? Do you balance pragmatism with quality? Can you communicate trade-offs to PMs? Do you proactively address debt or just complain?

Framework: The Debt Quadrant

Categorize tech debt by impact (how much it hurts) and effort (time to fix):

• High impact, low effort: Fix immediately (e.g., add logging to flaky service)
• High impact, high effort: Schedule dedicated time (e.g., rewrite legacy auth system)
• Low impact, low effort: Fix during feature work (e.g., rename confusing variable)
• Low impact, high effort: Probably ignore (e.g., migrate from React 17 → 18 if no blockers)

Example: Convincing PM to Prioritize Debt

Situation: "Our deployment pipeline took 45 minutes, slowing down iteration speed. PM wanted to ship new features."

Approach: "I quantified the cost: team of 5 engineers × 3 deploys/day × 45 min = 11 hours/day wasted. Proposed 1 sprint to optimize CI/CD."

Result: "Reduced pipeline to 8 minutes. Team velocity increased 20% the next quarter because we could iterate faster."

Why it works: Business impact quantified (11 hours = $$$), specific solution, measurable outcome.

Example: Strategic Tech Debt

Situation: "Building an MVP for a startup, needed to validate market fit in 2 months."

Approach: "I advocated for Firebase instead of building our own auth + database. We documented the trade-offs (vendor lock-in risk, cost at scale) and agreed to revisit if we hit 10k users."

Result: "Shipped in 6 weeks. Reached 5k users, didn't need to migrate. Saved 6 weeks of engineering time."

Why it works: Shows pragmatism, documented decision rationale, knew when debt was acceptable.

How to Talk to PMs About Tech Debt

1. Translate to business metrics: "This slows down every feature by 2 days" not "this code is ugly"
2. Show customer impact: "Users hit this bug 50x/week" not "the architecture is wrong"
3. Propose compromise: "20% of sprint for tech debt" not "stop all features"
4. Track progress: Before/after metrics (build time, incident rate, velocity)

Red Flags

• "We had tech debt but the PM wouldn't let us fix it" → lack of agency
• "I always refuse to ship code with any tech debt" → not pragmatic
• "Tech debt isn't my problem, I just write features" → not senior thinking

Good Debt Management Indicators

• Maintain a tech debt backlog with priority scores
• Reserve 10-20% of sprint capacity for tech debt
• Track debt metrics (test coverage, build time, incident rate)
• Document debt decisions with ADRs (Architecture Decision Records)
• Boy scout rule: leave code better than you found it

Interview Questions

• How do you balance tech debt with feature work?
• Tell me about a time you convinced your team to refactor code.
• Have you ever intentionally taken on tech debt? Why?
• How do you prioritize which tech debt to fix?