skip to content

An account record holds a boolean active flag plus an optional credential — how many states can it hold, and how many are legal?

level: juniorimportance: should knowfreq 48%

answer

  1. independent fields multiply
  2. collapse each field to present or absent
  3. two by two, not string values
  4. compare against the domain's vocabulary
  5. the gap is your defensive code budget

basics

~20 s

Four representable states, two legal. Counting the credential only as present or absent, the two independent fields multiply to 2 × 2 = 4 combinations, and the domain allows only invited-without-credential and active-with-credential — the other two were never meant to exist.

solid answer

~40 s

The two fields vary independently, so the number of states the record can hold is the product of their options. Treating the credential as just `present` or `absent`, that is 2 × 2 = 4. The domain recognises only two of them: invited with no credential, and active with one. The remaining two — active with nothing to authenticate against, and a credential attached to an account nobody proved — are representable but meaningless. The count is the point of the exercise: it turns a vague feeling that the record is "a bit loose" into a number, and a redesign is judged by whether that gap between representable and legal closes to zero.

code

pseudocode · 7 lines
pseudocode
// shape A: one record, fields vary independently
record Account: active (boolean), credential (present | absent)
// representable = 2 * 2 = 4 ; legal = 2 ; gap = 2

// shape B: a closed choice of two variants
type Account = Invited(address, invitedAt) | Active(address, credential)
// representable = 2 ; legal = 2 ; gap = 0

go deeper

for a junior

Recall the multiplication: independent fields multiply their options, so a boolean beside a present-or-absent field gives four. Then say which of the four the business has a name for.

for a middle

Explain why the multiplication is valid — nothing stops the fields varying separately — and show that the redesign changes the count itself rather than adding a guard against the bad rows.

for a senior

Use the count as review evidence: point at the gap, say which read sites currently pay for it, and judge whether closing it is worth the change in a live codebase.

for a principal

Treat the gap as a running cost that scales with the number of readers and the number of flags. Say where you would spend a redesign and where a wide space is legitimate, such as an uninterpreted edge shape.

## Counting is the diagnostic "This record is a bit loose" is a feeling. "This record can hold four states and the business recognises two" is a measurement, and it is the fastest way to argue for a redesign in review. The counting rule is simple: fields that vary **independently** multiply their options together. Take the account record with a boolean `active` and a `credential` that may be absent. To keep the arithmetic about the *shape* rather than about the credential's contents, count the credential as exactly two possibilities: present, or absent. Then: - flag: 2 possibilities (`true`, `false`) - credential: 2 possibilities (present, absent) - representable states: 2 × 2 = **4** Now list which of the four the domain has a name for: | State | Domain name | Legal? | |---|---|---| | `false`, absent | invited | yes | | `true`, present | active | yes | | `true`, absent | none | no | | `false`, present | none | no | Two of four. Half the space the type admits is space nothing in the business can describe, and every one of those states will eventually be reached by a partially-written migration, a defaulted field, or a message that arrived half-populated. ## What the gap predicts The ratio of representable to legal states predicts how much defensive code the value forces on its readers. Each illegal state has to be excluded somewhere, and if it is not excluded by the shape it is excluded by a guard — or, far more often, by nobody, which is the bug. So the number is not trivia. It is a budget: 1. **Count the states the shape admits.** Multiply the independent fields' options. 2. **Count the states the domain names.** Ask the person who knows the business which combinations mean something. 3. **The difference is what your code is currently obliged to handle by hand.** A difference of zero means the shape carries the rule. ## Closing the gap Replace the single record with a closed choice of two variants — *Invited*, carrying an address and an invitation time; *Active*, carrying an address and a required credential. Count again. There are now exactly two constructible shapes, and the domain names both. The gap is zero, and the phrase for that is that the illegal states have become **unrepresentable**: not forbidden, not validated against — unnameable. The same arithmetic explains why adding another loosely-related flag makes things worse quickly. A second independent boolean whose truth decides whether a third field is meaningful takes the record to 2 × 2 × 2 = 8 representable states while the domain may still recognise three. The gap grows multiplicatively while the domain's vocabulary grows by one word at a time. ## Counting honestly A few cautions keep the exercise from turning into theatre: - **Count possibilities, not values.** If the credential is a string, its own possibilities are astronomically many and swamp the arithmetic. What matters is how many *shapes* the record has, so collapse each field to the distinctions the rule turns on — here, present or absent. - **Independence is the assumption being tested.** The multiplication is only right because nothing in the type stops the fields varying separately. That is precisely the property the redesign removes. - **Not every extra state is a bug in waiting.** Some spaces are legitimately larger than their domain, especially at the edges of a system where input has not been interpreted yet. The count tells you where to look, not what the verdict must be. - **Zero gap is the goal, not always the outcome.** Some rules relate values that are not both present in one record; those cannot be closed by reshaping this record alone, and pretending otherwise produces contortions worse than the guard they replace. ## How the question is actually asked An interviewer rarely says "count the inhabitants". They show the record, describe the rule in one sentence, and ask what is wrong with it. The candidate who answers "it lets you build an active account with no credential, and one other combination just as impossible" has demonstrated the whole skill: reading a shape, comparing it against the domain's vocabulary, and naming the states that fall in the gap. The candidate who answers "you should validate it" has described the symptom's treatment and not the illness.

  • Why count the credential as two possibilities instead of every value it could take?
    Because the rule turns only on whether it is there. Counting its contents makes the arithmetic enormous and hides the shape defect. Collapse each field to the distinctions the invariant actually uses, then multiply; the interesting number is how many shapes exist, not how many values.
  • What happens to the count when a second independent flag is added?
    The representable states multiply again — 2 × 2 × 2 = 8 — while the domain usually gains at most one more named situation. The gap grows multiplicatively and the defensive code needed to cover it grows with it, which is why these records rot fast.

saying these in an interview costs you the question

  • Counts every possible credential value and gets a meaningless number
  • Says the record has two states because the domain has two
  • Assumes a constructor check changes how many states are representable
  • Thinks the illegal combinations are rare enough to ignore
  • Treats the exercise as arithmetic with no design conclusion