An e-signature product has accumulated 300 suppressions of the design system's raw-color lint rule; how would you review them and stop the count from growing?
answer
- a suppression is a decision
- group by reason, not by file
- rule wrong, system gap, or debt
- new suppressions routed for review
- ratchet: the count only falls
basics
~20 sGroup suppressions by reason, not file: system gaps, an over-broad rule, data-driven values, debt. Fix gaps and the rule first, burn down the debt, then require reasons, route new suppressions for review and fail CI if the count rises.
solid answer
~50 sA suppression is a recorded decision to leave the system's path, so I would treat 300 of them as 300 small decisions to audit, not as lint noise. First **group by reason**: a cluster pointing at one missing token or variant is a **system gap** to fix centrally; a cluster of false positives means the **rule is too broad**; data-driven values such as a sender's brand color need a proper **extension point**; the rest is usually **debt** — literals nobody bothered to replace. Fix the gaps and the rule first, because they delete suppressions in bulk. Then stop the growth: a **required reason** on every suppression, **routing** of new ones to the system team for review, a CI check that fails if the **count rises** above the recorded baseline, and a trend report per team. The count should only fall.
go deeper
Recall what a suppression is and that each one should carry a reason explaining why the code leaves the system's path.
Explain why grouping by reason reveals system gaps, over-broad rules and debt, and why fixing gaps first deletes suppressions in bulk.
Show how you would stop regrowth with required reasons, routing to the system team, a ratchet in CI, expiries and a trend report — without making review a bottleneck.
Weigh central review load against product autonomy, and decide how much exception traffic the system team can absorb before the rule or the system itself must change.
## What a suppression is A **suppression** is an inline or file-level instruction that tells a lint rule to ignore a specific violation. For a design-system rule — such as one forbidding raw color values — each suppression is a small, recorded decision that this code stays off the system's path. That makes suppressions valuable data: they show exactly where the system and the product disagree. Three hundred of them usually means the decisions stopped being reviewed. Nobody made one big mistake; each suppression got a build green on a busy day. ## Step 1: group by reason Sorting by file tells you where they are. Sorting by **reason** tells you what to do. For an e-signature product, a typical breakdown: | Group | Example | Action | |---|---|---| | System gap | A status color for the declined state has no token | Add the token centrally; replace every suppression that used it | | Rule too broad | The rule flags colors inside test fixtures and document previews | Narrow the rule's scope or allowlist those paths explicitly | | Data-driven value | The sender's brand color in the signing header | Provide an extension point; remove the literal entirely | | Third-party content | Colors from the customer's uploaded document | Keep as a file-level exception with a recorded reason | | Debt | Literals copied from old screens, no reason given | Replace with tokens, team by team | If suppressions carry no reasons, the first pass is reading the code around each one — tedious, but it is the only way to classify them. ## Step 2: fix the causes that delete suppressions in bulk - **System gaps first.** One new token for the declined status can delete forty suppressions at once, and it helps every other product with the same need. - **Then the rule.** If a quarter of the suppressions are false positives, the rule is teaching engineers that suppressing is normal. Narrowing it restores trust. - **Then extension points** for data-driven values, so the literals disappear rather than being permitted. - **Then the debt**, spread across teams and tracked like any backlog. ## Step 3: stop the growth Cleaning up once is pointless if the process that created the pile remains. Put in place: 1. **A required reason.** A suppression without a reason, or without a link to a system request, fails the check. 2. **Routing.** Changes that add a suppression of a design-system rule are routed to the system team for review, using the repository's ownership rules — a quick look, not a gate that waits days. 3. **A ratchet.** CI records the current count per rule and fails if a change increases it, so the count can fall but never silently rise. Legitimate new exceptions are approved by lowering something else or by the system team adjusting the baseline. 4. **Expiry for gap-driven exceptions.** When the requested token or variant ships, the linked suppressions are flagged for removal. 5. **A trend report** per team and per rule, so the system team sees where gaps are appearing before they become another pile. ## Reviewing a single new suppression When a routed suppression arrives, the reviewer asks: - Is the reason real, or does a token already exist for this role? - Is this a gap the system should fill for everyone? - Is the scope as small as possible — one line rather than a file? - Will anything remove it later, or is it permanent by design? ## What success looks like The count falls release by release, new suppressions arrive with reasons that a reviewer can accept or redirect, and clusters trigger system changes rather than more suppressions. The product still has exceptions, and it should: third-party document content will always sit outside the system. The difference is that every exception is known, justified and owned. Signs the process is working: - New suppressions arrive with reasons a reviewer can accept at a glance. - Clusters are spotted within weeks, not discovered in a yearly cleanup. - The system team's backlog contains requests that trace back to suppressions. - Product teams stop seeing the rule as an obstacle, because the exit is quick when it is justified.
- Why route new suppressions to the system team rather than letting each product team approve its own?Product reviewers see one change; the system team sees the pattern. Ten teams each suppressing the same rule for the same missing token looks like ten reasonable exceptions locally and like one gap centrally. Routing makes that visible early, and a quick review keeps it from becoming a bottleneck.
- What does a ratchet do that a periodic cleanup does not?A cleanup lowers the count once; a ratchet keeps it from rising again. CI records the current count per rule and fails any change that adds to it without approval, so progress cannot quietly erode between cleanups and every new exception becomes a conscious decision.
saying these in an interview costs you the question
- Suppressions are lint noise, so the count does not matter.
- The fastest fix is deleting all suppressions and failing the build.
- Grouping suppressions by file is enough to decide what to do.
- Product teams should approve their own design-system suppressions alone.
- A cleanup sprint solves it; no ongoing check is needed.