Android Developer Interview Questions (2026)
Android hiring is particularly challenging because the platform has undergone massive architectural evolution — from Java Activities with no lifecycle safety to Kotlin Coroutines, Jetpack, and Compose — meaning candidates at the same seniority level can have radically different mental models of how Android apps should be structured. A great Android developer writes idiomatic Kotlin, handles the Activity lifecycle correctly under all conditions, and builds for the enormous diversity of Android hardware.
Top 10 Android Developer interview questions
These questions assess Kotlin proficiency, lifecycle mastery, modern Jetpack architecture, concurrency, background work, and the discipline to build apps that work reliably across a fragmented device ecosystem.
Explain the Activity and Fragment lifecycle. Can you describe a real bug you encountered due to incorrect lifecycle handling?
What to look for
The Android lifecycle is one of the most common sources of crashes and UI inconsistencies. Strong candidates describe specific lifecycle states and transitions and give a real example — a crash from accessing a destroyed fragment, a memory leak from an unregistered listener in onStart, or a configuration change wiping state. They should describe how they now use ViewModel and LiveData/StateFlow to insulate state from lifecycle events.
How do Kotlin Coroutines work under the hood? How do you decide which CoroutineScope and Dispatcher to use?
What to look for
Strong candidates explain suspension as cooperative multitasking (state machine under the hood, not threads), the structured concurrency guarantee of scope, and the role of different dispatchers (Main for UI updates, IO for network/disk, Default for CPU-intensive work). They should describe how they cancel coroutines tied to lifecycle — using viewModelScope and lifecycleScope — and why using GlobalScope is problematic. Developers who "just use launch { }" without thinking about scope are creating coroutine leaks.
How do you handle ANRs? Tell me about an ANR you diagnosed in a production app and what caused it.
What to look for
ANRs (Application Not Responding) occur when the main thread is blocked for more than 5 seconds. Strong candidates describe reading the ANR trace, identifying the blocked main thread stack, and tracking the root cause — typically a synchronous network call, database operation, or lock contention on the main thread. They describe systematic offloading of work to background threads and the use of StrictMode during development to catch violations early.
Compare Flows and LiveData for state management. When would you choose one over the other in a Kotlin-first architecture?
What to look for
Strong candidates explain that StateFlow/SharedFlow are Kotlin-first, composable with operators, and integrate naturally with Compose, while LiveData is lifecycle-aware but lacks stream operators and is Java-based. They describe how stateIn() converts cold flows to lifecycle-aware hot flows for the UI layer. The best candidates express a clear preference for StateFlow in new Kotlin projects while understanding why LiveData still exists in mixed codebases. A candidate who only knows LiveData and has never used Flows is significantly behind the current Android stack.
How do you approach dependency injection in Android? What problem does Hilt solve that manual DI doesn't?
What to look for
Strong candidates describe the Android-specific DI challenges: Activity and Fragment creation is controlled by the OS, not by your code, making constructor injection impractical without a framework. They explain that Hilt handles Android component scoping (ActivityComponent, ViewModelComponent) and integrates with the Jetpack ViewModel factory. Watch for candidates who conflate DI with a ServiceLocator pattern, or who describe adding static singletons everywhere as their DI approach.
How do you reliably schedule background work that must complete even if the app is closed? What are the constraints of WorkManager?
What to look for
Strong candidates explain WorkManager's guarantee (work is executed eventually, survives app restart and device reboot), its constraint system (network, charging state), chaining and parallelism, and its limitations (not for real-time or precise scheduling). They should distinguish WorkManager from Services (foreground for user-visible work) and AlarmManager (precise timing). The Android battery optimization changes (Doze, App Standby) and their interaction with background work are important context a senior developer should understand.
Walk me through how you'd migrate a legacy View-based screen to Jetpack Compose incrementally without breaking anything.
What to look for
Strong candidates describe ComposeView for embedding Compose inside existing XML layouts, and AndroidView for the reverse (embedding legacy Views inside Compose). They describe how state sharing between the two systems works (sharing a ViewModel), and the importance of testing the seam between Compose and View-based code. Candidates who describe rewriting the screen from scratch without acknowledgment of the risk are not thinking incrementally.
How do you handle app performance issues on low-end Android devices? What optimizations have you made specifically for lower-memory or slower CPU devices?
What to look for
This question tests whether the developer thinks beyond their development device. Strong candidates describe image loading optimization (Glide/Coil with proper bitmap config), reducing overdraw, avoiding object allocation in onDraw, using ActivityManager to detect low-memory devices and adjusting behavior accordingly, and profiling specifically on low-end device emulators. Developers who've only tested on flagship Pixels will create apps that crash or lag on the majority of the Android install base.
How do you manage app size and APK/AAB optimization for Google Play distribution?
What to look for
Strong candidates describe AAB (Android App Bundle) for on-demand feature delivery and language/density splits, R8 for code shrinking and obfuscation, ProGuard rules, removing unused resources, optimizing image assets (WebP, vector drawables), and using Android Size Analyzer. They should know that app size directly affects install conversion rates — especially in markets with limited data plans. Developers who only ship APKs and haven't explored AAB have left significant optimization on the table.
Tell me about a security vulnerability you identified or fixed in an Android app. What was the risk and how did you address it?
What to look for
Android-specific vulnerabilities include exported components without permission enforcement, sensitive data logged in logcat, insecure local storage (world-readable files), improper SSL certificate validation, and insecure deep link handling. Strong candidates describe a specific finding, the potential exploit path, and the fix. Candidates who cannot name a single Android-specific security concern haven't done security-conscious development or worked in a regulated environment.
Pro tips for interviewing Android Developer candidates
Test lifecycle knowledge with a specific crash scenario
Present a real or realistic crash stack trace involving an Activity or Fragment lifecycle event and ask the candidate to diagnose it. Lifecycle bugs account for a disproportionate share of Android production crashes, and the ability to read a crash trace and trace it back to a lifecycle cause is the single most important Android-specific skill to evaluate.
Assess device fragmentation awareness
Android runs on thousands of device models across a huge range of screen sizes, RAM, CPU speeds, and OS versions. Ask candidates how they handle devices with very low RAM, how they test across screen sizes, and whether they've dealt with OEM-specific behavior differences. Developers who've only tested on a single device will create apps that work in their office and fail in the market.
Probe for Compose experience specifically if it matters to you
Jetpack Compose is now the recommended approach for new Android UI, but many experienced Android developers have primarily worked in the View system. If Compose is central to your stack, make this an explicit evaluation dimension with a dedicated coding exercise. A developer who is expert in traditional Views but has no Compose experience will need ramp-up time that may or may not be acceptable depending on your project state.
Frequently asked questions
What are the best Android developer interview questions to ask? +
The top three: (1) "Explain the Android Activity and Fragment lifecycle — describe a real bug you encountered due to a lifecycle misunderstanding" to test platform depth; (2) "How do you handle configuration changes like screen rotation without losing state?" to assess architecture knowledge; and (3) "What ANRs have you debugged in production and how did you track them down?" to reveal operational experience.
How many interview rounds for an Android developer? +
Two to three rounds is standard: a recruiter screen, a technical round focused on Kotlin, architecture (MVVM/MVI), and a live Jetpack/Compose design challenge, and optionally a code review session. Ask the candidate to walk through code from a real project — architecture decisions are far more revealing than puzzle-solving exercises.
What skills should I assess in an Android developer interview? +
Key areas: Kotlin proficiency (coroutines, flows, sealed classes), Android lifecycle and configuration change handling, Jetpack libraries (ViewModel, Room, WorkManager, Navigation), Jetpack Compose, dependency injection (Hilt/Dagger), background work management, Play Store deployment experience, and performance profiling with Android Studio Profiler.
What does a good Android developer interview process look like? +
Anchor the technical portion in a real Android challenge from your codebase. Ask the candidate to review an existing screen's architecture, identify issues, and propose improvements. This is more predictive than abstract coding exercises and surfaces how they think about maintenance and readability — essential for working in a shared codebase.
Ready to hire your next Android Developer?
Use Treegarden to build structured interview scorecards, share feedback with your team, and make faster, bias-free hiring decisions.
Request a demo