Technical debt
27 bites tagged Technical debt: interview questions with model answers, and 60-second explainers.
What technical areas would you investigate in acquisition due diligence?
Tests strategic integration risk beyond code quality. Cover: architecture compatibility and tech debt; data model overlap and migration cost; security and compliance gaps; team retention; roadmap conflicts.
How do you justify API refactoring over new features to stakeholders?
Tests turning technical drag into business cost. Frame cruft as interest on velocity; quantify incident cost, MTTR, and lead time; advocate incremental cleanup with product work. Avoid demanding a six-month rewrite without product tie-in.
Decide between cutting a feature versus taking technical debt for a deadline
Quantify business risk of both paths, secure buy-in, and lock a time-boxed post-launch remediation plan.
How would you prove roadmap divergence from vision and correct course?
Quantify coupling, complexity, and service creep; link compromises to feature delays; propose a funded ATD roadmap with milestones.
How would you scope a one-quarter v1 against a three-quarter solution?
Tests bounded technical debt via stable interfaces. A strong answer defines a thin core, pushes complexity into swappable modules, documents debt ledger, and negotiates scope cuts. Red flag: promising to refactor later without concrete boundaries or ownership.
How would you frame a major refactoring proposal using product strategy?
Reframing tech debt as delivery risk, not engineering chore. Tie refactoring to velocity loss and firefighting; shift accountability from dev-vs-ops fights to product ownership.
How do you systematically manage and pay down experiment debt?
Tests sustainable velocity through experiment lifecycle hygiene. Strong answers cover isolated experiment directories, TTLs on feature flags, and recurring cleanup sprints. Red flag: banning experiments or treating all experiment code as permanent.
Lifecycle of a feature flag experiment from creation to cleanup
Tests operational rigor across the full flag lifecycle. A strong answer covers six stages: SDK instrumentation with event tracking, phased rollout, monitored experiment, ship/kill decision, and code cleanup.
Quantify UI Debt Before It Compounds
UI debt quantification turns messy interfaces into measurable cost. Teams track component adoption, override rates, and design-dev drift to prioritize refactors. The footgun is treating every inconsistency as debt, ignoring the business value of shipping fast.
Ward Cunningham: Ship Early, But Repay Technical Debt
Ward Cunningham, who coined "technical debt," said shipping early to learn is like a loan: valuable only if you repay fast. Teams that never refactor see progress drop to zero as all effort goes to interest. Use debt to buy learning time, then refactor.
How would you frame technical debt for your manager's business case?
This tests translating debt into business risk and cost of delay. A strong answer quantifies velocity drag, proposes phased remediation via WSJF or capacity allocation, and offers roadmap trade-offs.
Describe a framework to strategically manage tech debt during product discovery
This tests strategic debt tradeoffs under speed pressure. A strong answer classifies debt by interest, caps MVP debt with guardrails, and reserves fixed sprint capacity for repayment. Red flag: vilifying debt or deferring cleanup without triggers.
How do you build a business case for technical debt?
This tests your ability to translate engineering problems into business impact. A strong answer quantifies the debt's cost (e.g., slower velocity), frames it as risk, and proposes a concrete payback plan like allocating 20% capacity.
How do you quantify the cost of technical debt?
This tests translating engineering problems into business impact. Calculate the ongoing time cost per sprint, estimate the fix cost, and present a breakeven point to frame the refactor as an investment.
How do you strategically manage tech debt during product discovery?
This tests your strategic view of tech debt. A great answer defines intentional vs. unintentional debt, outlines a framework for tracking and repayment (like a debt backlog), and explains when it's a valid tool for MVPs.
How do you fix an inverted test pyramid?
This tests your ability to create a pragmatic, multi-sprint plan to improve test suite health. A good answer involves analyzing tests, getting buy-in, then incrementally adding unit/integration tests while refactoring old E2E tests.
Handling a Mandated DoD on a Legacy System
This tests your ability to balance organizational standards with team reality and drive incremental improvement. Acknowledge the org DoD, create a realistic team DoD, and make the gap transparent with a concrete plan to close it.
How do you prioritize tech debt against new features?
This tests your ability to translate engineering risk into business impact. A great answer frames debt as a business cost (slowdown, bugs), quantifies the impact, and proposes a specific capacity allocation. A red flag is framing it as an 'us vs. them' battle.
How do you convince a PO to prioritize technical debt?
Tests your ability to influence without authority by translating technical issues into business impact. A great answer quantifies the cost of inaction (e.g., slowed velocity) and proposes concrete Scrum strategies like allocating 20% capacity.
How do you explain tech debt's business impact to a Product Owner?
Tests your ability to translate technical issues into business value. A great answer quantifies the slowdown (e.g., cycle time), proposes an iterative plan (e.g., 20% capacity), and connects the work to future feature velocity.
How do you build a business case for technical debt work?
Tests your ability to translate technical issues into business impact. Frame debt as business risk, quantify its impact on velocity and cost, and propose a clear, capacity-based plan.
Your team can't meet the mandated Definition of Done. What's your plan?
This tests your pragmatism and ability to manage risk. A strong answer makes the gap transparent, proposes a temporary aspirational DoD, and creates a concrete plan to close the gap. A red flag is ignoring the DoD or asking for a permanent exemption without a.
Flow Debt: The Hidden Cost of Workflow Inefficiency
Flow Debt is the invisible cost of process bottlenecks that slow down delivery. It shows up as work waiting for handoffs, reviews, or decisions. The footgun is blaming individuals for system-level delays instead of optimizing the workflow itself.
Code Smells: Indicators of Deeper Problems, Not Flaws
A code smell is a surface-level hint, like a long method, that suggests a deeper design problem. It's an indicator, not a definitive flaw. The footgun is blindly "fixing" every smell; a smell is a reason to investigate, not an automatic command to refactor.
Get Technical debt bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.