When orthogonal concerns cause state explosion, the state count grows as the product of independent conditions rather than their sum. For example, if a device has 4 operating modes and each must also track 3 connection states and 2 error conditions, a flat machine needs up to 4×3×2 = 24 states, most of them near-duplicates differing in one dimension, which is unmaintainable and bug-prone. The fixes: hierarchical (nested) state machines (statecharts), where a superstate captures behavior common to its substates so you don't replicate transitions, e.g. a "Connected" superstate containing the operating-mode substates, with a single "disconnect" transition out of the whole group; or orthogonal/concurrent regions, modeling the independent dimensions as separate cooperating machines (one for mode, one for connection, one for faults) that communicate via events. This collapses the multiplicative blowup back toward additive. Frameworks like UML statecharts or QP/QF formalize this. The trigger to refactor is when you notice the same transition copy-pasted across many states, or states named like MODE_A_CONNECTED_ERROR.
Data Structures & Algorithms · Interview question
When does a flat FSM become the wrong structure, and what do you do?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Finite State Machines
One state at a time, transitions on events: the structure behind protocol parsers, button debouncers, and comms stacks, implemented as a switch or a transition table.