How do you decide when a quick fix is good enough and when to do it properly?
answer
- your two or three deciding factors
- the fast lane, with a real example
- the line you never cross
- how the IOU gets recorded
- what the rule has cost you
basics
~20 sTests whether your quality bar is a rule others could apply, not a mood. Answer with two or three deciding factors, a fast lane you really use, a line you never cross, and how debt gets recorded.
how to answer
5 beats- the two or three questions you ask yourselfOpen with the criteria, not with a story. Reversibility, blast radius and who absorbs the failure are the durable ones; pick the ones you actually use and state them in a sentence each so an interviewer can apply them to their own codebase.
- the fast lane, with a real exampleName a class of work where a quick fix is the right answer and give one thing you deliberately did cheaply. Without this beat the answer reads as purity, which interviewers hear as never having shipped under pressure.
- the line you do not cross, and whyDescribe the work where you always do it properly and tie it to a property, not a feeling — irreversibility, money moving, a customer absorbing the failure. One vivid consequence lands better than three abstractions.
- what happens when you do go fastGive the mechanics of the IOU in a sentence or two: where it is written, what trigger makes it due, and who outside engineering hears about it the same day.
- what the rule has cost youClose with a time holding the line was expensive and you held it anyway. This is the beat that proves the rule is real rather than an interview answer, so do not skip it for time.
your answer
4 story prompts- Write your criteria as three questions you could ask about any change in a minute.
- Pick one change you deliberately did cheaply and one you refused to rush.
- Name the class of work where you hold an absolute floor, and why it is absolute.
- Have one moment ready where your own rule cost a date and you kept it anyway.
draft and rehearse your own answer in a learn session
go deeper
Probes engineering judgement rather than a single episode: whether you hold transferable criteria for the speed-versus-quality trade or decide by mood and deadline proximity. A strong answer names two or three factors, shows a lane where speed is genuinely correct, names a floor you do not go under, and explains how a shortcut is recorded when you take one.
I run it on three questions: how reversible is this, who eats the cost if it is wrong, and does it touch money. Reversible and internal, I go fast without much agonising. At one client a reconciliation report that thirty-odd finance people read each morning was being assembled by a query nobody enjoyed. I patched it with a materialised view and a scheduled refresh in an afternoon instead of doing the modelling work properly, because if it is wrong for one morning somebody reruns it and swears at me. The blast radius is an inbox. The pay button is the other lane. Anything that can take a customer's money and not tell them, or tell them and not take it, I do properly the first time even when properly costs three or four extra days. Those failures are not reversible — you cannot un-double-charge a card, you can only refund and apologise, and the client wears that in their support queue for a week. The third question decides the IOU. When I do go fast, the shortcut gets a ticket with a trigger condition rather than a date, and that trigger goes to whoever is paying, in writing, the same day. My working rule of thumb is that if I would be uncomfortable saying the shortcut out loud in the client review, I am not allowed to take it.
The three questions are portable, and each one is grounded in work rather than left abstract. The fast-lane example is what keeps this from sounding like purity, and the discomfort test at the end gives the interviewer a memorable, checkable heuristic. It would downlevel if the criteria never touched who absorbs the failure.
At this point my answer has to survive me not being in the room, so I turned the judgement into two things the team applies without me. The first is a tiering of the code. Across three client engagements we wrote down which paths are money paths — authorisation, capture, refund, webhook replay — and put a floor under them: a release does not go out if payment-path coverage on those files drops into the seventies, and the pipeline fails on it rather than a human noticing in review. Everything outside that tier, internal tooling and back-office screens and reporting, ships at whatever bar the person doing it thinks is right, and I deliberately stopped reviewing those with the same eyes. The second is a debt register that somebody actually reads. Every deliberate shortcut gets an entry with the trigger that makes it due, an owner and an estimate, and I take that register into the client's fortnightly steering meeting. That last part is the whole trick — debt an engineering team holds privately is a rumour, debt the person paying has looked at is a scheduled cost. Where it has cost me: two releases slipped a day each because the floor held and I would not sign the exception. I would rather explain a day than an incident, and I said that to the client rather than hiding the reason for the slip.
The move a level note cannot carry is externalising the rule — a pipeline check and a register in a steering meeting, so the bar does not depend on this person's attention. Naming two slipped releases and refusing the exception out loud is the evidence that the floor is real. Vague ownership of the register would downlevel it.
You are not expected to set the bar. Show you know which questions to ask — can this be undone, who absorbs it if it is wrong — and that you take a knowing shortcut to someone senior before shipping it rather than after.
Your criteria should be concrete enough to apply without asking anyone: cost of the wrong outcome, how easily it is reversed, whether a customer or only a colleague eats the failure. Ground each factor in a call you actually made.
The bar should live outside your head as a checked threshold, a review rule, or a tier of code where speed is fine and a tier where it never is. Be ready with a time the rule cost a day and you enforced it anyway.
Frame it as policy: how quality bars are set per risk tier across teams, how deliberate debt is surfaced to the people funding it, and how you stop the rule becoming either a rubber stamp or a permanent blocker.
saying these in an interview costs you the question
- Answering it depends without ever naming what it depends on
- Claiming you never cut corners, which reads as inexperience rather than rigour
- Criteria that all quietly reduce to how close the deadline is
- A stated rule with no example of it applied to real work
- Nobody outside engineering ever hears about the trade in your account
- Where is that line written down, if anywhere?Be honest about the maturity. A rule in your head is a starting answer; a rule in a pipeline check, a definition of done or a review checklist is a stronger one. If it is informal, say what you would write down first and why that piece matters most — that shows you know the difference between judgement and a standard.
- When has that rule cost you a delivery date?Give a concrete instance, including the discomfort. A quality bar nobody has ever felt is not a bar. Say what slipped, who you told, and how you explained the trade to whoever was waiting. Being unable to name a single cost suggests the rule bends whenever it is inconvenient.
- Who gets to overrule you on that?Show you know the decision has an owner and that it is often not you. Name the role, describe how you make the risk legible so their decision is informed, and say what you do once it goes against you — document the exposure and add the guardrail, rather than sulking or quietly re-litigating it later.