What the Android developer interview looks like

Android developer interviews typically span 2–3 weeks and test a mix of general programming ability, Android platform knowledge, and mobile system design thinking. The balance varies — larger companies emphasize algorithms, while startups and product companies focus more on Android-specific skills and architecture. Here’s what each stage looks like.

  • Recruiter screen
    30 minutes. Background overview, Android experience highlights, salary expectations. They’re filtering for relevant mobile development experience and communication ability.
  • Technical phone screen
    45–60 minutes. Live coding in Kotlin, covering algorithms, data structures, and often an Android-specific problem (lifecycle handling, coroutines, or UI logic). Some companies use a take-home app exercise instead.
  • Onsite (virtual or in-person)
    4–5 hours across 3–4 sessions. Typically 1–2 coding rounds (Kotlin/Android), 1 mobile system design round (design an app feature or architecture), and 1 behavioral round. Some companies include a pair programming exercise.
  • Hiring manager chat
    30 minutes. Culture fit, team dynamics, career goals. Often the final signal before an offer decision is made.

Technical questions

These are the questions that come up most often in Android developer interviews. They cover Kotlin, Jetpack Compose, Android architecture, and mobile-specific system design. For each one, we’ve included what the interviewer is really testing and how to structure a strong answer.

Explain the Android Activity lifecycle and how you handle configuration changes.
Fundamental question that every Android developer should nail. They want depth, not just the method names.
Walk through the lifecycle: onCreate → onStart → onResume (foreground) → onPause → onStop (background) → onDestroy. For configuration changes (screen rotation, locale change), the default behavior destroys and recreates the Activity. To preserve state, use ViewModel (survives configuration changes but not process death), SavedStateHandle or onSaveInstanceState (survives process death, limited to small data via Bundle), and persistent storage (Room, DataStore) for data that must survive app restarts. Mention that Jetpack Compose simplifies this with rememberSaveable and that modern apps should use ViewModels to hold UI state rather than relying on Activity instance state.
How would you architect an Android app that needs to work offline and sync when connectivity returns?
Mobile system design question — they want to see you think about real-world constraints like battery, network, and data consistency.
Use a repository pattern with Room as the single source of truth. All UI reads come from the local database (via Flow or LiveData), never directly from the network. When online, sync data using WorkManager (handles retries, respects battery/network constraints). For conflict resolution, discuss strategies: last-write-wins (simple but lossy), server-wins (safest for most apps), or operational transforms (complex but necessary for collaborative features). Use a sync status table to track pending operations. Mention exponential backoff for failed syncs and how you’d handle the UI (show a “last synced at” indicator, queue user actions optimistically). Discuss pagination for initial sync of large datasets.
Explain Kotlin coroutines and how they differ from threads. How do you handle structured concurrency in Android?
They’re testing whether you understand coroutines deeply, not just that you use them.
Coroutines are lightweight, cooperative concurrency primitives that suspend rather than block. Unlike threads (OS-managed, ~1MB stack each), coroutines share threads and can run thousands concurrently with minimal overhead. Structured concurrency means coroutines are scoped to a lifecycle: viewModelScope cancels when the ViewModel clears, lifecycleScope cancels when the lifecycle owner destroys. This prevents leaks. Use Dispatchers.Main for UI updates, Dispatchers.IO for network/disk, Dispatchers.Default for CPU-heavy work. Discuss SupervisorJob (one child failure doesn’t cancel siblings), exception handling with CoroutineExceptionHandler, and why you should avoid GlobalScope (breaks structured concurrency, no automatic cancellation).
What is Jetpack Compose and how does its rendering model differ from the View system?
Increasingly critical in 2026. They want to know you understand the declarative paradigm, not just the API surface.
Jetpack Compose uses a declarative UI model: you describe what the UI should look like for a given state, and the framework handles updates. The View system is imperative: you mutate views directly. Compose uses recomposition — when state changes, only affected composables re-execute. The compiler plugin tracks which state each composable reads and skips unchanged ones (smart recomposition). Key concepts: remember (cache values across recompositions), mutableStateOf (observable state that triggers recomposition), LaunchedEffect/SideEffect (manage side effects within the composition lifecycle). Discuss performance: Compose can be faster than Views because it avoids the overhead of inflating XML and walking the view hierarchy, but poorly written composables that trigger unnecessary recompositions can be slower.
How do you handle dependency injection in an Android app, and why does it matter?
They’re evaluating your architecture skills, not just whether you know Hilt annotations.
DI provides dependencies from outside a class rather than creating them internally. Benefits: testability (swap real implementations for fakes), modularity (change implementations without touching consumers), and lifecycle management (scope instances to Activity, ViewModel, or Application). Hilt is the standard for Android: it generates Dagger components scoped to Android lifecycles. @HiltAndroidApp, @AndroidEntryPoint, @Inject, @Module, @Provides, @Singleton. Discuss scoping: @Singleton (app lifetime), @ViewModelScoped (survives config changes), @ActivityScoped. For testing, use Hilt’s testing APIs to replace modules. Mention alternatives: Koin (simpler, runtime resolution) vs. Hilt (compile-time safety, better performance). The tradeoff is boilerplate vs. safety.
An app you maintain has janky scrolling in a RecyclerView (or LazyColumn). How do you diagnose and fix it?
Practical performance question — they want your debugging methodology, not just “use DiffUtil.”
Start with profiling: use Android Studio’s CPU Profiler or Perfetto to identify where frame drops occur. Check the main thread: any work over 16ms per frame causes jank. Common causes: (1) Expensive item binding — move image loading to a background thread (Coil/Glide with proper sizing), avoid layout inflation in onBindViewHolder. (2) Missing DiffUtil/ListAdapter (or missing key in LazyColumn) — without it, the entire list rebinds on updates. (3) Nested scrolling conflicts. (4) Overdraw — use GPU overdraw debugging to find unnecessary background drawing. (5) Large images loaded at full resolution — resize before display. For Compose LazyColumn specifically: ensure items have stable keys, avoid allocations in composable functions, and use derivedStateOf for computed values that shouldn’t trigger recomposition.

