Every engineer cuts corners sometimes. So when an interviewer asks about a time you had to choose between shipping quickly and doing it properly, they already know you’ve done it. What they want to find out is whether you can tell which corners are safe to cut, whether you make that decision openly, and whether you come back to it.
Two answers fail almost every time. One is “I never compromise on quality,” which sounds principled but suggests you’d be hard to plan with. The other is “we skipped the tests and it worked out,” which suggests luck rather than judgment.
Not all quality is the same
It helps to think of quality in layers, because the layers have very different costs when you skip them.
- Correctness and safety. Money, data integrity, security, privacy, permissions. Skipping these doesn’t create debt; it creates incidents.
- Operability. Logging, alerts, a rollback path. You can sometimes ship a thinner version, but shipping with none means you won’t know when something breaks.
- Maintainability. Clean structure, test coverage of non-critical paths, removing duplication. These can wait, if you plan to come back.
- Polish. Animations, perfect empty states, nice-to-have UI details. Often the first thing to defer, and users rarely notice.
When you describe a trade-off in an interview, naming which layer each item sat in shows you made a reasoned decision rather than cutting whatever was left at the end.
Deliberate, prudent shortcuts
Martin Fowler’s Technical Debt Quadrant sorts shortcuts along two axes: deliberate or inadvertent, and reckless or prudent. “We don’t have time for design” is deliberate and reckless. “Now we know how we should have done it” is inadvertent and prudent: you learned something by building. The quadrant you want your story to sit in is deliberate and prudent: “We must ship now and deal with the consequences,” said by people who know what the consequences are.
That’s a useful way to frame your answer. You knew what you were taking on, you wrote it down, and you had a plan for it.
Worked example: a checkout redesign before a sale
Here’s an illustrative scenario. Treat it as a pattern for organizing your own story, not as a story to retell.
A retail team is launching a redesigned checkout two weeks before a seasonal sale. You’re the engineer on the payment step, and the remaining work doesn’t fit:
- Server-side validation of discount codes
- A check that customers can only view their own order confirmation pages
- Automated tests for the new address form
- Merging three copies of price-formatting code into one module
- Animated transitions between checkout steps
- Autocomplete for saved addresses
A risky answer (illustrative, weak):
We were really tight on time, so we decided to skip the automated tests and some of the validation to hit the date. It all worked out fine and the sale went well.
It may be true, but it skipped validation on a payment flow and got lucky. An interviewer will worry about what happens next time.
Stronger version (illustrative; use your own list and decisions):
With two weeks left, I listed what remained on the payment step and sorted it by what would happen if we shipped without it. Discount-code validation and the check that customers could only see their own order pages were non-negotiable: one was money, the other was customer data. I kept the address-form tests, but only for the happy path and the two errors that block payment, and left the rest of the cases for later.
I proposed deferring the price-formatting cleanup, dropping the step animations and moving saved-address autocomplete to after the sale. The product manager agreed to all three. For the cleanup, I opened a ticket explaining the duplication and the risk (a formatting fix applied in one place but not the others), put a short code comment linking to it in each copy, and we scheduled it for the sprint after the sale.
Checkout launched on time and handled the sale without payment issues. The cleanup actually slipped one more sprint because of post-sale bug fixes, and it was done about three weeks later. Next time I’d agree the follow-up slot before shipping, so it competes less with whatever comes up afterwards.
Each item is placed in a layer, the person who owns the scope agreed, the shortcut is recorded with its specific risk, and the result admits the follow-up slipped.
Writing the shortcut down
A shortcut nobody recorded is just a defect waiting to be found. What makes it deliberate is the record. A useful one is short: what was deferred, why, what could go wrong in the meantime, who owns it, and what should trigger coming back to it (a date, a sprint, or an event like “before we add a fourth currency”).
A comment in the code pointing to the ticket helps the next person who reads that file understand that the duplication is known, not an accident. Mentioning that you did this tells the interviewer you think about the people who come after you.
The follow-up is part of the answer
Expect “Did you ever go back and fix it?” If you did, say when. If you didn’t, say so plainly and say what you’d change, such as getting the follow-up into a specific sprint before shipping rather than “soon after.” A candidate who admits the debt is still there and has a view on why is more believable than one whose every shortcut was repaid on schedule.
Mistakes that weaken the answer
- “I never compromise on quality.” It doesn’t match how software gets built, and interviewers know it.
- Calling everything technical debt. A missing permission check isn’t debt; it’s a vulnerability.
- Cutting correctness or security and presenting it as pragmatism.
- No record and no plan. Without them, the shortcut was a hope, not a decision.
- Blaming product for the pressure. Deadlines are normal; the story is about how you handled one.
Follow-up questions to expect
“Who decided what to cut?” The scope decision usually belongs to the product owner, with your recommendation. Say who agreed.
“How did you know the reduced tests were enough?” Explain the reasoning: they covered every path that could stop a customer paying, and the deferred cases were cosmetic validation messages.
“What would make you refuse to ship?” Name a line you wouldn’t cross, such as a known way for one customer to see another’s data, and say you’d escalate it rather than quietly comply.
Interview practice: sort a pre-launch list
Two days before launching a new public signup flow, five items remain. Which do you insist on, which do you defer, and why?
- (a) Rate limiting on the signup endpoint
- (b) Dark-mode styles for the signup pages
- (c) Unit tests for an internal admin report on signups
- (d) A tested rollback script for the database migration
- (e) Translations for a market launching in three months
Answer and reasoning
Insist on (a) and (d). Rate limiting on a public signup endpoint is a safety item: without it, bots can create thousands of accounts or use the form to send spam, and cleaning that up costs far more than building the limit. A tested rollback script is operability: if the migration goes wrong on launch day, you need a known way back.
Defer (b), (c) and (e) with records. Dark mode is polish. The admin report tests matter for maintainability, but the report is internal, so a bug there affects your own team rather than customers; open a ticket and schedule it. Translations have a real date three months away, so they belong in the plan for that launch, not this one.
What makes the answer strong is the reasoning by layer, not the specific choices. Someone could reasonably argue the admin report tests should stay if finance relies on the report for billing. If you can explain why each item sits where it does, the interviewer sees the judgment they were asking about.
Related reading on technical debt
- Behavioral and HR interview questions
- Behavioral and HR multiple-choice questions
- Behavioral: Advocating for Technical Debt Work, for getting the deferred work scheduled later
- Behavioral Interviews: Handling an Unrealistic Deadline
- Martin Fowler: Technical Debt Quadrant