How to implement efficient large lists in Jetpack Compose?
This tests your grasp of Compose performance. Use LazyColumn to compose only visible items, unlike a Column which renders all items at once. A red flag is suggesting a scrollable Column, which has severe performance costs for large lists.
What's really being asked
This question tests your understanding of performance optimization in Compose. It's not just about knowing the name of a composable, but about understanding the fundamental difference between composing all UI elements at once versus composing them on demand. The interviewer is looking for your grasp of how declarative UI handles resource management, specifically for lists with a large or unknown number of items.
The full answer
An excellent answer addresses four points in order. First, state the correct tool for the job: LazyColumn for vertical lists, LazyRow for horizontal, or LazyVerticalGrid for grids. Second, explain the core mechanism: these composables are 'lazy' because they only compose and measure the items currently visible in the viewport, plus a small buffer for smooth scrolling. Third, contrast this directly with a standard Column or Row. Using a Column with a forEach loop composes every single item in the list upfront, leading to high memory usage and potentially long initial load times that can cause an Application Not Responding (ANR) error. Fourth, mention advanced but crucial features like providing a stable key for each item to help Compose optimize for data changes (adds, moves, deletes) and using LazyListState to observe or control the scroll position programmatically.
The mistakes people make
The most common red flag is suggesting a Column wrapped in a Modifier.verticalScroll(). This is a performance trap. It makes the content scrollable but still composes every item in the list at once, defeating the purpose of lazy loading. Another weak answer is simply naming LazyColumn without explaining the 'why'—the on-demand composition principle. Forgetting to mention the importance of the key parameter is a missed opportunity to demonstrate senior-level knowledge, as it's critical for performance in dynamic lists.
What usually comes next
Expect questions like: "How would you handle different view types within a single LazyColumn?" (Answer: use the item block with conditional logic or the contentType parameter). "When is it appropriate to use a scrollable Column?" (Answer: for a small, fixed number of items where the performance overhead is negligible). "How would you save and restore the scroll position across configuration changes?" (Answer: use rememberLazyListState with rememberSaveable).
A concrete example
Imagine a list with 5,000 items. A Column would attempt to create and hold all 5,000 item composables in memory at once, likely causing a multi-second freeze or an ANR on a mid-range device. A LazyColumn, however, would only create and measure the 8-10 items visible on screen, plus a few offscreen. Its initial composition time would be milliseconds, and its memory usage would be a tiny fraction of the Column's, regardless of whether the list has 5,000 or 500,000 items.
Interview question
You find a long list implemented with a `Column` and a `verticalScroll` modifier. What is the primary performance issue with this approach for large datasets?
- a.It composes every item in the list at once, regardless of visibility, causing high memory usage and slow initial rendering.Correct
- b.The `verticalScroll` modifier is less efficient at handling fling gestures compared to a LazyColumn's internal implementation.
- c.It requires manually providing a `key` for each item to ensure proper recomposition, which is handled automatically by `LazyColumn`.
- d.It prevents the use of `rememberLazyListState` for controlling scroll position, making programmatic scrolling difficult.
Why? this is the answer
The correct answer is B because a scrollable `Column` composes all its children upfront, which is a major performance trap for large lists. Option B is a tempting distractor, but the fundamental bottleneck is the composition strategy, not gesture handling.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles