30 Android Interview Questions, Ranked by Level

Use 30 Android interview questions ranked by level to focus on the most common phone-screen topics first, with model answers and follow-ups.

Most candidates preparing for Android interviews don't have a knowledge problem. They have a prioritization problem. If you've been staring at a list of 80 android interview questions trying to figure out where to start, you already know the feeling: you've read about Activities and Fragments and Intents, but you're not sure which ones will actually come up in the first ten minutes, and you're not sure your answers sound like someone who has shipped a real app. This guide is built for junior developers, career switchers, and mid-level engineers who want the shortest path from "I've read the docs" to "I can hold this conversation." The structure is level-ordered on purpose — study what shows up first, go deeper only when you've nailed the basics.

The real gap isn't coverage. It's that most Android prep resources treat every question as equally important, which means you spend equal time on obscure JNI internals and on the Activity lifecycle question that shows up in literally every phone screen. That's a bad trade. The ordering in this guide comes from comparing overlap across multiple Android interview question lists and manually coding the topics that repeat most often in screening rounds, mid-level loops, and take-home follow-ups. Start at the top. Move down as your confidence grows.

Start with the Questions That Show Up Everywhere

What are the first Android interview questions to study for junior roles?

The highest-frequency beginner questions cluster around four topics: the Activity lifecycle, Android application components, Intents, and Context. These are not just definitional — they are the interviewers' first filter. If your answers on these sound like you memorized a glossary, the call gets shorter. If they sound like you've actually hit a rotation bug at 11pm, the call gets longer.

The common mistake is reciting the callback sequence — `onCreate`, `onStart`, `onResume` — without connecting it to anything that actually happened in your app. A stronger answer pattern: name the callback, say what it means for your UI or data, and tie it to one concrete decision you made. "We moved our network call to `onStart` instead of `onCreate` because we needed it to re-fire after the user backgrounded the app to grant a permission" is more useful than a diagram.

Study these five questions first, in this order: What is the Activity lifecycle and when does each callback fire? What are the four main Android components? What is Context and when do you use Application context versus Activity context? What is the difference between an Activity and a Fragment? What is an Intent, and when do you use explicit versus implicit?

Which Android questions are most likely to be asked in the first 10 minutes?

Interviewers use the opening minutes to check one thing: have you actually built something? The questions they use to check this are deceptively simple. "Walk me through how you'd build a login screen" or "how does your list screen handle a slow network?" are not architecture questions — they're credibility checks.

A grounded answer uses a real project as scaffolding. Say you built a simple list screen backed by a REST API. A strong answer to "how does your list handle a slow network?" sounds like: "We show a loading state while the request is in flight, map the result to a UI state sealed class, and update the RecyclerView adapter from the ViewModel. If the request fails, we show an error banner with a retry button." That answer reveals architecture, state handling, and user experience awareness in four sentences. It does not require a fancy project — it requires that you actually thought about the problem.

What should a career switcher learn first to stop sounding lost?

The gap for career switchers is usually not Android syntax — it's Android vocabulary plus missing mental models. You can read Kotlin fluently and still sound lost when an interviewer asks why you'd use a Fragment instead of just another Activity, because you haven't built the intuition for why Android's component model exists.

The questions that unlock the rest of the interview are the same ones above, but the career switcher needs to understand why these concepts exist, not just what they do. Android's component model exists because the OS can kill your process at any time — understanding that one fact makes lifecycle, saved state, and Context all make sense at once. Start there. Build a toy app with one Activity, one Fragment, a ViewModel, and a list backed by a fake repository. Ship it to an emulator and rotate the screen. You'll learn more from that one exercise than from reading twenty interview prep lists.

Prove You Understand the Android Basics, Not Just the Glossary

The jump from "I know what these are" to "I sound like an Android developer interview questions veteran" is almost entirely about framing. Interviewers who've done fifty screening calls can tell within two answers whether you've used these concepts or just read about them.

What is Android, and what makes it different from just another mobile app platform?

Android is a Linux-based operating system and application framework designed for touchscreen devices. But the interview answer that actually lands goes one level deeper: Android is a platform where apps are not continuously running processes — they are collections of components the OS instantiates and destroys based on system resources and user behavior. That distinction matters because it explains everything downstream: why lifecycle exists, why you can't hold a long-lived reference to an Activity, and why the app sandbox isolates your process from others.

