The team can ship in six weeks with an approach that will need rework, or five months with one that will not. How do you decide, and what do you do either way?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can make a debt decision deliberately rather than by default, and whether you know which debts are cheap and which are not.
The deciding questions
1. What is the cost of being late? For a product still proving demand, or a regulatory deadline, or a competitor window, three months of delay may be existential. For an internal tool with no deadline, it is nearly free. This is the term most often left unspoken, and it usually dominates.
2. What is the probability we still care in a year? Debt on something that will be replaced or retired is never repaid, which makes it free. Debt on the system's core is compounding.
3. Which kind of debt is it? This is the part that separates a good answer from a slogan:
| Debt in | Cost to repay | Verdict |
|---|---|---|
| Internal implementation of one module | One refactor | Cheap — take it |
| Test coverage | Grows, but bounded | Risky — take it only briefly |
| Data model / schema | Migration under load | Expensive |
| Public API or event contract | Every consumer must change | Expensive |
| Service boundaries | Effectively a rewrite | Very expensive |
| Security posture | Breach, and it is not "debt" | Never |
So the answer is rarely "fast" or "slow" wholesale. It is fast in the cheap places, careful in the expensive ones — which frequently produces a third option somewhere between six weeks and five months, and finding that option is the actual work.
4. Is the debt reversible on our own schedule? Debt that will be forced due at an unpredictable moment (a security or compliance issue) is different from debt you can choose to repay next quarter.
What you do either way
If you take the debt: write down what it is, what it costs per change, what triggers repayment (a user count, a latency figure, a date), and put the repayment in a backlog with an owner. Undocumented debt is not debt, it is mess — it has the interest payments and none of the deliberate benefit.
If you take the slow path: say explicitly what the extra fourteen weeks buys, in terms the business recognises. "It is better engineered" is not an answer; "it avoids a migration that would cost eight weeks and a maintenance window at 40,000 users" is.
What a strong answer adds
Rejecting the framing that this is a one-time choice. Almost every real answer is: ship the six-week version with the expensive decisions made properly — clean module boundaries, a schema you can live with, a stable public contract — and take the debt in the implementation, which is the part you can rewrite quietly later. That is not a compromise between the two options; it is the option neither party proposed.