What normalization rules must an anagram check agree on before any code is written?

## Equivalence is relative, and that is the whole question The interview version of this is the pairing everyone has seen: one word and a two-word phrase declared anagrams of each other. They are — *if* case is folded and whitespace is dropped. Under a rule that treats a space as an ordinary character, the two are not anagrams at all, because one contains a space and the other does not. Neither answer is wrong; they answer different questions. That is the point a senior candidate is expected to reach unprompted: "are these anagrams?" is under-specified until the canonicalization is named. In a live feature — say a word game catching shuffled duplicate answers — the canonicalization is not a formatting detail. It is the definition of the product behaviour. ## The checklist to pin down 1. **Case.** Are the inputs folded to a single case before comparison? Folding is not always a simple per-character mapping — some scripts have characters whose folded form has a different length — so "lowercase everything" is a decision to be stated, not an obvious default. 2. **Whitespace and punctuation.** Dropped, or significant? Dropping is what makes multi-word phrases comparable; keeping is what makes the check exact. Pick one and write it down. 3. **Digits and symbols.** Do they participate, or are inputs containing them rejected before the comparison runs? Rejection is often better than silent dropping, because silent dropping makes two visibly different inputs match. 4. **Scope of the alphabet.** Which characters are in bounds at all? This is where a fixed small tally quietly fails: it defines a scope by accident rather than by decision. 5. **The unit being compared.** What counts as "a character" for tallying? Sequences that look the same on screen can be composed from different underlying units. You do not need to solve that here — you need to state which unit your rule counts, so the failure is a known constraint rather than a mystery bug report. ## One rule, one place The most common production failure is not choosing wrongly, it is choosing twice. A feature that stores a canonical form when an answer is accepted, and computes another canonical form when a new answer arrives, has two implementations of the same rule. They agree on the day they are written. Then someone fixes punctuation handling on the ingest side, the comparison side keeps the old behaviour, and the feature starts missing duplicates that its own tests still pass on — because the tests exercise both paths through the same helper the developer happened to use. The fix is structural: the canonicalization is one function, both paths call it, and the tests assert on that function directly with representative inputs from every class the feature claims to support — mixed case, spacing variants, punctuation, digits, accented letters. When the audience widens, those tests fail loudly instead of the feature silently producing false matches. ## The rule is a data format Once canonical forms are persisted — as duplicate-detection keys, as grouping buckets, as an index — the normalization rule has become part of the stored data's contract. Change the rule and every existing key was computed under the old one: new keys stop matching old keys, and duplicate detection silently degrades rather than erroring. The options are the usual ones for a format change: version the key so old and new coexist during a migration, or run a rebuild pass over the stored forms. Either way it is a planned migration, not a one-line edit, and treating it as a one-line edit is exactly the failure this framing is meant to prevent. ## Rejecting versus dropping One judgment call deserves its own mention. When an input contains characters outside the agreed scope, you can drop them, or you can reject the input. Dropping keeps the feature permissive and makes two visibly different submissions compare equal — sometimes desirable, sometimes a bug that reaches users as "why did it say this was a duplicate?". Rejecting keeps the equivalence honest at the cost of turning away input. Choose deliberately, state the choice in the spec, and make the error message say which characters were out of scope. ## What interviewers listen for A candidate who asks the clarifying questions before writing anything; who names case, separators and scope specifically rather than saying "I'd normalize it"; who puts the rule in one place; and who recognises that a stored canonical form makes the rule a migration concern. A candidate who starts coding the comparison without asking has answered a question nobody asked.