The follow-up interviewers are really probing is whether you understand that you don't fully control your app's execution. If you've internalized that, your lifecycle and state answers will automatically sound more grounded.

What are the main Android application components?

There are four: Activities, Services, Broadcast Receivers, and Content Providers. Each one is a distinct entry point into your app that the OS can invoke independently.

An Activity is a single screen with a UI. A Service runs background work without a UI — think a music player continuing to play after you leave the app. A Broadcast Receiver listens for system-wide or app-wide events, like a network connectivity change. A Content Provider exposes structured data to other apps, like the contacts database.

In a messaging app, you'd have an Activity for the conversation screen, a Service for maintaining the socket connection, a Broadcast Receiver to detect when the device comes back online, and potentially a Content Provider if you're exposing message data to a search widget. The components are not interchangeable — each one has a specific lifecycle and a specific reason to exist.

What is the difference between an Activity and a Fragment?

The simple answer: an Activity is a full screen, a Fragment is a reusable UI piece that lives inside an Activity. That's correct and it gets you through the first half of the question.

Where it breaks in real apps: Fragments add a second lifecycle layered on top of the Activity lifecycle, they have their own back stack behavior, and their state can get out of sync with the parent Activity on rotation or process death if you're not careful. The pain point candidates who've actually shipped fragments know is the `onCreateView` versus `onViewCreated` distinction, the difference between `getViewLifecycleOwner()` and `this` when observing LiveData, and the fact that fragment transactions are asynchronous in ways that surprise you the first time.

A strong answer names the reuse benefit — a Fragment can be shown in a single-pane or dual-pane layout depending on screen size — and then acknowledges the complexity cost: "Fragments are worth it for navigation and reuse, but they add lifecycle surface area you have to manage carefully."

What does Context actually do in Android?

Context is the interface between your code and the Android system. It lets you access resources like strings and drawables, system services like `LayoutInflater` or `ConnectivityManager`, and app-level operations like starting an Activity or registering a broadcast receiver.

The follow-up interviewers almost always ask: "Which Context do you use in an adapter?" The answer is Application context for anything that outlives the screen, Activity context for anything tied to the UI. Using an Activity context in a long-lived object — a singleton, a static reference, a callback that outlives the Activity — is one of the most common memory leaks in Android. A strong answer names that tradeoff explicitly: "In an adapter I use the context passed in via the constructor, which is typically the Activity context, and I'm careful not to hold a static reference to it."

What is an Intent, and when do you use explicit vs implicit intents?

Think of an Intent as a routing message. An explicit Intent names the exact component you want to start — it's how you navigate from a feed screen to a profile detail screen within your own app. An implicit Intent describes an action and lets the system find an app that can handle it — it's how you share text to another app or open a URL in a browser.

The practical difference: explicit Intents are for internal navigation where you control both endpoints. Implicit Intents are for cross-app communication where you don't know or care which app handles the request. If you're launching a camera intent to let the user take a photo, you use implicit — you don't care whether it's the stock camera or a third-party app. If you're opening your own settings screen, you use explicit. The Android developer documentation on Intents and Intent Filters covers the resolution mechanism in detail and is worth reading before any screening call.

Answer Lifecycle and State Questions Without Drifting Into Memorized Trivia

Android interview prep on lifecycle tends to go wrong in the same direction: candidates memorize the callback sequence and then freeze when the interviewer asks what actually happens to the UI state when the user rotates the screen.

What does the Activity lifecycle actually test?

Interviewers use lifecycle questions to check whether you understand when UI state lives, dies, and gets rebuilt — not whether you can recite six method names in order. The rotation-change scenario is the canonical test: when the user rotates the screen, the Activity is destroyed and recreated. If you've stored UI state in a local variable, it's gone. If you've stored it in a ViewModel, it survives.

A strong answer explains the why behind the callbacks: `onPause` is where you release anything that consumes resources when the screen isn't visible, `onStop` is where you save persistent data, `onDestroy` is cleanup. The interviewer is checking whether you've thought about what happens at each transition, not whether you've memorized the diagram.

How should you talk about process death and saved state?

The structural mistake most candidates make: they prepare for rotation but forget that the OS can kill the process entirely when the app is backgrounded. Rotation recreates the Activity in the same process — the ViewModel survives. Process death destroys everything, including the ViewModel. Only `savedInstanceState` and persistent storage survive process death.

