Your codebase updates tables by writing into selected rows — what standing rule would you set so a lost or misplaced write cannot reach production, and what does it cost?
answer
- name the failure class first
- silent, value-level, structurally perfect
- review rule versus runtime check
- scope by blast radius, not uniformly
- a read-back is another pass
basics
~20 sScope the rule by blast radius rather than applying one everywhere: reject split-address writes in review across the codebase, and require a value read-back only where the written table is consumed by a later step. Each control has a different price.
solid answer
~50 sStart by naming the failure class you are buying protection from: a write that completes, raises nothing, changes no row count and leaves the wrong values behind. Two controls address it at very different prices. A **review rule** — the whole target in one statement, never address-then-assign — costs nothing at run time and is visible in the shape of the line, so apply it everywhere. A **read-back** — re-read the addressed rows and compare the values — costs another pass over those rows every run, so spend it where a wrong value would escape the step that produced it. Defend both by the class of defect they remove, not by taste, and expect the rule to look different on a design that is immutable by default, where the same class of loss wears a different costume.
go deeper
You are not expected to set the policy, but you are expected to follow it: put the whole target in one statement, and check the values afterwards when someone else will use the result.
Be able to explain why the rule exists — that this failure raises nothing and changes no shape — and to apply it without needing the reasoning re-derived each time.
Show where you would and would not spend the read-back, and justify the boundary by where a wrong value stops being visible to the person who produced it.
Argue the policy from the class of defect, its escape path and its cost, concede the cases where it buys nothing, and state the boundary so the rule survives a deadline.
## What you are actually buying Before choosing a rule, name the failure precisely, because that is what decides which controls are worth their price. The failure here is a write that: - completes without raising anything; - leaves the number of rows and columns unchanged; - produces output that is structurally perfect and wrong in individual values; - reads, at the call site, exactly like a write that worked. That combination is what makes it expensive. There is no crash to page on and no shape to notice, so the defect is found downstream — often much later, by someone who does not know the code that produced it, and usually after a decision has been taken on the number. ## Candidate rules, and what each is worth | rule | what it catches | what it costs | |---|---|---| | the whole target in one statement; never address then assign | the value landing in a discarded intermediate | nothing at run time; some friction where a design has no combined write | | build the replacement and assign it back in one statement | the same class, where no combined write exists | a full-length column of values per update | | read back the addressed rows and compare values | everything above, plus a misplaced or unsupplied value | another pass over the written rows, every run | | state whether a write's population is as of before the sequence or as of now | order-dependent reclassification | a line of code and a moment's thought | The first and last are close to free and should be unconditional. The middle two cost real work and should be scoped. ## Scoping by blast radius The question is not whether a wrong value is bad, it is how far it travels before someone would notice: 1. **Exploratory work whose result nothing else reads** — the review rule alone. A read-back here buys nothing, because the author is looking at the values anyway. 2. **A step whose output another step consumes** — read back. This is the boundary at which a wrong value stops being visible to the person who created it. 3. **Anything feeding a published figure or an automated decision** — read back, and treat the check as part of the step rather than as an optional extra someone can comment out under time pressure. A rule that applies uniformly is easier to state and reliably gets routed around, because the people paying for it in the cheap case can see it buying nothing. A rule scoped to where the failure escapes survives contact with a deadline. ## The costs people underestimate - **A read-back is another pass.** On a large table that is not free, and on a pipeline with dozens of updates it compounds. Read back the addressed rows, not the whole table. - **A blanket ban on in-place writes** pushes people toward rebuilding whole columns, which under an eager evaluation model is a second full allocation per step; under a design that shares untouched buffers or defers the duplicate until a write it is much cheaper. The rule's cost therefore depends on which model the codebase is in, and you should say which before you argue about it. - **Rules that cannot be checked mechanically decay.** A review rule about the shape of a statement is checkable by eye and by a lint-style pass; a rule about intent is not, which is why the population rule is expressed as a required comment rather than as a prohibition. ## Where the question changes shape On a design that is immutable by default the two-step write cannot corrupt anything, because there is nothing to corrupt: every step returns a new object. But the same **class** of silent loss is still available — the new object is simply never assigned back, and the pipeline carries on with the old one. A rule written against one design's mechanism protects nobody working in the other. Write the rule against the class: *a modification whose result is not observably present in the object later steps read is a defect, whatever the mechanism*. ## How to defend it Defend the rule by the class of silent failure it removes and by where that failure would escape, never by taste or by habit. Concede the cases where a colleague is right that it buys nothing, and scope it out of them explicitly — a rule with a stated boundary is one people apply inside that boundary, while a rule presented as universal is one people quietly stop applying at all.
- Why is a review rule against the split-address write cheaper than a runtime check?It costs nothing at run time and the whole signal is the shape of the statement, so it is checkable by eye and by a lint-style pass. A read-back costs another pass over the written rows on every execution. Apply the cheap rule everywhere and spend the expensive one only where a wrong value would leave the step that produced it.
- A colleague says the rule is noise because their tool cannot lose a write. How do you answer?Grant the point for that design and scope the rule rather than defending it universally. On an immutable-by-default design nothing is corrupted, but the result can still be dropped by never assigning it back — the same silent class in a different costume. State the rule against the class of failure, not against one tool's mechanism.
- How do you stop a mandated read-back from being commented out under deadline pressure?Make it part of the step rather than an addendum to it, so removing it is a visible change to the step's contract rather than deleting a line that looks like debugging. And keep it scoped, so the people it slows down are the ones it is actually protecting.
saying these in an interview costs you the question
- Mandates a read-back on every write regardless of what consumes the result.
- Defends the rule by style or taste rather than the failure it removes.
- Assumes one rule fits every design a mixed codebase uses.
- Relies on a tool's diagnostic as the codebase's guarantee.
- Treats an extra full pass over a large table as free.
- States the rule with no boundary, so nobody can tell where it stops applying.