Android interviews in 2026: what’s still asked and what’s fading

On 6 September 2026 I opened Android’s own coroutines documentation to check a number before writing this, and found something worth repeating to anyone prepping Android developer interview questions right now: Google’s own page states that “over 50% of professional developers who use coroutines have reported seeing increased productivity,” and calls coroutines “our recommended solution for asynchronous programming on Android.” That’s not marketing copy from a Medium post. It’s the platform vendor telling you which tool the interview will assume you already know.

Android hiring in 2026 doesn’t look like Android hiring in 2019. Half the syllabus barely comes up anymore. This post is organized by what the interviewer is actually trying to find out, not by a flat question dump, because that’s closer to how a real loop actually flows.

Android developer interview questions about Kotlin coroutines

This is the block that decides whether you’re a serious candidate in the first five minutes.

Q: What’s the difference between a suspend function and a regular function, mechanically?
Model answer: a suspend function can pause its execution without blocking the thread it’s running on, then resume later, usually after some other async work finishes. It doesn’t create a new thread by itself. Coroutines run many suspended functions on a small pool of threads, which is why Android’s docs describe suspension as saving memory compared to blocking, since you’re not paying a full thread’s stack cost for every concurrent operation.
Follow-up: “Why does that matter for a list with 200 network calls?” Because 200 blocking threads would exhaust the thread pool and probably the device, while 200 suspended coroutines cost close to nothing until they’re actually doing work.

Structured concurrency, and where the Room call goes

Q: What is structured concurrency and why should a ViewModel care?
Model answer: structured concurrency means every coroutine launches inside a scope, and that scope owns the coroutine’s lifetime. When the scope is cancelled, cancellation propagates automatically through the whole hierarchy of child coroutines. Android’s documentation lists this directly under the benefits of coroutines: fewer memory leaks, because you run operations within a scope instead of leaving a bare thread running after the screen it belonged to is gone.
Follow-up: “What happens if you launch a coroutine in GlobalScope instead of viewModelScope?” It survives the ViewModel’s death. If it’s doing UI work or holding a reference back to a destroyed screen, that’s your leak, and it’s a subtle one because the app doesn’t crash, it just slowly accumulates garbage.

Q: Where do you put a Room database call, and why?
Model answer: behind a suspend function wrapped in withContext(Dispatchers.IO), so the disk read never blocks the main thread. Android’s own guidance calls a function “main-safe” when it doesn’t block UI updates on the main thread, and that’s the actual bar an interviewer is checking against, not whether you can recite Room annotations.

Jetpack Compose versus Views: is the old syllabus dead

Not dead. Slower to die than most Compose advocates expected.

Q: How does Compose’s recomposition model differ from the View system’s invalidate-and-redraw cycle?
Model answer: the View system invalidates a specific view and redraws that subtree on the next frame; you manage state yourself and manually update views when it changes. Compose observes state reads inside a composable function, and when that state changes, only the composables that actually read it get recomposed, skipping ones that don’t depend on it. The mental model flips from “tell the view what to draw” to “describe what the UI looks like for any given state, and let the framework figure out what changed.”
Follow-up: “What’s a common Compose performance mistake?” Reading unstable state (like a mutable list without a stable wrapper) inside a composable, which forces recomposition far more often than necessary because Compose can’t tell the data didn’t meaningfully change.

Q: Would you start a brand-new app on Views in 2026?
Honestly, no, and most interviewers asking this question already know the expected answer is no. Android’s architecture guidance leans hard toward Compose for new UI work. But XML layouts aren’t fading as fast in interviews as the tooling docs suggest, because most production Android codebases at companies over five years old still carry large View-based screens nobody has budget to rewrite, so knowing both is still worth more than knowing only one.

The activity and fragment lifecycle: why this question refuses to die

Interviewers keep asking lifecycle questions because configuration changes (rotation being the classic one) still break naive code, and because lifecycle bugs are invisible until a specific device or a specific OS version surfaces them in production, three weeks after the demo went fine.