Behavioral and situational questions

Android developer behavioral rounds focus on how you handle device fragmentation, performance constraints, and shipping features to millions of users. Mobile development has unique challenges, and interviewers want to see that you’ve navigated them. Use the STAR method (Situation, Task, Action, Result) for every answer.

Tell me about a time you shipped a feature that had to work across many different Android devices and screen sizes.
What they’re testing: Adaptability, attention to detail, understanding of Android fragmentation challenges.
Use STAR: describe the Situation (what feature, how many device configurations), your Task (your specific responsibility), the Action you took (testing strategy, responsive layouts, handling API-level differences), and the Result (crash-free rate, user adoption across device types). The best answers show you thought about fragmentation proactively (tested on low-end devices, used Firebase Test Lab) rather than reactively (fixed bugs after users complained).
Describe a time you had to refactor or migrate a significant part of an Android codebase.
What they’re testing: Technical leadership, planning ability, risk management.
Explain the before state (what was broken or outdated — e.g., migrating from Java to Kotlin, Views to Compose, or a legacy architecture to MVVM). Describe your migration plan: did you do it all at once or incrementally? How did you ensure the app kept working during the transition? What testing strategy did you use? Quantify the result: reduced crash rate, faster feature development, improved test coverage. Show that you managed risk (feature flags, incremental rollout) rather than doing a “big bang” rewrite.
Tell me about a time you had to optimize an app for performance or battery life.
What they’re testing: Profiling skills, user empathy, ability to balance performance with development velocity.
Describe the problem (what was the user impact — slow launch, battery drain, ANRs?) and how you measured it (profiling tools, Firebase Performance, user reports). Walk through your diagnosis and fix, emphasizing the systematic approach. Quantify the improvement: “Reduced cold start time from 3.2s to 1.1s” or “Decreased background battery usage by 60%.” The key is showing you used data to identify the problem and verify the fix, not just guessing.
Give an example of how you handled a critical bug in a production app.
What they’re testing: Crisis management, communication, root cause analysis.
Describe the severity (crash affecting X% of users, data loss, security issue), your response (how quickly you acted, how you communicated with stakeholders), and your fix (hotfix vs. staged rollout, root cause vs. bandaid). Mention what you did after the fix: postmortem, added monitoring/tests to prevent recurrence. The best answers show calm under pressure and a focus on users, not blame.

How to prepare (a 2-week plan)

Week 1: Build your foundation

  • Days 1–2: Review Android fundamentals: Activity/Fragment lifecycle, ViewModel, LiveData/StateFlow, Room, WorkManager, and Navigation component. Make sure you can explain these from memory.
  • Days 3–4: Practice Kotlin coding problems. Do 4–6 LeetCode problems daily focusing on arrays, strings, trees, and graphs. Use Kotlin idioms (extension functions, scope functions, coroutines) — interviewers notice if you write Java-style Kotlin.
  • Days 5–6: Study Jetpack Compose: recomposition, state management, side effects, lazy layouts, and navigation. If you haven’t used Compose in production, build a small practice app. Also review mobile system design: offline-first architecture, pagination, caching, push notifications.
  • Day 7: Rest. Review your notes but don’t push hard.