A strong answer sounds like: "For configuration changes like rotation, I keep UI state in a ViewModel. For process death, I use `rememberSaveable` in Compose or `onSaveInstanceState` in Views for transient UI state, and I rely on the repository layer for anything that needs to survive across sessions." That answer reveals that you've thought about both failure modes, not just the one that's easier to test. The Android documentation on saving UI state distinguishes these cases explicitly.

Why do Fragment questions trip people up so often?

Fragments are hard because they combine three problems at once: their own lifecycle, navigation stack behavior, and parent-child state management. A candidate who's only read about Fragments will give an answer about reuse and modularity. A candidate who's shipped one will mention the back stack.

A concrete example that reveals real experience: nested fragments, where a child Fragment inside a parent Fragment can receive `onResume` callbacks at different times than the parent, and where the child back stack is separate from the Activity back stack. Another signal: knowing that you should observe LiveData from `viewLifecycleOwner` inside a Fragment, not from `this`, because the Fragment's view can be destroyed and recreated while the Fragment itself is still alive. That one bug — observing from the wrong owner — causes duplicate observers that fire after the view is gone.

One concrete lesson from a real debugging session: assuming the Activity would still be in a valid state after the app was backgrounded for several minutes caused a crash when the Fragment tried to access a resource through the Activity's context after the OS had reclaimed it. The fix was straightforward once diagnosed, but it only makes sense if you understand that backgrounding is not the same as the user pressing back.

Use Architecture Answers to Show Judgment, Not Memorization

Architecture questions are where mid-level Android interviews separate candidates who have read the docs from candidates who have made real tradeoff decisions. The interviewer is not checking whether you know what MVVM stands for — they're checking whether you can explain why you'd choose it and where it creates pain.

How do MVVM, MVP, and MVC differ in real Android projects?

MVC in Android is mostly a historical pattern — the Activity ends up being both the Controller and the View, which makes testing nearly impossible. MVP separates the Presenter from the View via an interface, which makes unit testing the Presenter straightforward but creates a lot of boilerplate: every interaction requires an interface method.

MVVM with a ViewModel and observable state (LiveData or StateFlow) is the modern default. The ViewModel holds UI state and business logic, the View observes and renders, and there's no direct reference from the ViewModel to the View. The tradeoff: MVVM requires understanding reactive patterns, and the ViewModel's state management can get complex in screens with many independent state dimensions.

Where each one becomes painful: MVC falls apart when the Activity grows past 500 lines. MVP becomes painful when the interface grows to 30 methods. MVVM becomes painful when you have multiple ViewModels sharing state without a clear owner.

When would you choose MVVM over MVP in a new app?

For any new Android project in 2024, MVVM is the default — not because it's theoretically superior but because Jetpack is built around it. ViewModels survive configuration changes natively, StateFlow and LiveData integrate with lifecycle-aware observers, and Hilt provides dependency injection that fits the ViewModel pattern cleanly.

The tradeoff interviewers care about: MVVM with StateFlow requires the team to understand coroutines and reactive state updates. If you're adding a new feature screen to a legacy MVP app, converting to MVVM mid-feature creates inconsistency. In that case, extending the existing MVP pattern is the pragmatic choice — consistency beats theoretical correctness in a shared codebase.

What architecture topics are table stakes for mid-level Android interviews?

At the mid-level, interviewers expect fluency on: the Repository pattern as the single source of truth for data, ViewModels as the boundary between UI and data layers, one-way data flow (state flows down, events flow up), and dependency injection via Hilt or Dagger. The depth expected is not academic — it's "explain how your ViewModel gets its data from the repository and how the UI updates when the network response arrives."

A concrete production scenario: a feature screen that shows a cached feed, makes a network request, and updates the UI with fresh data. The ViewModel exposes a `StateFlow<UiState>` that starts in `Loading`, transitions to `Success` with cached data immediately, then updates again when the network call resolves. The Repository handles both the local Room query and the remote API call. The Android architecture guide from Google describes this layered pattern in detail and is the canonical reference for the vocabulary interviewers expect.

Show That Kotlin and Coroutines Are Part of Your Day Job

What Kotlin basics still come up in Android coding interview questions?

