Question 1

You are starting a new project. Which state management solution would you choose and why?

Accepted Answer

This question does not test a library name — it tests your reasoning. Start by asking: 1. Ask for context: team size, product lifetime, how much of the app is async, are there audit/logging requirements? 2. Name the criteria: built-in async state handling, ease of testing, traceability, boilerplate, the team's existing experience. 3. Decide and justify: "A four-person team on an API-heavy app → Riverpod: AsyncValue gives loading/error for free, override makes tests simple, autoDispose cleans memory on its own." 4. Say why you rejected the alternative: "I'd keep BLoC for flows that need an audit trail, like payments — every state change having an event gives you the log for free." 5. Name the risk: Riverpod's learning curve and codegen build times; I mitigate with lints and one reference feature. Citing the official position strengthens the argument: the Flutter team itself gives no single recommendation and ties the choice to context.

Question 2

Half the team wants BLoC, half wants Riverpod. How would you drive that decision?

Accepted Answer

This is a leadership question, not a technical one. Structure: 1. Turn the debate into criteria: both sides score their choice against the same list — testing, async, traceability, boilerplate, onboarding time, existing code. 2. Propose a measurable experiment: spike the same medium-sized feature both ways (two to three days), then compare lines of code, time to write tests and review comments. 3. Document the decision: an ADR — the choice, the reasons, the rejected alternative and the condition for revisiting. 4. Set the boundary: if mixed use is allowed, say which part uses which, enforced by a lint rule and a review checklist. 5. Keep an exit: the layer that separates state from UI (repository, use case) stays the same either way, which makes a future migration cheap. The closing line that matters: "To me, the choice itself matters less than the team applying it consistently."

Question 3

What is your take on libraries like GetX? Why don't you (or do you) pick them?

Accepted Answer

The trap here is trashing a library. Talk in technical criteria instead: Boundaries of responsibility: when state, navigation, DI and localisation all live in one package, replacing it means touching every layer. I prefer small tools that solve one problem. Testability: how easy is it to separate state from the UI and from global singletons? Static global entry points let state leak between tests. Fit with the framework: solutions that bypass BuildContext, such as context-free navigation, drift from Flutter's own model and add upgrade risk. Team and hiring: which skill is more available on the market, and how quickly a new developer becomes productive. Then show balance: on a small MVP that must ship fast, speed can outweigh those arguments. What matters is that the choice is deliberate and revisited as the project grows. That reads far more mature than "it's a bad library".

Criterion	Provider	Riverpod	BLoC / Cubit
Where providers live	In the widget tree (`MultiProvider`)	Outside the tree, as global `final` variables	In the tree (`BlocProvider`), backed by package:provider
Reading	By type: `context.watch<T>()`	By object: `ref.watch(myProvider)`	By type: `context.read<T>()`, `BlocBuilder<B, S>`
Reading a missing provider	A runtime error (not found in the tree)	Visible at compile time — a provider is a concrete object	A runtime error (`BlocProvider` not found)
Async state	Manual: `FutureProvider` or flags inside the model	Built-in `AsyncValue`: loading/error/data out of the box	Manual in the state model: a status enum or sealed classes
Traceability	Weak — you can't see who called `notifyListeners`	Possible via observers	Strong — every state change is triggered by an event
Boilerplate	The least	Medium (less with codegen)	The most (less with Cubit)

The landscape of approaches and how to choose

📚 Sources and documentation