Question 1

Which state management would you choose for a project, and why?

Accepted Answer

The question tests decision-making, not trivia. Structure: (1) ask first — project size, team experience, greenfield or existing code; (2) explain the split — setState for local state, a package only for shared state; (3) make a concrete choice with a reason: Provider on a small-to-mid project (low learning cost), Riverpod where the app is async-heavy (AsyncValue forces all three states), BLoC on enterprise work needing audit trails and complex flows. Close by showing you are not dogmatic: migrating a working codebase just because something is "more modern" does not pay for itself.

Question 2

Explain the difference between ephemeral and app state.

Accepted Answer

Ephemeral state lives inside one widget and nobody else needs it: form text, an expanded panel, the current tab, an animation phase. setState is right and sufficient. App state spans screens or must survive a screen closing: sign-in status, the cart, user settings, caches. The practical test question: "is this needed on another screen, or must it survive this screen closing?" — if the answer is no, no package is needed. Knowing the split matters in interviews because making everything global is the most common design mistake.

Question 3

How would you approach changing the state management of an existing project?

Accepted Answer

First I would check the reason: what is the actual problem — hard to test, too many rebuilds, or simply "it is old"? If it is the last one I would not recommend migrating: the cost of changing working code is real while the benefit is hypothetical. If there is a real problem: (1) no big rewrite — go incrementally, new screens on the new approach, existing ones untouched, since both can coexist; (2) migrate one screen first and get the team's reaction; (3) add tests to any area before moving it. The key message: a migration produces no product value, so it has to be justified by the size of the problem it solves.

Criterion	setState	Provider	Riverpod	BLoC
Learning cost	None	Low	Moderate	High
Boilerplate	None	Little	Little	A lot
Testability	Weak	Good	Very good	Very good
Compile-time safety	—	Weak	Strong	Moderate
Fits	One widget	Small to mid app	Mid to large	Large, team-built

Choosing: comparison and decision

📚 Sources and documentation