AndroidHire

Android Architecture Interview Questions

MVVM, Clean Architecture, and data flow.

50 questions in this topic · 8 sample questions below

Practice Architecture in the quiz engine

Sample questions

  1. In a strict MVI architecture, what is the defining constraint that most distinguishes it from MVVM?

    • The UI renders from a single immutable state object, and all changes flow through a reducer transforming old state into new state — correct
    • It requires the Redux library and a global application store
    • The View directly mutates the model without any intermediary
    • Business logic must live inside the Composable functions

    Why: MVI centers on a single immutable state produced by reducing intents into new state, giving unidirectional flow. MVI is a pattern, not a library, so it never requires Redux or a global store.

  2. Why is exposing a public MutableStateFlow from a ViewModel considered an antipattern?

    • MutableStateFlow cannot be collected from Compose
    • It allows the UI layer to mutate state directly, breaking the single source of truth and unidirectional data flow — correct
    • MutableStateFlow is not lifecycle-aware and will crash
    • It forces the ViewModel to hold a Context reference

    Why: Publicly mutable state lets Views write to it, violating unidirectional flow and the single source of truth. MutableStateFlow is perfectly collectable from Compose; the problem is write access, not readability.

  3. A screen must show a one-time snackbar when saving fails. Which approach most reliably delivers exactly-once without loss on configuration change?

    • A SharedFlow with replay set to 1 so late collectors still receive it
    • A plain StateFlow holding the error message string
    • A Channel exposed via receiveAsFlow, or an event modeled as consumable state the UI marks as handled — correct
    • A LiveData with postValue called from the ViewModel

    Why: A Channel with receiveAsFlow buffers until collected and delivers once; alternatively events can be state the UI explicitly consumes. A replay=1 SharedFlow re-emits stale events to new collectors, causing duplicate snackbars after recreation.

  4. Which statement about SharedFlow with replay set to 0 for one-off events is correct?

    • It reliably guarantees a recreated screen receives events emitted while no collector was active
    • It buffers events indefinitely until the next collector subscribes
    • It behaves identically to a Channel with unlimited buffer
    • Events emitted while there is no active collector are dropped, so config change can lose them — correct

    Why: SharedFlow with replay=0 and no extra buffer drops emissions when no collector is subscribed, so events during recreation can be lost. That is exactly why it is unreliable for one-off events compared to a Channel.

  5. What is the purpose of the private MutableStateFlow plus public asStateFlow() idiom in a ViewModel?

    • To make the flow lifecycle-aware automatically
    • To enable replay of the last ten emissions
    • To convert the flow into LiveData
    • To expose a read-only StateFlow externally while keeping mutation internal — correct

    Why: asStateFlow returns a read-only view so only the ViewModel can update the value, preserving unidirectional flow. It does not add lifecycle awareness or replay buffering.

  6. SavedStateHandle in a ViewModel primarily protects against which scenario?

    • Configuration changes like rotation
    • Memory leaks from Context references
    • Process death, restoring a small amount of state after the OS reclaims the app — correct
    • Cold start after the user force-stops the app

    Why: A plain ViewModel already survives configuration changes; SavedStateHandle adds survival across system-initiated process death via the saved state bundle. It does nothing after an explicit force-stop, which clears saved state.

  7. Why should collectAsStateWithLifecycle be preferred over collectAsState in Compose for UI state?

    • It renders faster by skipping recomposition
    • It stops collecting when the lifecycle drops below STARTED, avoiding wasted work and updates while backgrounded — correct
    • It automatically retries on collection errors
    • It is required for StateFlow but optional for other flows

    Why: collectAsStateWithLifecycle suspends collection when the UI is not at least STARTED, saving work and preventing background updates. Plain collectAsState keeps collecting even when the screen is not visible.

  8. In stateIn with SharingStarted.WhileSubscribed(5000), what does the 5000 millisecond timeout accomplish?

    • It keeps the upstream flow active for 5 seconds after the last subscriber leaves, surviving brief config changes without restarting collection — correct
    • It delays the first emission by 5 seconds
    • It caps the flow to emit at most once every 5 seconds
    • It retries the upstream flow every 5 seconds on failure

    Why: The timeout keeps the shared upstream alive briefly after the last collector unsubscribes, so a rotation does not tear down and restart the underlying work. It is not a debounce, delay, or retry interval.

Practice all 50 Architecture questions

These 8 are a sample. The full Architecture bank is scored, tracks your progress, and explains every answer.

Open the quiz

More Android interview topics