Q: Walk through what happens to an Activity on screen rotation, and where state actually survives.
Model answer: the Activity is destroyed and recreated. Anything in a plain instance variable is gone. A ViewModel survives, because it’s scoped to the Activity’s lifecycle owner in a way that’s decoupled from the underlying Activity instance being torn down and rebuilt. onSaveInstanceState is the fallback for anything that needs to survive process death too, which a ViewModel alone does not.
Follow-up: “So why do people still get this wrong?” Because it works fine in the emulator during a quick demo and only breaks under real memory pressure or an actual rotation, which a lot of manual testing skips.

Q: Are Fragments still asked about in 2026?
Less than they used to be. Compose plus a single-activity architecture removes most of the reason to reach for Fragments at all, and I’ve noticed fewer interview loops centering a whole question block on Fragment back-stack management the way they did around 2020. It hasn’t vanished, since a lot of legacy apps still use them for navigation, so knowing the fragment lifecycle (particularly the gap between onCreateView and onViewCreated, and why view binding references must be cleared in onDestroyView) still comes up when the role touches an older codebase.

Architecture: MVVM, MVI, and why the interviewer cares which one you pick

Q: Describe MVVM on Android in your own words.
Model answer: the View (Activity, Fragment, or a Composable) observes a stream of state from the ViewModel and renders it. User actions flow the other direction as method calls into the ViewModel. The ViewModel holds no reference back to the View, which is what makes it survive configuration changes and stay testable without an Android framework dependency. Google’s own architecture guidance describes this as unidirectional data flow, and treats it as strongly recommended, not optional style.
Follow-up: “Why not let the View call the repository directly?” Because then business logic lives in the View, which is the hardest layer to unit test and the first thing that gets rewritten when the UI framework changes underneath it.

Q: What does MVI add that plain MVVM doesn’t already give you?
Model answer: MVI usually forces a single immutable state object per screen and models every user action as an explicit intent processed through one reducer-like function, which makes state transitions easier to trace and test in isolation. MVVM technically allows scattered mutable state across multiple properties unless the team enforces discipline. I think MVI is oversold for small screens, where the ceremony costs more than the traceability buys back, but it earns its keep on a genuinely complex screen with a dozen interacting states.

Performance and memory leaks

Q: Name three ways an Android app leaks memory that a junior developer wouldn’t expect.
Model answer: a static reference to an Activity or View held past its lifecycle. A registered listener or callback (location updates, sensor listeners, broadcast receivers) that’s never unregistered. An inner class or anonymous listener that implicitly holds a reference to its outer Activity, kept alive by something long-lived like a singleton.
Follow-up: “How would you actually catch one of these before shipping?” LeakCanary in debug builds catches most of the obvious ones automatically, and profiling with Android Studio’s memory profiler on a manual heavy-use session catches the rest that LeakCanary’s heuristics miss.

Q: An app is janky scrolling a RecyclerView with 40 items. Where do you look first?
Overdraw from nested layouts, expensive work happening inside onBindViewHolder (image decoding on the main thread is the classic offender), and missing DiffUtil causing a full rebind on every tiny data change instead of updating only what actually changed.

What’s fading, said plainly

AsyncTask is gone from interviews, and gone from the platform (deprecated, then removed as a recommended pattern entirely). RxJava questions still show up at companies with old codebases but rarely as the primary syllabus for a new hire in 2026, since coroutines and Flow cover the same ground with less operator-chain overhead for most teams. Deep manual View-touch-event handling questions have thinned out too, replaced by Compose gesture APIs almost everywhere except games and custom-drawing-heavy apps.

What hasn’t faded, and probably won’t: the rotation-and-state-survival question, because it’s really a proxy for whether you understand the Android process model, not whether you remember a specific API.

Before your interview

Read Android’s own architecture guidance and coroutines guide end to end once, they’re both short and current. Then build one small screen with real network calls and rotate the device while a request is in flight, because that ten-minute exercise surfaces more real lifecycle questions than a week of flashcards. If the role touches backend contracts too, our API developer interview questions post covers the other half of a full-stack mobile loop.

Most Android developer interview questions about architecture boil down to that one trade-off. What would change my mind about MVI being oversold for small screens? Seeing a team ship it on a three-screen MVP faster than they’d have shipped plain MVVM. I haven’t seen that yet. Practicing the actual verbal walkthrough of a lifecycle bug out loud, on something like LastRound AI‘s mock interview mode, catches more gaps than reading one more Compose tutorial does.