A layout change is expected to change a table's row count — so what claim replaces the row count on that step?
answer
- the row count is allowed to move
- find what the step preserves
- count filled cells, not all cells
- compare totals within a tolerance
basics
~20 sAssert a quantity the step is supposed to preserve: the number of non-absent value cells, the total of each measure, and the number of distinct entities. Rearranging a table moves measurements around; it must not create or destroy them.
solid answer
~50 sWhen a step turns one row per measurement into one column per measure, the row count is meant to fall, so equality across the step is the wrong claim — but abandoning the check entirely is how a step that quietly combined values ships. Find what the step preserves instead. Three claims work: the count of non-absent value cells before and after, the total of each measure column, and the number of distinct entities, which is often exactly what the new row count should be. Two details make them meaningful. Count filled cells rather than all cells, because a wider layout creates a cell for every combination including the ones that never occurred. And compare totals within a stated tolerance where the values are fractional, since summing the same numbers in a different order moves the last digits. If a total comes out lower, the claim has done its job and stops there.
go deeper
Remember that a step allowed to change the row count still gets a check — you assert something it should preserve, such as how many filled value cells there are before and after.
Explain why the filled cells rather than all cells is the claim after a widening step, and compute the expected row count from the number of distinct entities instead of accepting that the count simply changed.
Show judgment about the comparison itself: a tolerance sized for reassociated fractional arithmetic and not for data loss, a total per measure rather than one combined figure, and stopping at the failed claim rather than repairing the data inside the check.
The angle is what evidence a rearranged result must carry before anyone reports from it, and what it costs: one extra pass per measure, spent where the layout changes, against a wrong total that nobody can trace.
## Why the row count stops being the claim A step that rearranges a table between **one row per measurement** and **one column per measure** is supposed to change the row count. Many measurements for one entity become one row with several columns, so equality either side would fail on every correct run, and a claim that always fails is deleted within a week. The mistake is to conclude that this kind of step cannot carry a claim. It can — you just have to ask what the step promises rather than what the previous step promised. The promise is **conservation**: a rearrangement moves measurements to different cells; it must not create or destroy them. ## Quantities a layout change should preserve - **The number of non-absent value cells.** Every measurement that existed before should exist after, in a different place. This is the most direct statement of the promise. - **The total of each measure.** A sum over a column is one pass and catches values that were combined, replaced or dropped even when the cell count happens to work out. - **The number of distinct entities.** The set of entities is the same set before and after, whichever way round the layout is. - **The expected row count, computed rather than preserved.** Often the new row count is not arbitrary at all: it should equal the number of distinct entities. That is a far stronger claim than "the count changed, which was expected", and it is available to you the moment you write the step. | claim | catches | does not catch | |---|---|---| | filled cells before == after | measurements lost or invented | two measurements combined into one value whose total is unchanged | | total of each measure, within a tolerance | values dropped, combined or replaced | two values swapped between entities | | row count after == distinct entities | a step that produced more rows than there are entities | anything about the values themselves | None of these is a complete proof, and together they are cheap and catch most of what actually goes wrong at this step. ## Making the claim well-defined Two details decide whether the claim means anything. **Count filled cells, not all cells.** Turning measures into columns creates a cell for every combination of entity and measure, including combinations that never occurred. Those cells hold an **absent-value marker** — whatever the tool puts in a cell where no value exists, and different tools put different things there. A claim over the total number of cells therefore fails on every correct run of a widening step; a claim over the non-absent cells is the one that holds. Say explicitly which you mean, and say what your total does with absence, because tools differ in whether an absent cell propagates through a sum or is skipped — the claim has to be a statement about a defined number. **Compare totals within a tolerance where the values are fractional.** Values held as fractions are summed in whatever order the step happens to visit them, and reassociating the additions moves the final digits. An exact comparison then reports a difference that is arithmetic noise rather than data loss. State **absolute and relative tolerance** — how far apart two numbers may be in fixed units, and as a fraction of their magnitude — and size them for the noise, not for the loss. A tolerance generous enough to hide a missing measurement has quietly retired the claim. Totals over values held exactly as whole numbers need no tolerance at all. ## Where the claim stops Suppose the total comes out lower after the step. You now know something precise and limited: **measurements did not survive this step**, and you know it at the step rather than from a report three days later. You do not yet know why, and the assertion is not the place to work it out or to repair it. It hands you the step, the quantity and the size of the gap, which is exactly the evidence the next person needs. The same discipline generalises past layout changes. Any step whose whole purpose is to change the row count — reducing many rows to one per group, expanding a range into one row per day, removing rows by a condition — has a quantity it is supposed to preserve or a count it is supposed to produce. Write that down as the claim instead of the equality that no longer applies, and the step keeps its evidence instead of becoming the one place in the file where nothing is checked.
- The table has several measure columns. Which total do you assert?One per measure column, or the count of non-absent cells across all of them, and preferably both. Summing unlike measures together into one number produces a total that can stay the same while two of its parts move in opposite directions, which is precisely the defect the claim exists to catch.
- How do you make the total well-defined when the measure column holds absent cells?State the rule rather than inheriting one: sum over the non-absent values and count them separately, so the claim is two defined numbers. Tools differ in whether an absence propagates through a sum or is skipped silently, and a claim whose value depends on which design you happen to be running is not a claim.
saying these in an interview costs you the question
- Drops the check because the row count legitimately changed
- Compares fractional totals for exact equality
- Counts all cells including the absent ones a wider layout created
- Assumes a rearrangement cannot lose measurements
- Sets a tolerance loose enough to absorb missing data
- Sums unlike measures into one total and asserts that