A mock interview that actually prepares you.

Structured concurrency means a parent scope outlives all its children, and cancellation propagates both up and down. coroutineScope cancels all children if any one fails. supervisorScope isolates failures — one child failing doesn't cancel its siblings. You'd use supervisorScope when children are independent (e.g. loading multiple feed sections in parallel where one failing shouldn't kill the others).

StateFlow holds a single value, always has a current state, and replays it to new collectors — great for UI state. SharedFlow is a hot stream with configurable replay and buffer — good for one-shot events. Channel is a rendezvous point — designed for producer/consumer with backpressure. Common mistake: using SharedFlow for navigation events without handling configuration changes properly.

In launch, uncaught exceptions propagate to the parent immediately and crash the scope unless a CoroutineExceptionHandler is installed. In async, the exception is held until .await() is called — so you must wrap await() in try/catch or the exception is swallowed. Strong answers mention that CoroutineExceptionHandler doesn't help in supervisorScope children by default.

The ViewModel survives rotation, so viewModelScope coroutines continue running — the network call is not restarted. The new Activity/Fragment resubscribes to the StateFlow/LiveData and gets the current state. The job is only cancelled when onCleared() fires (user navigates away). This is one of the core reasons ViewModels exist.

Recomposition is triggered when a State object read during composition changes. Compose skips recomposing a composable if all its inputs are equal (stability). To prevent unnecessary recompositions: mark data classes @Stable or @Immutable when safe, hoist state correctly, use remember to cache derived values, avoid reading unstable types inside composables, and use derivedStateOf when a computation depends on multiple states.

Composition: builds the UI tree and observes state. Layout: measures and places nodes. Drawing: renders to canvas. Phases are incremental — Compose can skip earlier phases if only later ones are affected. For example, an animation that only changes a translation can skip composition and layout entirely (using Modifier.graphicsLayer) and run only the draw phase, keeping it on the render thread at 60fps.

LaunchedEffect runs a suspend block tied to a key — relaunches when the key changes, cancels when leaving composition. SideEffect runs after every successful recomposition — used to sync Compose state to non-Compose code (analytics, etc). DisposableEffect is for non-coroutine side effects that need cleanup (listeners, observers) — its onDispose runs when the composable leaves composition.

Three concentric layers: Data (repositories, data sources, DTOs), Domain (use cases, entities, repository interfaces), Presentation (ViewModel, UI state, composables). The dependency rule: inner layers never reference outer ones. Domain has zero Android imports. Use cases are plain Kotlin classes the ViewModel calls. Data layer implements domain interfaces. Common mistake: putting business logic in the ViewModel or referencing Android SDK classes in domain.

The classic problem: StateFlow replays its last value, so a "navigate to Detail" event re-fires on rotation. Options: SharedFlow with replay=0 (events lost if no collector), Channel (buffered, consumed once), or the "consumed event wrapper" pattern (Event<T>). Google's current recommendation is SharedFlow combined with collecting only when the UI is in STARTED state using repeatOnLifecycle.

Repository abstracts data access behind a single interface, letting the ViewModel remain agnostic about whether data comes from network, cache, or DB. Even with one source today, the pattern pays off immediately in testing — you can inject a fake repository without touching Room or Retrofit. It also makes adding a cache layer trivial later: the ViewModel never changes, only the repository implementation does.

Key components: Request queue (manages concurrent loads), Memory cache (LRU, bitmap pool to avoid GC pressure), Disk cache (bounded, LRU eviction), Decoder pipeline (BitmapFactory with inSampleSize for downsampling, hardware bitmaps for Compose), Network fetcher (OkHttp, HTTP cache headers), Lifecycle-aware request cancellation (cancels on Fragment/View detach), Placeholder/error state management. Strong answers address bitmap size estimation and why you must downsample before decoding.

Transport layer: WebSocket for real-time (long-lived), with SSE or HTTP polling as fallback. Local DB: Room stores all messages with a status column (sending / sent / delivered / read). Offline: write to Room first, enqueue with WorkManager (guaranteed delivery). Message ordering: server-assigned monotonic sequence ID, client uses local timestamp only for optimistic display. Conflicts resolved by server sequence on sync. Strong answers cover idempotency keys to prevent duplicate sends.

Core design: gateway-agnostic API contract (your SDK exposes PaymentProvider interface), pluggable adapters per gateway (Razorpay, Stripe, UPI), and a state machine for payment lifecycle (IDLE → INITIATING → PENDING → SUCCESS/FAILED/CANCELLED). Retry logic with idempotency keys so a network failure doesn't double-charge. Expose a result as a sealed class. Surface a PaymentResult callback and a webhook reconciliation path. Strong answers mention 3DS redirect handling and deep-link return flow.