RecyclerView, DiffUtil & XML Layouts Interview Questions
UI › Views & RecyclerView
Walk me through what actually happens end-to-end when a user scrolls a RecyclerView and a new row comes into view.
What a strong answer covers: As a view scrolls off-screen the LayoutManager detaches it and hands it to the Recycler, which first tries a quick scrap reuse if the position is still nearby, otherwise the ViewHolder moves into the shared RecycledViewPool keyed by view type; when a new row appears, the Adapter is asked for a ViewHolder of that type, and if the pool has one it's reused via onBindViewHolder, skipping the expensive inflate, otherwise onCreateViewHolder inflates a fresh one first. The nuance worth stating explicitly: recycling means rebinding, not 'the same data stays', so onBindViewHolder must fully set every field including resetting anything conditionally set like visibility or listeners, or recycled rows show stale state from whatever they previously displayed.
You inherit a RecyclerView screen that's janky while scrolling. Walk me through how you'd figure out whether the cause is layout complexity, bind-time work, or something else.
What a strong answer covers: Start with onBindViewHolder: object allocation, image decoding on the main thread, findViewById calls that should be cached in the ViewHolder, or new listener objects created on every bind instead of reused. If bind code is clean, the next suspect is layout complexity, deeply nested ViewGroups or nested weighted LinearLayouts causing multiple measure passes per row, which a profiling trace shows as high measure and layout time rather than high bind time, fixed by flattening with ConstraintLayout or merge. A strong candidate also checks whether notifyDataSetChanged() is being called for small updates instead of DiffUtil or ListAdapter, since that alone rebinds and re-animates the whole visible window and looks identical to generic jank until you check the call site.
In 2026, when would you still choose RecyclerView and XML over a Compose LazyColumn for a new screen, and what are you actually giving up either way?
What a strong answer covers: You'd still reach for RecyclerView when joining an existing large View-based module where a ComposeView adds interop overhead and inconsistent theming for marginal benefit, or in extremely performance-sensitive lists with huge item counts and custom decorations where the team has already tuned RecyclerView's recycling and prefetch behavior and doesn't want to re-verify perf under Compose. Choosing RecyclerView gives up Compose's simpler state-driven item animation model, since DiffUtil payloads have to be hand-rolled; choosing LazyColumn gives up RecyclerView's maturity in custom LayoutManagers, ItemTouchHelper, and established performance tuning. A weak answer frames this as old versus new rather than a real, still-live trade-off.