Android interviews reuse a surprisingly small set of topics. Lifecycle, state, coroutines, Compose, and how you'd keep a big app from collapsing under its own weight — that's most of it, at every company, at every level.
Which is why "I know lifecycle" predicts almost nothing about how the interview will go. The topic stays the same as you move up; the bar moves. The same question, asked to a Junior and to a Senior, is graded on completely different things.
| Level | How the rotation question sounds | What the answer is graded on |
|---|---|---|
| Junior | "What happens when the screen rotates?" | The rule. The Activity is recreated, and state is lost unless something saves it |
| Middle | "So where would you keep that state, and why there?" | The reason. Which storage survives which kind of death — and that there is more than one kind |
| Senior | "How do you decide what deserves to survive at all?" | The trade-off. What's cheap to refetch, versus what the user typed and can never be asked for twice |
So this list is sorted by level rather than by topic. Find the level you're interviewing at, then read the next one up as well — the questions that decide an offer usually come from one step above the title you applied for.
Junior: can you build a screen that behaves
What they're checking: whether you understand the framework's rules well enough not to fight them.
- What happens to an Activity when the screen rotates?
- What's the difference between an Activity and a Fragment, and why do Fragments exist at all?
- What is an Intent, and when is it explicit versus implicit?
- Why can't you do network work on the main thread?
- How does
RecyclerViewreuse views, and what breaks if you forget that it does? - What does Kotlin's null safety actually buy you compared to Java?
- How would you pass data from one screen to the next?
Saying it out loud: question 5 is the one that separates people who've shipped a list from people who've followed a tutorial. Everyone can say "it recycles views for performance." The half that scores is the consequence: "Because the view gets reused, anything I set in onBindViewHolder I have to set every time — including clearing it. The classic bug is loading an image asynchronously, scrolling fast, and the wrong image landing in the wrong row, because that holder has already been rebound to different data." You've now shown you've debugged it, not read about it.
Middle: can you reason about state and concurrency
What they're checking: whether you can explain why the framework behaves that way — not just what it does.
- What is process death, and how is it different from a configuration change?
ViewModelorSavedStateHandle— when do you need which?- Explain coroutine scopes. What happens to a running coroutine when the screen goes away?
StateFlow,SharedFlow,LiveData— how do you choose between them?- What causes a recomposition in Compose, and how do you avoid the unnecessary ones?
- How do memory leaks happen on Android, and how would you track one down?
- What do you actually unit test in an Android app — and what do you deliberately not test?
Saying it out loud: question 8 is the single most reliable Middle-level filter, because it's the point where the mental model either exists or doesn't. Answer it as two different events with two different survivors: "A configuration change destroys the Activity but the process stays alive, so a ViewModel survives it. Process death is the system killing the whole process while you're backgrounded — the ViewModel is gone with it, and you come back to a fresh one with the user still expecting their half-filled form. That's the case SavedStateHandle exists for, and it's why I test it by killing the app from the developer options rather than by rotating." That last sentence is worth as much as the rest, because it says you've actually reproduced it.
Question 14 is quietly a judgment question, not a testing question. Candidates recite the testing stack; what scores is drawing the line — business logic and state reducers yes, framework glue whose only assertion is that the framework still works, no.
If you've been told you "answered everything correctly" and still didn't get the offer, this is usually the gap. Nothing in the topic list changed between the two sections above — lifecycle is still lifecycle, coroutines are still coroutines. What changed is that a correct answer stopped being enough on its own. An answer that ends at the rule is not wrong; it's just an answer to the Junior version of the question.
Senior: can you make decisions other people have to live with
What they're checking: whether you can defend a trade-off in front of the people who'll maintain it.
- How would you split a large app into modules, and what do you actually gain?
- Design an offline-first feature. What happens when a sync conflicts?
- An ANR is being reported in production and you can't reproduce it. How do you find it?
- The app has hundreds of View-based screens and Compose is the direction. What's your migration plan?
- How do you decide between adding a third-party library and writing it yourself?
- Startup time regressed by 400ms after a release. Walk me through what you do.
Saying it out loud: question 18 is where senior candidates most often answer a smaller question than the one asked. "We'd use interop and migrate screen by screen" is the tactic, and the tactic isn't the answer — the answer is the plan around it: "I'd start with the leaf screens that nobody else depends on, so the first migrations are cheap and reversible. I'd freeze new View-based screens on day one, because the only migration that ever finishes is one where the old thing stops growing. And I'd want a rule for what we don't migrate — screens due to be deleted next quarter get left alone." Order, a stopping rule, and something explicitly out of scope. That's what makes it sound like you've run a migration rather than read the interop guide.
Question 20 rewards asking before diagnosing. Which release, which device tier, cold or warm start, and is the number from a real distribution or one machine — the interviewer is watching whether you narrow the problem before touching a profiler.
Which level are you actually being interviewed at?
Android loops have a habit that catches people out: the interviewer picks one topic and keeps following up until you stop knowing. Rotation, then ViewModel, then process death, then how the system decides what to write into the bundle — each answer buying the next, harder question.
Candidates read that as failing. It usually isn't. It's calibration: the fastest way to find the top of someone's knowledge is to climb until they run out, and an interviewer who stops early has learned less about you, not more. Which means the moment you hit your limit is a normal, expected part of the interview — and how you handle it carries real weight, because it's one of the few genuinely unrehearsed moments in the conversation.
Bluffing past the edge
“I think it… depends on the configuration, it should handle that automatically in most cases.”
The interviewer already knows the answer, so they can tell. And they've now learned something worse than a knowledge gap — that under pressure your confidence stops tracking what you actually know.
Naming the edge
“That's past where I've worked. What I'd expect is that the saved state survives, because the system writes it into the bundle before it kills the process — but I'd verify that before relying on it. Is that the direction you're going?”
You've marked the boundary, shown your reasoning at it, and handed the conversation back. The gap costs you a point. Handling it this way often earns more than that back.
The one thing to avoid is a flat "I don't know" with nothing after it. Say where the edge is, say what you'd expect and why, then say how you'd check. That's the same behaviour they want from you on a Monday morning with a bug nobody has seen before.
The part that isn't about Android
Read back through the three levels and notice how little of the difference is knowledge. The Junior answer and the Senior answer to the rotation question are about the same feature. What changes is scope, ordering, and the willingness to say what you'd leave out — all of which live in how you talk, not what you know.
That's also why grinding more topics stops working at a certain point. If you've been preparing for a while and your answers still come out as definitions, more input isn't the fix. We wrote about a saner way to run the preparation itself in How to practice interviews without burning out.
Practical target: take question 1, question 8 and question 16 — the same "what happens to state you didn't protect" thread at three levels — and answer all three out loud, back to back. If your Junior answer and your Middle answer come out sounding the same, that's the level you're currently interviewing at, whatever the title on the job posting says.
