In an ordered chain of conditional arms guarding a permission decision, what makes a later arm unreachable?
answer
- the first matching arm wins
- earlier conditions are implicitly negated
- one condition may imply another
- widest test placed first swallows the rest
- name an input that reaches the arm
basics
~20 sAn arm is unreachable when every input satisfying its condition already satisfied an earlier condition in the chain, or when its own condition is self-contradictory and no input satisfies it at all. First-match selection then guarantees it never runs.
solid answer
~50 sAn ordered chain takes the **first** arm whose condition holds, so a later arm only runs for inputs that all the earlier conditions rejected. It is therefore dead in two distinct ways. Either its condition is **implied** by one of the earlier ones — a chain that tests `score > 0` and then `score > 50` can never reach the second, because every score above fifty is already above zero — or its condition is **contradictory** in itself, such as requiring a value to be both above fifty and below ten, in which case no input satisfies it regardless of position. The usual cause of the first kind is ordering the tests from widest to narrowest instead of most specific first. Diagnosis is a reading exercise: for each arm, ask whether any input can reach it, and if you cannot name one, the arm is dead.
code
pseudocode · 11 linesfunction classify(request)
if request.score > 0 then
return ALLOW_WITH_REVIEW
else if request.score > 50 then # never reached
return ESCALATE
else
return ALLOW
# score = 60 -> 60 > 0 holds, so the first arm fires and returns
# ALLOW_WITH_REVIEW; the escalate arm's effective guard is
# (score <= 0 and score > 50), which no score satisfiesgo deeper
Know that a chain takes the first arm whose condition is true, so arms below it are skipped even if their conditions would also hold.
Derive an arm's effective guard by conjoining the negated earlier conditions, and separate the two causes of death: implication by an earlier arm, and self-contradiction.
Frame it as a policy hole rather than dead code — the decision the arm existed to make is never taken — and describe the per-arm test that catches it at the change.
Decide how such chains are kept honest at scale: where policy may live in ordered conditions at all, and when it belongs in an explicit table of bands instead.
## What "unreachable" means in an ordered chain An ordered chain of conditions is not a set of independent tests. It is a sequence with an implicit accumulation: arm *k* runs for inputs that satisfy condition *k* **and fail every condition before it**. The effective guard on the third arm of a chain is not `C3` but `not C1 and not C2 and C3`. An arm is **unreachable** when that effective guard is unsatisfiable — no input at all can produce it. Everything about diagnosing dead arms follows from writing that conjunction out. ## Two ways an arm dies 1. **Implied by an earlier condition.** If `C3` implies `C1` — every input satisfying `C3` also satisfies `C1` — then `not C1 and C3` is empty and the arm is dead. This is the common case, and it is produced by ordering tests from **widest to narrowest**. A chain that asks "is the risk score above zero?" before "is it above fifty?" has already swallowed every high-risk request into the first arm. 2. **Contradictory in itself.** The condition cannot be satisfied by any input independently of position: a value required to be both greater than fifty and less than ten, a flag required to be both set and clear, a state required to be two mutually exclusive members of a closed set at once. Reordering does not save this arm; only fixing the condition does. A third case is worth separating because it looks identical from the outside: an arm that *is* reachable in principle but never reached by real traffic. That is not an unreachable arm, it is an **untaken** one, and the fix — if any — is a data question, not a control-flow question. ## Working the example A permission chain tests risk in this order: | Arm | Condition | Effective guard | Reachable? | |---|---|---|---| | 1 | `score > 0` | `score > 0` | yes, for any positive score | | 2 | `score > 50` | `score <= 0 and score > 50` | no — unsatisfiable | | 3 | else | `score <= 0` | yes, for zero and below | Arm 2 is dead, and the damage is not that it wastes a line: the decision it was written to make — escalate a high-risk request — is never taken, and every high-risk request gets arm 1's answer. The bug reads as a policy failure, not as a control-flow failure, which is why it survives review. ## Overlap is what makes order matter The deep property is whether the conditions **overlap**. - **Mutually exclusive conditions** — no input satisfies two of them — make the chain order-independent. You may reorder the arms freely; the same input takes the same arm. Branching on distinct members of a closed set of outcomes is the everyday example. - **Overlapping conditions** make the chain order-dependent, and then the order *is* the policy. The rule for writing them is **most specific first**: put the narrower condition above the wider one it implies, so the narrow case gets its own arm before the wide one absorbs it. That single rule prevents most implied-arm deaths, and it also explains why a catch-all belongs last: it is the widest condition there is. ## Diagnosing and preventing dead arms 1. **Name a reaching input.** For each arm, state one concrete input that reaches it. If you cannot produce one, the arm is dead — this is faster and more reliable than staring at the conditions. 2. **Write out the effective guard.** Conjoin the negations of the earlier conditions and simplify. Dead arms collapse to an obvious contradiction once written this way. 3. **Look for widening as you read down.** A chain whose conditions get *looser* going downward is fine; a chain where a lower condition is stricter than one above it is the shape that produces implied arms. 4. **Let the tooling help where it exists.** Some analysers report a condition subsumed by an earlier one or a contradictory comparison; treat such a warning as a policy bug rather than a style nit. 5. **Cover each arm with a test.** One case per arm, asserting the decision, turns an unreachable arm into a failing test on the day it is introduced instead of a silent policy hole. ## What an interviewer is checking Not whether you can spot one dead arm — that is a puzzle. They want to hear the reasoning: first-match semantics, the effective guard as a conjunction, implication versus contradiction as two separate causes, and "most specific first" as the rule that keeps overlapping conditions honest.
- How do you rewrite that chain so the escalate decision is actually taken?Order the overlapping conditions most specific first: test `score > 50` above `score > 0`. Each arm's effective guard then names a real band — above fifty, between one and fifty, zero and below — and every band has an input that reaches it.
- When can you reorder the arms of a chain without changing behaviour?When the conditions are mutually exclusive, so no input satisfies two of them. Then each input matches at most one arm and first-match has nothing to choose between. As soon as two conditions overlap, the order is part of the policy and moving an arm changes decisions.
- Is an arm that no production input has ever taken an unreachable arm?No — that is an untaken arm. Its effective guard is satisfiable, so some input would reach it; the traffic simply has not produced one. Unreachability is a property of the conditions alone and can be established by reading them, while untaken-ness is a fact about the data.
saying these in an interview costs you the question
- Reads each condition alone, ignoring the earlier ones negated
- Thinks arm order never matters in a conditional chain
- Calls an arm no traffic reaches an unreachable arm
- Puts the widest condition first and the narrow one after
- Believes a contradictory condition is fixed by reordering