Week 2: Simulate and refine

  • Days 8–9: Practice mobile system design interviews. Design an offline-capable messaging app, a feed with infinite scroll and caching, or a media player with background playback. Time yourself to 45 minutes per problem.
  • Days 10–11: Prepare 4–5 STAR stories from your resume. Focus on: shipping features across diverse devices, performance optimization, major refactors, and handling production incidents.
  • Days 12–13: Research the specific company. Download their Android app, note what they do well and what you’d improve. Check their tech blog for architecture posts. Prepare 3–4 thoughtful questions about their mobile architecture and roadmap.
  • Day 14: Light review only. Do 1–2 easy problems to stay sharp and get a good night’s sleep.

Your resume is the foundation of your interview story. Make sure it sets up the right talking points. Our free scorer evaluates your resume specifically for Android developer roles — with actionable feedback on what to fix.

Score my resume →

What interviewers are actually evaluating

Android developer interviews evaluate platform expertise, software design skills, and your ability to build apps that perform well on real devices. Here’s what interviewers are scoring you on.

  • Android platform knowledge: Do you understand the Activity lifecycle, background processing constraints, memory management, and permission model? Can you work within Android’s constraints rather than fighting them?
  • Architecture and code quality: Can you structure an app using MVVM or MVI with clean separation of concerns? Do you write testable code with proper dependency injection? Interviewers are imagining maintaining your code for years.
  • Kotlin proficiency: Are you fluent in Kotlin idioms — coroutines, flows, extension functions, sealed classes, null safety? Writing Java-style Kotlin is a yellow flag in 2026.
  • Performance awareness: Do you think about frame rates, memory leaks, battery impact, and network usage? Can you profile and diagnose performance issues systematically?
  • User experience sensibility: Do you care about smooth animations, responsive layouts across screen sizes, and handling edge cases (no network, low memory, interrupted tasks) gracefully?

Mistakes that sink Android developer candidates

  1. Ignoring the Android lifecycle in your answers. If your solution doesn’t account for configuration changes, process death, or background restrictions, it won’t work on real devices. Always mention how your approach handles lifecycle events.
  2. Writing Java-style Kotlin. Using verbose patterns when Kotlin has cleaner alternatives (scope functions, data classes, sealed interfaces, coroutines instead of callbacks) signals you haven’t fully embraced the language.
  3. Not knowing Jetpack Compose. In 2026, most teams have adopted or are migrating to Compose. If you can only work with the XML View system, you’re limiting your options. At minimum, understand the declarative model and state management.
  4. Forgetting about device fragmentation. An answer that only works on Pixel devices with the latest Android version shows a narrow perspective. Mention backward compatibility, different screen densities, and manufacturer-specific quirks.
  5. Skipping testing in system design answers. When designing an app architecture, not mentioning unit tests, UI tests, or how your architecture enables testability is a missed opportunity.
  6. Not having opinions about architecture. “I just use whatever the team uses” is a weak answer. Have a thoughtful perspective on MVVM vs. MVI, XML vs. Compose, or Hilt vs. Koin — and back it up with experience.

How your resume sets up your interview

Your resume is not just a document that gets you the interview — it’s the starting point for every technical discussion. Interviewers will pick a project from your resume and drill into it for 15–20 minutes.

Before the interview, review each Android project on your resume and prepare to go deeper on any of them. For each project, ask yourself:

  • What architecture pattern did you use, and why?
  • What was the hardest technical challenge, and how did you solve it?
  • How did you handle offline support, performance, or device fragmentation?
  • What was the measurable impact (downloads, crash-free rate, user engagement)?
  • What would you architect differently if you started over?

A well-tailored resume creates natural technical conversations. If your resume says “Migrated app from Java/XML to Kotlin/Compose, reducing UI code by 40% and improving crash-free rate to 99.8%,” be ready to discuss your migration strategy, how you handled interop between Views and Compose, and how you measured success.

If your resume doesn’t set up these conversations well, our Android developer resume template can help you restructure it before the interview.

Day-of checklist

Before you walk in (or log on), run through this list:

  • Review the job description — note whether they use Compose, their minimum SDK version, and architecture preferences
  • Prepare deep dives on 2–3 Android projects from your resume with architecture decisions and impact metrics
  • Review Android lifecycle, coroutines, Jetpack Compose state management, and dependency injection
  • Practice at least one mobile system design problem end-to-end (offline-first app, feed with caching)
  • Prepare 3–4 STAR stories about shipping features, performance optimization, or handling production issues
  • Download and use the company’s Android app to understand their product
  • Test your audio, video, and screen sharing setup if the interview is virtual
  • Plan to log on or arrive 5 minutes early with water and a notepad