MVI Pattern Interview Questions
ARCHITECTURE › Patterns
Walk me through the full loop, from a button tap to a re-rendered screen, in an MVI-based screen.
What a strong answer covers: The View dispatches a single Intent object through one entry point, typically a processIntent function on the ViewModel; that intent is either reduced synchronously against the current State to produce a new State, or if it requires async work, it triggers a side effect that eventually produces a Result, which is then fed back through the reducer alongside the current State to produce the next State. The nuance: there's exactly one path from intent to state change, funneled through the same reducer, so a weak answer describing the ViewModel mutating state directly from a callback, bypassing the intent and reducer pipeline, has actually built MVVM with extra ceremony, not MVI.
What's the honest cost of MVI on a real team, and what convinces you it's worth paying versus staying with plain MVVM or UDF?
What a strong answer covers: The cost is real boilerplate: an Intent sealed class, a Result or partial-state type, and a reducer function for every screen, even trivial ones, plus a steeper onboarding curve for engineers used to calling a ViewModel function straight from the UI. It earns its keep on screens with genuinely complex, interleaved state, multiple async sources updating overlapping fields, where the reducer's purity and the ability to log and replay every intent-to-state transition materially speeds up debugging. A weak answer applies MVI uniformly across an app regardless of screen complexity, exactly the needless-ceremony trap interviewers are probing for.
A reducer needs to trigger an async operation as a result of an intent, like loading more data. Walk me through how you keep the reducer pure and testable while still making that side effect happen.
What a strong answer covers: The reducer itself stays a pure (State, Intent) to State function that never launches coroutines; an intent like LoadMore is handled by a separate effect handler, often in the ViewModel's intent-processing coroutine, that performs the actual suspend call and then feeds the outcome back in as a Result-type intent, such as DataLoaded(items) or LoadFailed(error), which the pure reducer consumes like any other intent. The nuance a weak answer misses: the reducer never knows a network call happened, it only ever sees State plus a plain data Result, which is exactly what makes reducers trivially unit-testable without mocking coroutines, and what makes replay-based debugging valid, since replaying intents reproduces the same states.