For a payroll adjustment task in integer cents, why ask about amount ranges and signs upfront?

## Constraints are inputs to the design Candidates treat "what's the range of the values?" as a formality, answer it themselves with "probably fine", and move on. It is not a formality. Magnitude, sign and precision each rule whole families of approaches in or out, and every one of them is settled by a single sentence during clarification or discovered later at a much worse price. A payroll adjustment task makes the point concretely because the units invite complacency. Amounts are in integer cents, which sounds like it disposes of the hard question — no fractional arithmetic, no rounding drift, everything exact. It disposes of *one* hard question and creates another: cents make the numbers roughly a hundred times larger than the currency figures a reader is picturing. ## Magnitude: the intermediates overflow first The useful framing is that inputs rarely overflow — intermediates do. Any single adjustment in cents is small. A sum across every employee, or across a year of pay periods, is not. A signed 32-bit accumulator holds values up to 2,147,483,647; in cents that is roughly 21.5 million currency units, a threshold an ordinary mid-sized payroll passes routinely. So the clarifying question is not "how big is one amount" but "how big can anything I compute from them get": totals, differences, and anything scaled or multiplied. Ask for the row count too, because the ceiling you care about is the product of a plausible per-row magnitude and a plausible row count, not the magnitude alone. What happens at the ceiling depends entirely on the environment — some runtimes wrap silently to a nonsensical negative total, some fault, and some promote to arbitrary-precision arithmetic and never notice. Three different outcomes for the same overflowing sum, which is exactly why you do not want to be finding out empirically. The mechanics of fixed-width arithmetic are a topic of their own; the clarify-phase point is narrower and complete on its own: a ceiling exists, and you need to know whether the data can reach it before you pick the accumulator. ## Sign: it removes monotonicity, not just validity "Can an adjustment be negative?" sounds like a validation question, and candidates answer it as one — a guard clause, an error message. The real consequence is structural. Negative values remove the guarantee that a running total moves in one direction, and monotonicity is the precondition behind a surprising number of shortcuts: early termination once a threshold is passed, discarding a prefix that can only have made things worse, reasoning that a partial result can only improve. Every one of those is silently invalid the moment a clawback or a correction can appear in the data. This is why the sign question belongs in the clarify phase rather than the error-handling phase. Its answer can change the approach, and an approach change is cheap only before there is an approach. ## Units and precision, briefly The third member of the family: what exactly is the unit, and is any operation allowed to produce a value that is not a whole one? If a task involves percentages, proration across pay periods, or splitting an amount, then something has to be rounded, and *who* rounds and *in which direction* is a business decision that changes the output. "Everything is integer cents" is a strong and welcome constraint precisely because it forbids that question from arising silently — but it forbids it only if the intermediate steps honour it too. ## When the interviewer waves it off "Assume everything fits" is a perfectly normal answer, and it is not a wasted question. Repeat it back as a precondition and attach a number to it: "so I'll use a fixed-width accumulator on the assumption totals stay under a couple of billion cents — if annual, company-wide totals are in scope, that assumption goes and I need a wider accumulator." You have now shown you know where the boundary is and what moves it, which is the entire point of having asked. That is more valuable than the guard clause you did not get to write. ## Why this reads as production experience Arithmetic ceilings, sign changes and rounding are three of the most common sources of quiet, expensive defects in financial code, and they share a signature: the code is correct on every example anyone tried, and wrong on data the examples did not reach. Asking about them during clarification signals someone who has debugged that class of failure and would rather not again. Asking about them *after* writing the code signals someone who is about to.