The Kotlin features that matter most in Android codebases are null safety, data classes, sealed classes, and scope functions (`let`, `apply`, `run`, `also`). Null safety matters because it forces explicit handling of nullable references — interviewers will ask how you handle a nullable API response. Sealed classes matter because they're the right way to model UI state with a finite set of outcomes (`Loading`, `Success`, `Error`). Scope functions come up because they appear everywhere in Android code and interviewers want to know you can read them fluently.

The likely follow-up on sealed classes: "Why not just use an enum?" The answer is that sealed classes can carry different data in each subtype — `Success` can hold the data, `Error` can hold the exception — which enums cannot.

What coroutine concepts do Android interviewers expect you to know?

Cover four areas: Dispatchers (Main for UI work, IO for network and disk, Default for CPU-heavy work), suspension (a coroutine suspends without blocking the thread), structured concurrency (coroutines are scoped and cancelled together), and cancellation (a cancelled coroutine propagates cancellation to its children).

The practical example interviewers want: a network request that starts when the screen opens and should be cancelled when the user navigates away. In a ViewModel, you launch the coroutine in `viewModelScope` — when the ViewModel is cleared, the scope is cancelled, and the network request is cancelled with it. That one example covers dispatchers, suspension, and structured concurrency in a single coherent story. The Android coroutines documentation covers `viewModelScope` and `lifecycleScope` usage in detail.

How do you explain Flow, LiveData, and RxJava without wandering?

LiveData is lifecycle-aware and simple, but it's limited to the main thread and doesn't have the full reactive operator set. Flow is Kotlin-native, works across threads, and integrates naturally with coroutines — it's the modern default for reactive streams in Android. RxJava predates both and has a much larger operator surface, but it brings significant complexity and a learning curve that's hard to justify in new projects.

In practice: use StateFlow for UI state in a ViewModel, use Flow for data streams from a repository or database, and use LiveData only if you're maintaining a legacy codebase that already uses it. RxJava appears in older codebases — knowing how to read it is valuable, but you shouldn't reach for it in new code. The concrete codebase signal: in one production project, repository calls used coroutines for single-shot network requests and Flow for database observation, with `stateIn` converting the Flow to StateFlow at the ViewModel boundary.

Compare Storage and Data Layers the Way Working Android Engineers Do

Mobile interview questions on storage tend to be practical — interviewers want to know you can pick the right tool for the job, not that you can define all four options.

How do Room, SQLite, SharedPreferences, and DataStore compare?

SQLite is the raw database layer — powerful, but you write SQL strings manually and handle cursor management yourself. Room is an abstraction over SQLite that adds compile-time query verification, type-safe DAOs, and migration support. Use Room whenever you need structured, relational data with more than a handful of rows.

SharedPreferences stores simple key-value pairs synchronously on the main thread — fast to set up, but it blocks the main thread on write and has no type safety. DataStore (specifically Preferences DataStore) is the modern replacement: it's asynchronous, uses Kotlin Flow, and is safe to use on any thread. For typed, structured preferences, Proto DataStore adds schema enforcement.

The practical tradeoff: Room for an offline cache or notes database, DataStore for user settings, SharedPreferences only when you're maintaining existing code that already uses it.

When is SharedPreferences still acceptable, and when is it the wrong choice?

SharedPreferences is still fine for tiny, infrequently-written key-value settings — a boolean for "has the user completed onboarding" or a string for "last selected tab." The read is synchronous and fast for small data, and the setup cost is essentially zero.

