Jetpack Compose Interview Questions — Practice Quiz

The Compose compiler infers stability for a type when all of its public properties are val and their types are themselves stable. Primitives (Int, Boolean, etc.) and String are stable by definition, so a data class composed entirely of val stable-typed properties is stable. This stability lets the compiler generate skippable composables, meaning a composable whose stable arguments are unchanged can be skipped during recomposition.

Recomposition is the mechanism that makes Compose declarative and reactive at the same time: you describe what the UI should look like given the current state, and Compose figures out which parts need to be re-invoked when that state changes, rather than the developer manually mutating Views. Understanding that it's targeted (only readers of changed state) and skippable (when inputs are stable and unchanged) rather than a full-tree re-render is the foundation for every Compose performance question that follows — stability, state hoisting granularity, and why unnecessary object allocation inside a composable is expensive.

Modifier order is left-to-right, with the leftmost modifier wrapping the outermost layer. This is a fundamental Compose concept: reversing the order of modifiers like padding and background produces visibly different results because each modifier wraps the result of everything to its right.

Modifier is the companion object's empty implementation; it passes through all measurements and drawing untouched. It serves as the neutral identity element for modifier composition.

Without a key, Compose stores remembered state by slot position. On the first pass, position 0 stores "Alice", position 1 stores "Bob", and position 2 stores "Carol". After reordering to [Bob, Alice, Carol], each position still holds its original value: slot 0 has "Alice" (now expecting "Bob"), slot 1 has "Bob" (now expecting "Alice"), and slot 2 has "Carol" (still "Carol"). This is exactly why providing a stable key to items() is recommended — it lets state follow the item instead of the position.

LazyColumn is called "lazy" because it only instantiates composables for items in or near the viewport. With 6 visible items and 3 prefetched beyond the bounds, only 9 composables are created out of 5,000. The remaining 5,000 − 9 = 4,991 items are never composed until the user scrolls to them. This is the core performance advantage of lazy lists over eager layouts like Column with forEach.

AndroidView is the Compose interop API that lets you bring a classic android.view.View into a composition. You supply a factory lambda that creates the View and an update lambda that configures it on recomposition. It lives in androidx.compose.ui.viewinterop (re-exported from androidx.compose.ui.platform).

ComposeView is the bridge widget that lets you host Compose content inside an existing ViewGroup. It is an AbstractComposeView subclass; you add it to an XML layout (or create it programmatically) and call setContent { @Composable () -> Unit } to provide the composable tree.

Compose's whole performance model depends on being free to treat composable functions like a description of UI rather than a sequence of imperative steps: recomposition can re-invoke a composable, smart recomposition can skip invoking it at all when its parameters haven't changed, and independent composables can in principle be composed out of order or concurrently. If a composable directly performs a side effect — incrementing a counter, writing to a file, making a network call — none of those guarantees hold anymore: skipping the call skips the side effect unexpectedly, and a re-invocation duplicates it. This is exactly why Compose has a dedicated, opt-in surface for side effects (LaunchedEffect, SideEffect, DisposableEffect) instead of letting composables perform them inline — those APIs give the runtime an explicit place to control when the effect actually runs. Kotlin's compiler does not forbid a composable from touching a var (b is false), returning Unit has no bearing on this at all (c), and visibility modifiers are unrelated to the Compose runtime's execution guarantees (d).

State hoisting is the core pattern Compose uses to keep composables stateless, reusable, and testable: instead of a composable owning mutableStateOf internally (which makes it a one-off, hard-to-reuse, hard-to-test unit tied to its own state), it accepts the current value and an onValueChange (or similarly-named) lambda as parameters, and the caller decides where that state actually lives — in a remember block one level up, in a ViewModel, wherever's appropriate. This is exactly analogous to a 'controlled component' pattern in other declarative UI frameworks, and it's why Compose's own built-ins like TextField take value/onValueChange rather than managing their own text internally. It is a manual authoring pattern the engineer applies, not something the compiler does automatically (b), has nothing to do with centralizing state in Application (c), and it's an active, current pattern rather than something rememberSaveable replaced — rememberSaveable solves a different problem (surviving process death), and hoisted state can itself be backed by rememberSaveable (d is false).

