Android Developer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
Android developer interviews usually combine Kotlin or Java fundamentals with Android-specific questions on the component lifecycle, threading, and architecture patterns like MVVM. Most include live coding, a take-home app, or a review of an app you've shipped.
Interviewers want to see that you understand what the Android framework does for you and where it can quietly cause bugs, plus the judgment to pick a reasonable architecture rather than the trendiest one.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Tell me about a time you had to fix a hard-to-reproduce crash in production.
What they're really asking: Can you debug issues you can't trigger reliably yourself?
Answer outline (STAR)
- SituationA crash reported by users on certain devices that never appeared in testing.
- TaskFind and fix the cause without a reliable repro.
- ActionRead the stack traces and device data in the crash reporter, then narrowed it to a specific OS version and screen configuration.
- ResultReproduced it on an emulator matching that config, fixed a null config check, and the crash rate dropped sharply.
Full sample answer (fictional example)
We had a crash affecting about 2 percent of sessions that never showed up in our own testing. I started with the crash reporter's stack traces and noticed they clustered on one OS version and a specific screen size. I set up an emulator matching that exact configuration and found a null pointer in a config-dependent layout path we hadn't tested on smaller screens. The fix was a null check plus a fallback layout value. After release, the crash rate for that build dropped from 2 percent to near zero within a day, confirmed through the same crash reporter dashboard.
2.Describe a time you disagreed with a designer or product manager about a feature's feasibility.
What they're really asking: Can you push back on scope with technical reasoning, not just refusal?
Answer outline (STAR)
- SituationA design that required animation and data behavior the current architecture didn't support well.
- TaskFind a version that was both feasible and close to the design intent.
- ActionPrototyped two simplified approaches and showed the tradeoffs in effort and feel.
- ResultWe shipped a version close to the original design on time, with the harder animation deferred to a later release.
Full sample answer (fictional example)
A designer wanted a screen with a complex entry animation tied to live data updates, which our current architecture handled awkwardly. Instead of just saying no, I built two quick prototypes: one close to the original animation with a performance cost, and one simplified version that kept the feel but was far cheaper to maintain. I showed both to the designer and PM with the tradeoffs explained plainly. We agreed to ship the simplified version at launch and revisit the full animation later if user feedback justified the extra investment, which it never ended up needing.
3.Tell me about optimizing an app that was slow or draining battery.
What they're really asking: Do you profile before guessing at a performance fix?
Answer outline (STAR)
- SituationUser complaints about battery drain and UI jank in a specific screen.
- TaskFind the actual cause rather than guessing at a fix.
- ActionUsed the profiler to find excessive wake locks and a layout being measured repeatedly.
- ResultFixed the wake lock usage and flattened the layout, cutting battery use and frame drops measurably.
Full sample answer (fictional example)
Users reported both battery drain and visible jank on our main feed screen. Rather than guess, I profiled the app with the Android Studio profiler during normal use. I found a wake lock that wasn't being released properly after a background sync, plus a layout that was being measured on every scroll event instead of once. I fixed the wake lock release logic and flattened the layout hierarchy to cut unnecessary measure passes. After the fix, battery usage reports from users dropped noticeably, and frame drops during scrolling went from frequent to rare in our own benchmarking.
4.Tell me about a time you had to learn a new library or architecture pattern quickly for a project.
What they're really asking: Can you get productive in unfamiliar territory under time pressure?
Answer outline (STAR)
- SituationA team migration to Jetpack Compose with a deadline already set.
- TaskBecome productive in the new tooling fast enough to contribute.
- ActionRebuilt one existing screen in Compose as a learning exercise, using docs and a teammate who'd used it before.
- ResultDelivered two new screens in Compose on schedule and wrote a short onboarding note for the rest of the team.
5.Describe a time you had to work closely with a backend team to resolve an API issue.
What they're really asking: Can you diagnose and communicate across the client-server boundary clearly?
Answer outline (STAR)
- SituationAn API returning inconsistent data that broke a list screen intermittently.
- TaskFind whose side the bug was on and get it fixed.
- ActionLogged raw responses on the client and compared them against the API's documented contract.
- ResultFound a backend pagination bug, reported it with exact repro steps, and verified the fix once deployed.
6.Tell me about a time you had to refactor legacy code with no tests.
What they're really asking: Can you make code safer to change without rewriting it all at once?
Answer outline (STAR)
- SituationAn old Activity with thousands of lines of untested logic that needed a new feature added.
- TaskAdd the feature without breaking existing behavior.
- ActionWrote characterization tests around the existing behavior first, then refactored in small verified steps.
- ResultAdded the feature safely, and the new tests caught two unrelated bugs in the old code.
Full sample answer (fictional example)
I inherited an Activity with several thousand lines of untested logic and needed to add a new feature to it. Rewriting it outright felt too risky given how much behavior was tangled together, so I wrote characterization tests first, capturing what the code actually did for its main paths before touching anything. Then I refactored in small steps, rerunning the tests after each change to confirm nothing broke. Once the code was cleaner, adding the new feature was straightforward. As a bonus, the characterization tests caught two existing bugs that had apparently gone unnoticed for a while, which I fixed separately.
7.Describe a time you had to estimate how long a feature would take and got it wrong.
What they're really asking: Can you own a bad estimate and adjust your process afterward?
Answer outline (STAR)
- SituationA feature estimated at one week that ended up taking three.
- TaskDeliver it and explain the delay honestly.
- ActionBroke down what was underestimated: an unexpected API limitation and missing edge-case handling.
- ResultDelivered the feature, and started breaking future estimates into smaller, reviewed pieces.
8.Tell me about mentoring a junior developer on your team.
What they're really asking: Can you help someone grow without just doing their work for them?
Answer outline (STAR)
- SituationA junior developer struggling with the app's architecture and coroutine usage.
- TaskHelp them become productive independently.
- ActionPaired on two features, then let them drive the third with me only reviewing, not writing.
- ResultThey shipped the next feature independently, and asked fewer basic questions over time.
9.Tell me about a time you had to choose between two libraries or approaches for the same problem.
What they're really asking: Can you make a technical decision with incomplete information and justify it?
Answer outline (STAR)
- SituationA choice between two networking libraries with different tradeoffs for the team's needs.
- TaskPick one the team could commit to without churn later.
- ActionPrototyped both against our actual use case and compared bundle size, API ergonomics and community support.
- ResultChose one, documented the reasoning, and the team didn't revisit the decision for over a year.
10.Describe a time a code review you received changed how you approached a problem.
What they're really asking: Can you take technical feedback and apply it, not just accept it politely?
Answer outline (STAR)
- SituationA reviewer flagged that my state management would cause a memory leak under certain navigation patterns.
- TaskUnderstand the issue and fix it properly, not just silence the warning.
- ActionAsked them to walk through the exact leak scenario, then rewrote it using a lifecycle-aware approach.
- ResultFixed the leak, and started applying that lifecycle-aware pattern across other screens proactively.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.Walk me through the Activity lifecycle and where you'd do setup versus cleanup work.
What they're really asking: A fundamental the framework assumes you already understand.
Answer outline
- onCreate runs once for initial setup; onStart and onResume run each time the Activity becomes visible and interactive.
- onPause and onStop handle releasing resources as the Activity goes into the background.
Full sample answer (fictional example)
onCreate runs once when the Activity is first created, so that's where I do one-time setup like inflating the layout and initializing ViewModels. onStart and onResume run each time the Activity becomes visible and then interactive, which is where I'd restart anything that needs to be active only while the user is actually looking at the screen, like a camera preview. onPause and onStop handle the reverse, releasing resources as the Activity goes into the background. One thing I always keep in mind is that configuration changes like rotation destroy and recreate the Activity by default, so I handle state explicitly with a ViewModel or saved state rather than assuming it survives.
12.What's the difference between a Fragment and an Activity, and when would you choose each?
What they're really asking: Tests whether you understand Android's navigation building blocks.
Answer outline
- An Activity is a top-level entry point with its own lifecycle, hosted by the system.
- A Fragment is a reusable piece of UI and behavior hosted inside an Activity or another Fragment.
13.Explain how you'd handle a long-running task without blocking the main thread.
What they're really asking: Tests understanding of Android's threading model and its main cause of crashes.
Answer outline
- The main thread handles UI and must stay responsive, so long work needs to move off it.
- Use Kotlin coroutines with an appropriate dispatcher, or a background executor for older code.
Full sample answer (fictional example)
The main thread in Android handles all UI rendering and user input, so anything that blocks it even briefly causes visible jank or an app-not-responding dialog. For long-running work like a network call or database query, I use Kotlin coroutines with a dispatcher like Dispatchers.IO, which moves the work off the main thread without the boilerplate of managing raw threads manually. Once the work finishes, I switch back to the main dispatcher before touching any UI element, since Views aren't thread-safe. In older codebases without coroutines, I'd use an executor or a background thread with a handler to post results back to the main thread safely.
14.What's the difference between MVVM and MVI, and why would you pick one over the other?
What they're really asking: Tests whether you understand architecture tradeoffs rather than just naming patterns.
Answer outline
- MVVM exposes state and events from a ViewModel that the UI observes and reacts to.
- MVI represents the whole screen as a single immutable state object updated through defined intents.
Full sample answer (fictional example)
In MVVM, the ViewModel exposes state and events that the UI observes and reacts to, often through multiple separate LiveData or StateFlow properties for different pieces of state. In MVI, the whole screen is represented as a single immutable state object, and all changes flow through explicitly defined intents rather than ad hoc function calls. MVI tends to make state changes more predictable and easier to test, since there's one source of truth per screen, but it adds more boilerplate for simple screens that don't need that rigor. I'd reach for MVVM on simpler screens and MVI on screens with complex, interdependent state.
15.How does Jetpack Compose's recomposition work, and how do you avoid unnecessary recompositions?
What they're really asking: Tests depth with modern Android UI, now expected on most teams.
Answer outline
- Compose recomposes functions when the state they read changes, skipping functions whose inputs didn't change.
- Unstable parameters or lambdas created inline can trigger recomposition more often than needed.
16.How would you handle offline support and data caching in an app that relies on a network API?
What they're really asking: Tests practical architecture for a very common real-world requirement.
Answer outline
- Use a local database like Room as the source of truth, synced from the network.
- The UI observes the local database so it works offline and updates once a sync completes.
17.What's the difference between a Service and a WorkManager job, and when would you use each?
What they're really asking: Tests knowledge of background execution options and their constraints.
Answer outline
- A Service runs ongoing work tied to the app's process, with foreground services for user-visible long tasks.
- WorkManager schedules deferrable background work that should survive app restarts and respects system battery constraints.
18.What's the difference between a sealed class and an enum class in Kotlin, and when would you use each?
What they're really asking: Tests Kotlin-specific knowledge beyond basic syntax.
Answer outline
- An enum class represents a fixed set of simple constant values.
- A sealed class allows each subtype to carry different data, useful for representing UI state.
19.Explain what StateFlow and LiveData are used for, and the differences between them.
What they're really asking: Tests familiarity with state-holding tools central to modern Android architecture.
Answer outline
- LiveData is lifecycle-aware and commonly used with the View system to expose UI state.
- StateFlow is a Kotlin coroutines type that always has a current value and works well with Compose.
20.How does dependency injection with Hilt or Dagger help in an Android app, and what problem does it solve?
What they're really asking: Tests understanding of why DI matters beyond following a template.
Answer outline
- It removes the need for classes to construct their own dependencies manually.
- This makes classes easier to test, since dependencies can be swapped for fakes or mocks.
21.What causes a memory leak in Android, and how would you detect one?
What they're really asking: Tests understanding of a classic Android bug class.
Answer outline
- A common cause is holding a reference to an Activity or View longer than its lifecycle allows.
- Static references, inner classes, and long-lived listeners are frequent culprits.
Full sample answer (fictional example)
A common cause is holding a reference to an Activity, Fragment, or View for longer than its lifecycle allows, which prevents the garbage collector from reclaiming it even after the screen is destroyed. This often happens through static references, inner classes that implicitly hold a reference to their outer class, or listeners registered but never unregistered. To detect leaks, I use LeakCanary during development, which flags retained objects automatically, and the Android Studio memory profiler to watch heap usage over repeated navigation through a screen. If memory keeps climbing after repeated visits to the same screen without dropping back down, that's usually a sign something isn't being released.
22.How would you write a unit test for a ViewModel that depends on a repository?
What they're really asking: Tests practical testing skill, not just theory.
Answer outline
- Inject a fake or mocked repository so the test doesn't depend on real network or database calls.
- Call the ViewModel's function and assert the resulting state matches what's expected.
Take-home or live exercise: tips
Android interviews often include a live coding round in Kotlin, a small take-home app, or a walkthrough of a feature from an app you've shipped.
- Narrate your reasoning out loud during live coding, including why you chose a particular data structure or API.
- In a take-home, keep the architecture simple and consistent rather than showcasing every pattern you know.
- When walking through a shipped app, be ready to name one thing you'd do differently with more time.
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.A user reports the app crashes only on their specific device model. How do you investigate?
What they're really asking: Tests triage approach when you can't reproduce an issue directly.
Answer outline
- Check crash reports for the exact stack trace, OS version, and device specs.
- Try an emulator or a device matching that configuration, including screen size and OS version.
Full sample answer (fictional example)
I'd start with the crash reporting tool to get the exact stack trace along with the OS version and device specs tied to that report, since device-specific crashes are often tied to a manufacturer customization or an unusual screen configuration. From there I'd try to match the environment as closely as possible, either with an emulator configured to that spec or, if available, the actual device model. If I still can't reproduce it, I'd add targeted logging around the suspected area and ship a build to get more detail from the next occurrence, rather than guessing at a fix without real evidence.
24.You're asked to add a feature that requires a breaking change to your app's data model. How do you handle it?
What they're really asking: Tests whether you protect existing users' data through a migration.
Answer outline
- Write a database migration that preserves existing user data rather than wiping it.
- Test the migration against real sample data from the old schema, not just an empty database.
Full sample answer (fictional example)
I'd write a database migration that transforms existing user data into the new schema rather than wiping and recreating the database, since losing user data for a schema change is a real trust problem. I'd test that migration against a copy of real sample data from the old schema, not just an empty database, because migrations often look fine until they hit actual edge cases like null values or old data formats. I'd also plan a rollback path in case the migration fails for some users in production, so a bad migration doesn't leave people with a broken app and no way back.
25.Your app's build time has become slow enough to frustrate the team. What do you look at?
What they're really asking: Tests awareness of build performance, which affects daily productivity.
Answer outline
- Check for unnecessary module dependencies and whether modules are split sensibly.
- Look at annotation processors and whether they can be swapped for faster alternatives like KSP.
26.You discover a security issue where sensitive data is logged in plaintext. What do you do?
What they're really asking: Tests whether you treat a security gap with urgency, not just a backlog ticket.
Answer outline
- Remove the logging immediately and check how far back the exposure goes.
- Check whether the data was also stored insecurely elsewhere, like shared preferences.
27.Your app needs to support a feature flag system for gradual feature rollout. How would you design it?
What they're really asking: Tests pragmatic architecture for controlled releases.
Answer outline
- Keep flag checks isolated so a feature can be toggled without scattering conditionals everywhere.
- Fetch flags remotely where possible, with a sensible local default if the fetch fails.
28.A critical bug is found in production just before a major release. What do you do?
What they're really asking: Tests your judgment when release pressure tempts you to cut corners.
Answer outline
- Confirm the severity and scope of the bug before deciding whether to delay.
- Look for a minimal, low-risk fix rather than a larger change under time pressure.
29.Your team is debating whether to adopt Compose fully or keep the existing View-based screens. How would you weigh in?
What they're really asking: Tests whether you can evaluate a migration decision practically, not just prefer the newer tool.
Answer outline
- Consider the cost of maintaining two UI systems during a gradual migration.
- Weigh team familiarity and the app's current stability against the long-term benefits of Compose.
30.A third-party SDK your app depends on is causing crashes after an update. How do you handle it?
What they're really asking: Tests how you manage a dependency you don't control.
Answer outline
- Check whether pinning to the previous SDK version is a safe short-term fix.
- Report the issue to the SDK's maintainers with a clear reproduction case.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Naming architecture patterns without explaining the tradeoffs between them.
Practice explaining why you'd choose MVVM or MVI for a specific situation, not just defining them.
Treating the main thread and background threading casually.
Be ready to explain exactly where and why you'd move work off the main thread.
No mention of testing when describing how you build features.
Describe how you test a ViewModel or a piece of business logic, even briefly.
Blaming the framework for bugs instead of explaining the actual root cause.
Walk through the specific mechanism behind a bug you fixed, like a lifecycle or threading issue.
How to prepare for an Android developer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: Lifecycle deep dive
Redraw the Activity and Fragment lifecycle from memory, then explain configuration change handling out loud.
Day 2: Kotlin fundamentals
Review sealed classes, coroutines, and null safety with small code snippets you write from scratch.
Day 3: Design review session
Diagram the architecture of an app you've built, labeling where state lives and how data flows.
Day 4: Timed coding drills
Solve two small coding problems in Kotlin under a timer, narrating your reasoning as you go.
Day 5: Performance and profiling
Practice describing how you'd use the Android profiler to find a jank or memory issue step by step.
Day 6: Build walkthrough
Prepare a five-minute walkthrough of a shipped feature: the problem, the architecture, and what you'd improve now.
Day 7: Testing review
Write a unit test for a small ViewModel from scratch, covering a success case and a failure case.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- Is the app built with Compose, the View system, or a mix of both, and is that changing?
- What's the team's approach to testing: unit tests, UI tests, or mostly manual QA?
- How is the app's architecture structured, and how much freedom does an engineer have to change it?
- What's the release process like, and how often does the app ship to production?
- What's a recent technical challenge the Android team worked through?
Preparation tips
- Review the Activity and Fragment lifecycle until you can draw it from memory.
- Practice explaining coroutines, threading and a basic architecture pattern out loud, as if teaching someone.
- Expect a live coding round; practice solving a small problem in Kotlin while talking through your reasoning.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for Android developer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
Once we track enough live Android developer job ads, this page also shows the skills they ask for most, counted the same way as our in-demand skills report.
Last reviewed on November 1, 2026.