Data Structures & Algorithms · Interview question

What are the most common FSM bugs?

A strong answer

Top of the list: unhandled (state, event) combinations, a real input arrives in a state you didn't write a case for, and the machine either ignores it silently or falls through to wrong behavior; the fix is a default case or filling every table cell, even if the action is "ignore" or "go to error." Second: no error-recovery/resync path, real streams are noisy, so a parser that doesn't reset to a known state on a bad checksum or unexpected byte can wedge forever mid-frame; you need an explicit path back to the initial/idle state. Third: uninitialized starting state, if the state variable starts as garbage the machine behaves randomly, so it must be initialized to a defined initial state. Fourth: state explosion, bolting orthogonal conditions onto a flat machine multiplies states until it's unmaintainable, which signals you should refactor into hierarchical or cooperating machines. And for Mealy-style actions, double-firing or skipping transition actions if the action isn't run exactly once per transition. The unifying theme is totality: every state must define behavior for every possible event, including the unexpected ones.

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.

More Finite State Machines questions

Browse all 472 interview questions
What are the most common FSM bugs? | EmbeddedPrep.io