Compose Layout, Lists & Modifiers Interview Questions
UI › Compose UI
Explain modifier order to me like I'm a mid-level engineer who keeps getting surprised by it. Why does Compose care about order when a typical Android View builder pattern doesn't?
What a strong answer covers: Each Modifier wraps the next like a decorator, applying its effect around whatever comes after it in the chain, so order changes both what area an effect covers and what constraints flow to children; background before padding paints behind the padded area while background after padding excludes it, and the same logic applies to clickable, clip, and size modifiers. This is fundamentally different from XML View attributes, which are just properties on one object with no ordering, because a Modifier chain is actually a sequence of composed layout and draw nodes.
You're choosing between LazyColumn and a plain Column with verticalScroll for a list. Walk me through the actual decision criteria beyond 'lazy is always better.'
What a strong answer covers: LazyColumn only composes and measures items near the viewport, which matters for large or unbounded lists, but for short fixed lists like a handful of settings rows, a plain scrollable Column is simpler, has less bookkeeping overhead from lazy layout, item keys, and item-scope machinery, and avoids bugs like nesting a LazyColumn inside another scrollable container. The real criterion is expected item count and whether the list can grow unbounded, not an assumption that lazy is intrinsically superior, and LazyColumn does unlock things like per-item animation and sticky headers that a plain Column would need manual work to replicate.
A LazyColumn using animateItem() animates item moves correctly, but inserting a new item at the top makes the whole list flicker and the entrance animation look wrong. Beyond having animateItem() present, what's actually going on and how would you fix it?
What a strong answer covers: This usually comes down to the items() key not being a stable identity derived from the data, so on insertion at the top, every subsequent item is treated as a different item by position rather than recognized as the same item that moved down, which defeats animateItem()'s move detection that relies on key continuity across the update. Separately, wanting an explicit entrance animation for the genuinely new item requires composing that yourself, for example with AnimatedVisibility inside the item or by tracking newly-added keys, since animateItem() only animates position and size changes of items that persist across the update, not the appearance of brand-new ones.