It fails when you write frequently (the synchronous disk write blocks the main thread), when you need to observe changes reactively (there's no Flow support), or when your data has any structure beyond flat key-value pairs. DataStore wins in all three of those cases. A realistic migration scenario: moving a "user preferences" SharedPreferences file to Preferences DataStore in an existing app — the migration is straightforward using the `DataStore` migration API, and the result is a reactive, coroutine-friendly preferences layer.

What does a strong Room answer sound like in an interview?

Cover four concepts: Entities (data classes annotated with `@Entity` that map to database tables), DAOs (interfaces annotated with `@Dao` that define queries), queries (SQL or Room's query DSL, with compile-time verification), and migrations (versioned schema changes that preserve existing data).

A concrete example: an offline notes app where notes are stored in a Room database, fetched via a DAO that returns a `Flow<List<Note>>`, and observed in the ViewModel. When the user adds a note, the DAO inserts it, Room notifies the Flow, and the UI updates automatically. The migration story: when you add a `lastModified` column in version 2, you write a migration that adds the column with a default value so existing notes aren't lost.

Bring It Home With Performance, Testing, and Project Talk

What Android performance topics should you prepare beyond definitions?

Four areas that separate real experience from theory: RecyclerView performance (view recycling, `DiffUtil` for efficient updates, avoiding heavy work in `onBindViewHolder`), memory leaks (long-lived references to Activity or View, common in listeners and callbacks), ANRs (Application Not Responding errors caused by blocking the main thread), and startup time (cold start versus warm start, deferring non-critical initialization).

A concrete example: a scrolling feed with images. If you load images synchronously in `onBindViewHolder`, you'll drop frames. The fix is an image loading library like Coil or Glide that handles threading and caching. If you hold a reference to the adapter in a static field, you'll leak the RecyclerView and everything it holds. The Android performance documentation covers profiling tools including the Android Profiler, which is the right tool for diagnosing startup slowdowns and memory leaks.

What testing strategy should you be ready to explain?

The answer interviewers want is not "I write tests for everything" — it's a clear mental model of what to test where. Unit tests cover ViewModel logic, repository behavior, and utility functions — they run on the JVM, use Mockito or MockK for dependencies, and are fast. Integration tests cover the interaction between components, like a ViewModel and a fake repository. UI tests (Espresso or Compose's testing APIs) cover user flows, but they're slow and brittle — use them sparingly for critical paths, not for every screen.

The practical framing: test the ViewModel exhaustively because it contains the business logic. Test the repository with a fake data source to verify mapping and error handling. Test the UI only for flows where a regression would be catastrophic, like login or checkout.

What project questions do Android interviewers ask to see if you actually owned the app?

The follow-up probes that turn a project description into a credibility check: "Why did you choose that architecture?" "What was the hardest bug you fixed?" "What tradeoff did you make that you'd do differently now?" "What would you change if you started over?"

These questions have no wrong answer — they have revealing answers and evasive ones. A revealing answer names a specific decision, explains the constraint that drove it, and acknowledges what it cost. "We used SharedPreferences for caching because it was fast to ship, but it caused main thread jank at scale and we eventually migrated to Room" is a credibility-building answer. "We followed best practices" is not.

One concrete debugging story: tracing a startup slowdown using the Android Profiler revealed that a third-party SDK was doing disk reads synchronously on the main thread during `Application.onCreate`. Moving the SDK initialization to a background coroutine cut cold start time by 400ms. That kind of specific, numbered outcome is what interviewers remember.

How Verve AI Can Help You Prepare for Your Interview With Android

The hardest part of Android interview prep isn't learning what a ViewModel does — it's learning to explain what a ViewModel does under live pressure, when the interviewer follows up with "and what happens to that ViewModel when the process is killed?" Most prep tools give you the question and a model answer. They don't give you the follow-up.

That's the structural problem Verve AI Interview Copilot is built to solve. It listens in real-time to the actual conversation — not a canned prompt — and responds to what you actually said, including the part where you glossed over process death and the interviewer noticed. Verve AI Interview Copilot can run mock sessions that adapt to your answers, push back on vague responses, and surface the follow-up questions that real Android interviewers use to separate candidates who've read the docs from candidates who've shipped the app.

The specific capability that changes the calculus for Android prep: Verve AI Interview Copilot suggests answers live based on what's being asked in the moment, which means you can practice the exact sequences that break most candidates — the pivot from "explain the Activity lifecycle" to "what happens to your UI state when the OS kills the process?" — until the answer feels automatic, not rehearsed.

Conclusion

You don't need to study every Android topic at equal depth before your next interview. You need to study the ones that show up first, answer them in a way that sounds like you've actually built something, and go deeper on architecture, Kotlin, and storage only after you've nailed the basics.

Use the level order in this guide as a checklist, not a reading list. Before your next phone screen, confirm you can answer the Activity lifecycle, components, Context, Intent, and Fragment questions without hesitation. Before a mid-level loop, confirm you can explain MVVM versus MVP with a real tradeoff, walk through a ViewModel and repository pattern with a concrete feature, and talk about coroutines in terms of what they do in your app. Before the project discussion, have one specific debugging story ready — with a number attached.

The goal is not to have memorized thirty answers. It's to sound like someone who has shipped Android apps and thought carefully about the decisions they made. That's what the ordering is for.