Question 1

Compare Provider, Riverpod and BLoC.

Accepted Answer

Split the comparison into dimensions rather than a list of virtues. Mechanism: all three sit on the same Flutter foundation. Provider wraps InheritedWidget; flutter_bloc implements BlocProvider with package:provider; Riverpod reaches the tree through ProviderScope. So performance differences don't come from the mechanism. Where providers live: in the tree (Provider, BLoC) versus outside it as global finals (Riverpod). That is where Riverpod's compile-time safety and its support for many providers of the same type come from. Async state: hand-written flags in Provider; AsyncValue built into Riverpod; a status enum or sealed classes in a BLoC state model. Testing: in Riverpod, replacing a dependency via overrides is one line; in BLoC, blocTest asserts state sequences declaratively (seed, expect, wait, verify); in Provider you rebuild the tree by hand. Traceability: BLoC's onTransition gives the state → event → state chain — the most ready-made form for audits. Concurrency: BLoC ships EventTransformer and bloc_concurrency (droppable, restartable); the others are hand-rolled. A closing line: "The choice follows the team's needs, not the mechanism — the share of async work, audit requirements, testing culture and learning cost."

Question 2

Tell me the weaknesses of the approach you chose.

Accepted Answer

This question tests self-criticism. "It has no weaknesses" is the worst answer. If you chose Riverpod: a new mental model (providers as global finals look like global state at first), codegen build time, memory and caching mistakes if you don't know the autoDispose/family rules, and the extra work of major upgrades (2 → 3). If you chose BLoC: boilerplate (events, states and handlers in separate files), too much structure for simple screens, brittleness in tests coupled to state sequences, and "the event names are a mess" when the team lacks discipline. If you chose Provider: hand-written async state, runtime errors (ProviderNotFoundException), ChangeNotifier's mutable design making it easy to break select optimisations, and dependence on BuildContext (dialogs, routes). After each weakness, say how you mitigate it: lint rules, a reference feature, a review checklist, test coverage. That turns the answer from a complaint into an engineering position.

Question 3

The interviewer says: "Everything here is written with GetX." How would you respond?

Accepted Answer

This is both a technical and a cultural question — they want to see how you join a team. The structure: 1. Show curiosity, not criticism: "Which parts use it — state, navigation, DI, all of them? What problems does the team hit?" 2. Signal willingness to learn: being productive in the existing approach is the first duty; no team expects a new hire to arrive and change everything. 3. State your principles as criteria: what matters to me is not the library name but separating state from the UI and testability. Both are achievable with any approach — and that could be my first contribution. 4. Offer concrete value: keeping the repository/service layer independent of state management, writing tests for critical flows, isolating global static access in tests. 5. Leave the door open: if the team ever considers a change, I'd propose deciding with measurable criteria and a pilot feature. That answer is far stronger than "GetX is bad": it combines respect for the existing code, a technical principle and a concrete contribution.

Question	Provider	Riverpod 3	BLoC / Cubit
Learning curve	Low	Medium (a new mental model)	Medium-high (event/state discipline)
Async state	Hand-written flags	`AsyncValue` built in	A status enum or sealed states
Reading a wrong provider	A runtime error	Visible at compile time	A runtime error
Testing: replacing a dependency	Rebuilding the tree by hand	`overrides` — one line	`bloc_test`, `MockBloc`, `whenListen`
Testing the state sequence	A hand-written listener	`container.listen`	`blocTest(expect: ...)` — the most ready-made
Audit / event log	Hand-rolled	Observers	`BlocObserver` plus `onTransition`
Debounce / concurrency control	Hand-rolled	Hand-rolled (or indirectly via `select`/`autoDispose`)	`EventTransformer` plus `bloc_concurrency`
The official DI recommendation	Chosen by the official case study	The provider graph doubles as DI	`RepositoryProvider` (provider inside)

Comparison and justifying the choice

📚 Sources and documentation