2026 update
A few things have changed in 2026. AI is now allowed in coding rounds at Canva and Meta, detection has improved at companies that still ban it, pay has split at staff+, and the post-onsite wait got longer. Read what changed in 2026 →
What you'll be expected to do
What they're grading- Own a feature or screen end-to-end: spec, implementation, A/B test, staged Play Store rollout
- Write production Kotlin: coroutines, Flow, structured concurrency, lifecycle-aware components
- Build UI in Jetpack Compose (or maintain Views-based code if the team is mid-migration); reason about recomposition
- Partner with backend on API contracts; handle offline, process death, and configuration-change paths
- Participate in on-call for the app; debug ANRs, crashes, and performance regressions in production
- Optimise for app size, cold-start time, and battery; write the baseline profiles when needed
What does the interview loop look like?
5 rounds · 3–5 weeksMost companies follow a similar pattern for Android Engineer interviews. Total calendar time is 3–5 weeks from recruiter screen to offer.
Background, role calibration, motivation, pay expectations
Live coding a UI + data manipulation problem (parse JSON, render a list, handle a search filter, build a small ViewModel). Algorithm bar lighter than backend, Android-pattern bar heavier
Design a feature with Android-specific constraints: offline-first sync, image-loading cache with Room persistence, push notification handling, background work via WorkManager. Probing on lifecycle, process death, network resilience
A screen or feature you shipped, taken apart: the state that survived rotation and process death, the device where it looked wrong, and what the Play vitals said before and after. Common at the senior-leaning L4 bar
How you work with a backend team whose API assumes a good connection, a designer whose spec ignores the smallest supported screen, and a release you had to hold
Sample questions you should be ready for
9 of the ones that decide itRepresentative of what companies ask at this level. Every question here can be practised out loud, which is the fastest way to find out whether your answer holds up under follow-ups. Calibrd adds voice practice with coaching on every answer, and a full voice mock interview: a live round with an AI interviewer who has read the role and your CV, then an honest debrief.
- 01“Build a repository that serves a list from Room immediately, refreshes it from the network, and emits both states to the UI as a Flow. Handle the refresh failing while cached data is on screen, and cancel the refresh when the screen goes away.”
- 02“Walk me through what happens to a ViewModel during process death. How would you survive it for an in-flight network request triggered by user input?”
- 03“You've got a Compose list that's recomposing too often when scrolling. Walk me through how you'd diagnose it. Which tools, what would you look at first?”
- 04“Design sync for an app whose users edit the same records on a phone and a tablet, often offline for days. Cover the Room schema and the change log, who wins a conflict, and what happens when the sync is killed half way because the OS reclaimed the process.”
- 05“Design an image-loading library like Coil or Glide. Cover memory cache vs disk cache (Room or DiskLruCache), cancellation tied to Composable lifecycle, and what happens with a 10MB image arriving on a LazyColumn item.”
- 06“Design a push-notification handler that needs to update local data and surface a custom UI before the user opens the app. Cover Doze mode, foreground-service rules, and the silent-data-push path.”
- 07“Tell me about something that only broke on some devices or some OS versions. How did you find it without being able to reproduce it on your own phone?”
- 08“Walk me through a time you pushed back on a designer or PM on a feature you thought wouldn't work on Android (e.g. memory constraints, lifecycle, fragmentation).”
- 09“Describe an app-startup or memory optimisation you made. What was the metric, and what did you measure to prove it worked?”
These are the general ones. Paste a real posting and Calibrd predicts the questions that company asks for that exact role, then interviews you on them.
Predict my questions →Compensation benchmark
US majors · USD · medianTypical pay for Android Engineer at major US tech companies, headline numbers in USD. Typical pay in London, Berlin and Singapore is meaningfully lower, and equity varies a lot by company stage.
FAANG L4 Android total pay is typically $260–340k. Tracks the L4 SWE band closely at Google / Meta / Stripe / Snap. Google Android pays the same band at L4; Meta E4 Android is equivalent to E4 backend.
How to prep
5 tactical tipsLead behavioural answers with the STAR method: Situation, Task, Action, Result. The tips below build on that structure for this specific role.
- Drill Kotlin cold, coroutines, Flow, structured concurrency, generics, sealed classes, data classes. The coding round assumes fluency that take-home prep can't fake
- Know Jetpack Compose deeply: state, recomposition, side-effects, navigation. If the team is still on Views, know that lifecycle too (LiveData, fragments, transactions)
- Be ready to walk through a feature you've shipped: lifecycle decisions, process death handling, performance work. The deep-dive round expects specifics
- Watch the Now in Android updates from the last year for what's current, Compose has changed substantially across recent releases
- Practise 2–3 Android system designs cold: offline-first with Room, image cache, push notification handler with background work. Pattern-match from there
Where do Android Engineer candidates fail?
Spot it in a mock firstA few common mistakes that get Android Engineer candidates rejected even when they are otherwise strong. Worth catching in a mock interview before they show up in a real one.
Solving the coding problem optimally but ignoring the Android-specific parts, no lifecycle awareness, no thought about process death, no mention of where the ViewModel boundary sits.
Why it fails
At L4 the bar isn't whether you can code. It's whether you write Kotlin like someone who's shipped to production. A correct solution that doesn't think about configuration changes, or holds context references in a long-lived object, signals "generic engineer who learned Kotlin recently." The interviewer is waiting for the Android-layer commentary, not the algorithm.
Fix
After every solution, narrate the Android layer out loud: where this lives across the lifecycle, what happens during process death and config change, whether the type should hold a context (and if so, application vs activity), and where you'd reach for a coroutine scope tied to which lifecycle owner.
Designing an Android feature as if it were a web feature, perfect connectivity, no process death, the app always in foreground.
Why it fails
Mobile system design has different constraints than backend. Offline, flaky network, process death, Doze mode, background-work rules, these aren't optional considerations. Designs that ignore them read as "thinks like a backend engineer who happens to write Kotlin." The interviewer is waiting for the clarifying question about lifecycle, not for you to plough ahead with a server-first design.
Fix
Within the first five minutes of any Android system design, ask the lifecycle questions: what happens during process death, what runs in the background, what's the Doze-mode story, what data survives a config change. Then build the design around the answers.
Describing past Android work in terms of features built, no DAU, no crash-free rate, no Play Store rollout story, no ANR numbers.
Why it fails
Android interviewers calibrate against shipping experience. "I built the new feed" tells them nothing. "I built the feed used by 1.2M DAU, lifted scroll-to-engagement from 41% to 48% via the Compose recomposition fixes, and the staged Play rollout caught a startup ANR on Android 11 we patched in two days" lets them peg you. The shipping numbers separate L4 candidates from L3 candidates more than the technical depth does.
Fix
For your top 3–4 stories, attach three numbers each: scale (DAU or installs), impact (the metric that moved), and an operational detail (crash-free rate, ANR rate, Play Store rollout). Rough numbers beat no numbers.
Recommended resources
No affiliate linksBooks, courses, and tools that come up most often in Android Engineer prep.
- 01Android Developers, official docs →
Canonical reference. Re-read the Lifecycle, Background Work, and Compose state sections before any Android-heavy loop.
- 02Kotlin docs (kotlinlang.org) →
Official Kotlin reference. Skim the Coroutines and Flow chapters before a Kotlin-heavy coding round.
- 03Now in Android (Google's podcast + sample app) →
Google's reference sample app showing current best practices. Read the architecture decisions in the README, they reflect what major-tech teams converge on.
- 04Android Weekly newsletter →
Curated weekly newsletter. Subscribe and skim recent issues before interviews to pattern-match current Android engineering norms.
- 05Effective Kotlin (Marcin Moskała) →
The reference text for production-grade Kotlin. Read the chapters on coroutines, immutability, and API design before the coding round.
- 06Android vitals documentation →
The canonical reference for the crash-free and ANR budgets this guide keeps invoking — including the thresholds where Play starts punishing discoverability.
Frequently asked questions
Is this guide useful if I'm a backend / web engineer moving into Android?
Yes, the L4 / IC3 bar described here applies whether you came from web, backend, or Android directly. SWE-to-Android transitions usually have the algorithmic coding base but need to drill the Android-specific patterns (lifecycle, process death, coroutine scopes, Compose recomposition). The biggest delta is the coding round expecting fluent Kotlin idioms, not just correct code. Prep that gap first.
How long should I prep before my Android Engineer onsite?
The process takes 3–5 weeks. Add 4–6 weeks of prep if you're rusty on current Compose / Kotlin; 2–3 weeks if you're shipping Android daily. Catching up on the last year of Now in Android is the highest-leverage single move at this level.
What's the most common mistake candidates make at the Android Engineer bar?
Treating Android coding rounds as algorithm tests. The interviewer is grading whether you write Kotlin like a production Android engineer, lifecycle-aware scopes, Compose state handling, process-death survival. Algorithmic correctness without that layer reads as a backend engineer playing Android.
What if my interview process is different from what's listed?
Most variation is at the edges. Major tech companies (FAANG, scale-ups, mid-size SaaS) follow processes within 1–2 rounds of what's described. Smaller startups often run fewer rounds (3–4) but the bar at each round is similar; less-tech-mature companies sometimes skip system design or behavioural rounds entirely. Read the posting and ask the recruiter on the screening call; they'll tell you what's coming.
How does this guide compare to running a free scan?
This guide covers the general bar at L4 / IC3. The free scan reads one real posting and opens the report right here: the questions that role and company will ask, a pay benchmark matched to the level and, with your CV, the gaps an interviewer will probe and a CV score. No account or email first; the report is on screen in about a minute.
Walk in ready
Walk into your Android Engineer interview ready.
Paste your actual job and Calibrd predicts what that company asks for this role, where your CV is thin, and what it should pay. Then rehearse the round out loud with honest feedback until you're confident. Free to start.
Free to start · No card · Encrypted at rest, never used to train AI, remove anytime