Each element in a Modifier chain wraps the next one, and they're applied in the order they're written, left to right — each one affects the size/position/drawing available to whatever comes after it in the chain. Modifier.padding(16.dp).background(Color.Red) first shrinks the available layout space by the padding, and only then draws the background within that already-shrunk area, so you get red with no margin around it (the padding is 'outside' the red, i.e. background-colored the same as whatever's behind the Box). Modifier.background(Color.Red).padding(16.dp) draws the background across the full, unshrunk size first, and only then insets the content by the padding — so the red extends into what looks like a visible red margin around the content. This is one of the most commonly misunderstood parts of Compose for engineers coming from a View/XML background, where attribute order in a layout doesn't carry this kind of meaning, and it's a frequent live-coding interview probe for exactly that reason.

remember caches a value across recompositions of the same composition — the whole reason it exists is so a composable doesn't recreate expensive or stateful objects on every recomposition pass (a) — but a composition itself doesn't survive a configuration change or process death, so a plain remembered value is lost in both of those cases. rememberSaveable closes that gap specifically by writing into the platform's existing saved-instance-state Bundle, which the OS persists across both configuration changes and process death, restoring it on the next launch (b); because that mechanism is Bundle-based, only types Bundle can natively store (or a type with a registered Saver telling Compose how to serialize/deserialize it) can be stored this way (c). Neither survives an app being fully closed and relaunched days later with no process retained by the system at all — the saved-instance-state Bundle mechanism is for restoring the most recent session's state, not permanent storage, so (d) is false. And (e) misdescribes exactly the problem remember solves: unlike a plain local val, which genuinely is recreated on every recomposition, remember is specifically what prevents that recreation.

LaunchedEffect exists to bridge composition with coroutines: it launches its block in a CoroutineScope tied to the composable's presence in the composition, and that scope is cancelled automatically when the composable is removed from composition (a) — that's what makes it safe to launch, say, a network request or an animation without manually managing cancellation. It re-keys on its parameters: whenever a key changes between recompositions, Compose cancels the in-flight coroutine and starts a fresh one with the new key values (b), which is exactly why LaunchedEffect(Unit) — a key that is, by construction, always the same, unchanging value — only ever launches once, on first entering composition, and never restarts on later recompositions (c). It is explicitly not tied to every recomposition the way (d) claims; that's the entire point of keying it, since re-running a side effect on every single recomposition (which can happen many times) would be exactly the runaway behavior LaunchedEffect's key mechanism is designed to prevent. And (e) is simply false — LaunchedEffect is a standard composable function called directly in a composable's body, most commonly gated behind some condition, with no requirement to be nested inside another one.

False — it's the other way around. factory runs exactly once, the first time AndroidView enters composition, and its only job is to construct and return the legacy View instance; Compose then holds onto that same View instance across recompositions instead of recreating it. update is the lambda that runs on every recomposition where AndroidView's inputs are read, and its job is exactly to push any changed Compose state onto the already-created View (e.g. textView.text = someComposeState.value) so the wrapped View stays in sync with whatever state changed. Mixing these two up is a common source of interop bugs: putting sync logic in factory means the View is only ever configured once and silently goes stale on later state changes, while doing expensive construction work in update means it needlessly re-runs on every recomposition.

Nothing can launch before the composable exists in composition, so entering composition comes first, immediately followed by the first launch with whatever userId was passed in initially. LaunchedEffect only reacts to its key changing on a later recomposition — it doesn't restart when unrelated state changes — so the key change has to happen before anything is cancelled or relaunched. When Compose sees the key genuinely changed, it must cancel the previous coroutine before starting the new one, both to avoid two concurrent loadProfile calls racing each other and because that's literally what re-keying means: the old effect is no longer valid for the new key. The final cancellation on leaving composition is a separate, later event triggered by composable removal rather than a key change, so it comes last and applies to whichever coroutine happens to be running at that point.

Option (a) is true — composable functions routinely take @Composable () -> Unit lambda parameters (e.g., Column's content slot). Option (d) is true — the compiler transforms the function type so that @Composable () -> Unit is a distinct type from () -> Unit; they are not interchangeable. Option (b) is false — composable functions can return any type; remember is a canonical example of a @Composable function that returns a value. Option (c) is false — calling a @Composable function requires a Composer instance that the compiler injects, so it can only be invoked inside a composable context (such as setContent or another @Composable function).

True. A plain computation re-run directly inside a composable's body reads its inputs as State, so the composable recomposes every time any of those inputs change, even if the value it actually cares about — the result of the computation — didn't change. A classic example is a scroll-derived boolean like listState.firstVisibleItemIndex > 0: the scroll offset changes on every pixel of scroll, but the boolean only flips twice, once crossing 0. derivedStateOf recomputes its lambda whenever an input State it reads changes, but it only reports a new State value — and therefore only triggers recomposition in whatever reads it — when that recomputed result is actually different from the last one. This makes it purely a performance tool for the case where read-frequency of the inputs and the result differ, not a general substitute for remember; using it when the result changes just as often as the input adds overhead for no benefit.

items(tasks) { ... } without a key parameter identifies each composed row by its index in the list, not by which task it actually represents. Each row's remembered state (expanded here) is stored keyed to that slot, not to the task. When a task is deleted from the middle of the list, everything after it shifts up by one position — but the positions' remembered state doesn't shift with the data; instead, whatever expanded value was remembered at position N stays at position N and is now attached to a different task's row, which is exactly the 'wrong item's state shows up on a different row' symptom described. The fix is items(tasks, key = { it.id }) { task -> ... }: giving Compose a stable identity lets it match remembered state to the same underlying task across insertions, deletions, and reorders, discarding state cleanly (rather than misattributing it) when a task is actually removed. Removing remember entirely (b) would just make the state reset on every recomposition instead of persisting correctly for the right row, which fixes the symptom by breaking the underlying feature; the toggle lambda on line 7 is a correct, idiomatic read-and-flip of the captured mutableStateOf (c is a non-issue); and index-based keying by default is real, but it is exactly the behavior causing this bug, not an unrelated 'no bug' situation (d).

Every keystroke changes searchText, which recomposes ScreenContent — that part is expected and correct. The bug is what that recomposition does to ExpensiveRow's inputs: the trailing lambda on line 7 closes over searchText, so Kotlin has to allocate a new lambda instance capturing the new searchText value on every recomposition of ScreenContent, even though item itself hasn't changed. Compose's smart recomposition decides whether to skip re-invoking ExpensiveRow by checking whether all of its parameters are stable and equal to their previous values by instance/structural equality — and a freshly-allocated lambda instance is, from that check's point of view, a changed parameter, so ExpensiveRow is forced to recompose even though the only thing that actually changed lives outside of it entirely. The general fix is to avoid capturing frequently-changing values in a lambda passed down into a component that shouldn't care about them — e.g. hoist the click handling so ExpensiveRow receives a stable callback reference, or pass item.id and searchText separately so the composable can be restructured to not force the row to recompose. item itself being a data class is not inherently a problem (b) — a @Immutable/stable data class of stable-typed vals composes just fine — Compose does not process composables in linear declaration order for recomposition purposes (c), and siblings inside the same parent do not all recompose together automatically; each is independently skippable based on its own parameters (d is false).

The dividing line is whether the effect is itself a coroutine: LaunchedEffect exists to launch and manage the lifecycle of a suspend-based effect, and cancellation of that coroutine is Compose's natural cleanup mechanism for it. DisposableEffect is for effects that register something outside the coroutine world entirely — a listener, an observer, a callback — where 'cleanup' means explicitly unregistering it, not cancelling a coroutine. Because a registered listener that's never removed is a classic leak (it keeps a reference alive and keeps firing into code that's no longer meant to be running), Compose forces every DisposableEffect to supply an onDispose block as the final statement of its lambda — it's a compile-time requirement precisely so this cleanup step can't be silently omitted.

In a Compose modifier chain, modifiers are applied left-to-right, and each modifier wraps all subsequent ones. The first modifier (fillMaxSize, id b) is the outermost layer, directly receiving the parent's incoming constraints. The second (aspectRatio, id d) wraps everything after it. The third (clip, id a) wraps the fourth and the content. The last (padding, id c) is the innermost, sitting closest to the composable's content. The outermost-to-innermost order is therefore: fillMaxSize → aspectRatio → clip → padding (b, d, a, c).

During the layout phase, constraints propagate from the outermost (first) modifier inward. fillMaxWidth() (id c) first receives the parent's constraints and constrains the width to the maximum available. These reduced-width constraints flow to padding(16.dp) (id a), which subtracts 32 dp from both dimensions. The further-reduced constraints reach wrapContentSize (id d), which measures the child unbounded to find its natural size and centers it. Finally, the Text("Hi") content (id b) is measured within wrapContentSize. The order is therefore: fillMaxWidth → padding → wrapContentSize → Text (c, a, d, b).

The factory lambda of AndroidView runs exactly once—during the initial composition—to create the view instance. Setting text = status there captures only the first value of status. The update lambda runs on the first composition and every subsequent recomposition, so any state-dependent property must be set there. Because update omits view.text = status, a changed status never reaches the TextView. Lines 7 and 12 correctly set a constant textSize in both blocks, and setPadding in update does not interfere with parent-imposed padding. The fix is to remove text = status from the factory and add view.text = status inside update.

This is deliberately a staff-level question because it asks for the mechanism, not just the symptom: the compiler statically classifies parameter types as stable/unstable based on whether it can prove equal instances stay content-equal, and at runtime the skip decision is purely an equality check on stable parameters against their previous values. The two most common real-world defeats — collection interfaces with no immutability guarantee, and freshly-allocated lambdas capturing changing values — are exactly the kind of thing a strong senior/staff Compose engineer should be able to name unprompted when debugging a recomposition-count regression, because both are invisible in the code's apparent correctness (the app still works) and only show up as a performance regression under profiling.

Positional memoization is Compose's core mechanism for associating remember storage with call-site identity rather than variable names. The slot table is a linear array indexed by call position; conditional branches add and remove groups, which can misalign slots when control flow changes. key() creates an explicitly identified group that the slot table can track across structural changes, preserving memoized state.