Android Developer interview questions and how to answer them
Android interviews reward people who've been burned by real apps. The interviewer wants to hear about the rotation bug, the leaked Activity, the crash that only happened on one manufacturer's phones. Here's what each round checks, the questions that come up most, and what a good answer sounds like.
What happens in each round
- 1
Recruiter screen
What happens
Whether you've shipped native Android in Kotlin, whether you've worked in Compose or only XML views, and whether your salary range and location line up. Have a short, specific answer ready about the last app you released.
- 2
Technical phone screen
What happens
Core platform knowledge: the Activity and Fragment lifecycle, ViewModel scope, coroutines, and how you'd structure a simple screen. Often a shared editor with a small Kotlin problem where they care more about idiomatic code than cleverness.
- 3
Take-home or live coding
What happens
A small app that loads a list from an API, shows it, and handles loading and error states. They read your architecture, how you manage state across rotation, whether you wrote any tests, and the README where you explain trade-offs.
- 4
Mobile system design
What happens
How you'd build something like an offline-first feed or a chat screen: caching with Room, sync with WorkManager, pagination, and what happens when the network drops mid-request. They want you to ask about constraints before drawing boxes.
- 5
Team and behavioral round
What happens
How you work with designers, backend engineers and QA, how you handle a bad release, and whether you review code kindly. Usually with the engineering manager and a product or design partner.
Questions you're likely to get
1.Walk me through what happens to an Activity when the user rotates the phone.
Why they ask
Configuration changes are where junior Android code falls apart. They want to know you understand that the Activity is destroyed and recreated, and what survives.
How to answer
- Say the Activity goes through onPause, onStop and onDestroy, then a fresh instance runs onCreate
- Explain that a ViewModel survives the change while the Activity and its views don't
- Mention SavedStateHandle or rememberSaveable for state that must survive process death too
- Give a real bug you've seen, like a network call firing twice because it started in onCreate
2.How do you keep long-running work off the main thread, and how do you cancel it?
Why they ask
ANRs and leaks are what Android apps die of in production. This checks whether you actually understand coroutines or just copy launch blocks.
How to answer
- Use viewModelScope or lifecycleScope so work is cancelled when the owner goes away
- Switch to Dispatchers.IO for disk and network, keep UI updates on Main
- Explain structured concurrency and why a GlobalScope launch is a smell
- Mention WorkManager for work that must finish even if the user leaves the app
3.How do you manage state in a Jetpack Compose screen?
Why they ask
Compose changes how UI state works, and teams migrating to it need people who won't cause endless recompositions or lost input.
How to answer
- Describe state hoisting: composables take state in and send events up
- Expose a single UI state object from the ViewModel as a StateFlow and collect it with collectAsStateWithLifecycle
- Explain remember versus rememberSaveable and when each is right
- Mention checking recomposition counts in the Layout Inspector when a screen feels slow
4.Tell me about a crash you tracked down that you couldn't reproduce at first.
Why they ask
Device fragmentation means many real bugs never show up on your emulator. They want your debugging process, not a lucky guess.
How to answer
- Start from the Crashlytics stack trace and the breakdown by device, OS version and app version
- Narrow it down: add logging or custom keys, try matching emulator images, borrow a real device
- Name the root cause plainly, such as a manufacturer killing background work
- Say what you changed so the same class of bug gets caught earlier next time
5.How would you design an offline-first screen, like a notes list that syncs to a server?
Why they ask
Real users ride subways and lose signal. This is a compact system design question that reveals whether you think in terms of a single source of truth.
How to answer
- Make Room the source of truth and have the UI observe it through a Flow
- Write locally first, queue changes, and sync with WorkManager when there's a connection
- Discuss conflict handling, such as last write wins versus server timestamps
- Ask what the product actually needs before promising real-time sync
6.How do you structure an app so it's testable?
Why they ask
Plenty of Android codebases have almost no tests. They want to know if you'll add some or make testing harder.
How to answer
- Keep business logic in ViewModels and plain Kotlin classes, not Activities
- Inject dependencies with Hilt so you can swap in fakes
- Unit test ViewModels with JUnit and a test dispatcher for coroutines
- Use Espresso or Compose UI tests sparingly for the flows that break most
7.What causes memory leaks on Android and how do you find them?
Why they ask
Leaks cause slowdowns and out-of-memory crashes that look random. This checks whether you understand object lifetimes on the platform.
How to answer
- Name the classic cause: something long-lived holding a reference to an Activity or View
- Give examples like a static field, an unregistered listener, or a callback outliving its screen
- Mention LeakCanary in debug builds and the Android Studio memory profiler
- Use the application context where you don't need an Activity
8.How do you handle a release that's causing crashes after it goes out?
Why they ask
Mobile releases can't be rolled back like a website. They want to know you respect that.
How to answer
- Use staged rollouts in the Play Console and watch crash-free rates before widening
- Halt the rollout as soon as a new crash spikes
- Ship a hotfix build, or turn off the feature with a remote config flag if one exists
- Write up what happened and add a check so it doesn't repeat
9.Tell me about a time you pushed back on a design or product request.
Why they ask
Android developers often have to explain platform limits to designers who work on an iPhone. They want someone who can say no without starting a fight.
How to answer
- Pick a real case, such as an iOS-style pattern that fights Android back navigation
- Explain how you showed the problem, maybe with a quick prototype on a device
- Describe the compromise you reached
- Say what you'd do differently next time
10.How do you make an app accessible?
Why they ask
Accessibility often gets skipped. It shows whether you think about users beyond yourself.
How to answer
- Content descriptions on meaningful images and icons, and null on decorative ones
- Large enough touch targets and support for font scaling
- Test with TalkBack and the Accessibility Scanner
- Use semantics modifiers in Compose to group and label elements
11.Why do you want to work on our app specifically?
Why they ask
They want to know if you've used the product and have opinions about it.
How to answer
- Mention that you installed it and what you actually did with it
- Name something it does well on Android and something you'd look at
- Connect it to work you've done before
Mistakes that sink good candidates
Answering every architecture question with a library name instead of explaining the idea behind it
Speaking badly about Android compared with iOS, or the reverse, to people who work on both
Submitting a take-home with no README, no error handling and no tests
Claiming Compose experience you only have from a tutorial, then freezing on state hoisting
Need more Android Developer interviews to prep for?
HeroApply applies to Android Developer jobs that match you, every day. 291 jobs are open today.