An Android domain interview asks platform questions, like what happens to a ViewModel on rotation. Then it keeps asking. Each follow-up goes one level deeper. A correct first answer only gets you to the next question. The score comes from how far down that chain you can go. Google’s hiring guide says its interviewers plan follow-ups in advance. They grade answers against examples of poor, borderline, solid and outstanding responses. So a textbook answer that stops at the API name can be right and still read as borderline. The fix is to answer each question in four steps. Say what happens. Say how the platform makes it happen. Say where it breaks. Then say what you’d do about the break and how you’d test it. Below is one question taken through all four steps. A sample answer follows, then a practice drill for the rest of the round.
Android knowledge questions appear in two places in the loop
Some companies ask Android questions for a few minutes inside another round. Meta’s careers blog published a guide to its Android engineering interview in July 2016. At the time, its 45-minute technical screen opened with 5 to 10 minutes of Android questions. They covered key APIs and common problems. The listed topics ran from activities and fragments to concurrency, storage and rendering. That guide is ten years old, so ask your recruiter whether the format still holds.
Other loops give Android a full round. Sharib Khan described a Google Android L4 loop in a February 2025 post. His Android domain round covered architecture, coroutines and memory management. Then it moved to debugging questions about a log file. Amit Shekhar runs Outcome School. It sells Android interview courses. His September 2020 guide to Google’s Android interview lists similar topics. They include Handler and Looper, ViewModel internals, multithreading and memory leaks. Both are single accounts, not a published format.
Either format can follow a first answer with a deeper question. A full round just has time for more of them.
Google plans the follow-up questions before you walk in
Google’s re:Work site publishes its guide to structured interviewing, last updated in March 2026. It’s a general hiring guide, not an Android one. But it explains how a planned question is scored. The guide says interviewers prepare follow-up questions ahead of time. Those follow-ups draw out more detail on how a candidate thinks. Each attribute gets a rubric with example answers at four levels. Those are poor, borderline, solid and outstanding. Interviewers also take detailed notes for the people who decide later.
That changes what a correct answer is worth. The interviewer already knows where the questions go. If your first answer only names the API, the next question asks for the mechanism. If you can’t give it, the note says the answer stopped there. Our post on getting rejected after a good interview covers how those notes decide the outcome.
One question taken through four levels of follow-up
Take a common opener. “What happens to a ViewModel when the user rotates the phone?” Here’s the chain it tends to follow, one level at a time.
The first level is what happens. The ViewModel survives. Android’s ViewModel overview says it keeps its state through configuration changes like rotation. So the screen doesn’t fetch its data again. An answer can stop here and still be correct. It just leaves the next three questions to the interviewer.
The second level is how the platform does it. The next question is often “how?” The same page explains the scope. A ViewModel belongs to a ViewModelStoreOwner. That owner is often an activity or a navigation entry. It stays in memory until that owner goes away for good. For an activity, that means when it finishes. A rotation destroys the activity object and creates a new one. But the activity isn’t finishing, so its store and the ViewModel inside it are kept.
The third level is where it breaks. Here the interviewer asks what the ViewModel doesn’t survive. The answer is system-initiated process death. The guide on saving UI states compares three options. ViewModel state lives in memory, so it’s lost when the system kills the process. Saved instance state survives that. Only persistent storage survives the user closing the screen for good. A user who backgrounds a long form and comes back later can lose it. That happens even though rotation never lost a thing.
The fourth level is what you’d do about it. It also covers where that fix runs out. The saved state module gives the ViewModel a SavedStateHandle for this case. But the saving-states guide warns against putting large data there. It suggests keeping small values like an ID. You reload the rest from storage. The reason is a hard limit. Android’s TransactionTooLargeException reference says the Binder transaction buffer is currently 1MB. All transactions in progress for the process share it. A large form belongs in Room, with only its draft ID in saved state.
A strong candidate adds how to test it. The adb documentation lists adb shell am kill. It kills only processes that are safe to kill. So you background the app first, run the command, then return to it. If the form comes back empty, the state wasn’t saved.
A sample answer that reaches level 4 before it’s asked
You don’t have to wait for each follow-up. You can walk down the chain yourself and stop where the interviewer cuts in. Here’s the ViewModel answer, spoken in about a minute. Adapt it to the question you get.
It survives rotation. The ViewModel is scoped to a ViewModelStoreOwner, here the activity. Rotation recreates the activity. But the activity isn’t finishing, so the store is kept. What it doesn’t survive is the system killing the process in the background. For that I’d put small state, like a draft ID or a query, in SavedStateHandle. I wouldn’t put the whole form there. Saved state goes through Binder. That buffer is 1MB. The whole process shares it. So the form itself goes in Room. To check it, I’d background the app and run adb shell am kill. Then I’d reopen the app and see what’s still there.
Each part answers a follow-up before it’s asked. The opening sentence gives the fact. The next three give the mechanism. Then the answer names the failure case. The middle gives a fix with its limit and the reason for the limit. The last part shows how you’d check it in a real app.
Keep the answer short at each level. A long speech on level 1 burns time the interviewer planned for levels 3 and 4. If they cut in, follow them. They may want a different branch. One example is how rememberSaveable in Compose fits in.
When you reach a level you don’t know
Suppose the interviewer asks how the activity hands its store to the new instance during rotation. You may not know the exact method. Guessing a name you half remember is worse than saying where you’d look. Try something like this.
I don’t know the exact hook. I know the store is handed from the old activity instance to the new one during the change. I’d check the ComponentActivity source to see where that happens.
That gives the mechanism you’re sure of and marks the edge of what you know. It also names a concrete next step. In a structured interview, the note records how far you got. It doesn’t need to record a wrong guess too.
Practice each Android domain interview topic as a chain
A list of Android interview questions mostly trains the first level. A planned follow-up asks for the next three. So drill each topic as a chain.
- Pick one topic from your recruiter’s list. Khan’s round, for example, covered coroutines and memory management.
- Write the opener question. Under it, write one line for each of the four levels. Cover what happens, how, where it breaks and the fix with its limit.
- Find the official doc for levels 2 and 3. If you can’t find one, you’re guessing at that level.
- Add a test you could run for level 4. For memory leaks, that might be a heap dump after rotating ten times.
- Answer out loud in under a minute. Then have a friend interrupt at a random level and push one step deeper.
Ask your recruiter whether the loop has an Android domain round. Also ask how long it runs. If the round also includes a log file or a design task, prepare for those too. Our posts on the Android pairing round and the Android debugging interview cover those formats.