Android Developer interview questions and practice.
Builds native Android apps in Kotlin or Java, handling UI, device features, performance and Google Play releases.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Android Developer actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Structures an app around the platform's lifecycle, threading and navigation model so it stays responsive, testable and maintainable as it grows.
Keeps the app smooth and light on real, often low-end devices by measuring frame drops, startup time, memory and battery use, and fixing the causes.
Designs data flow that works with intermittent connectivity: caching, retries, conflict handling, and secure local storage.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
App architecture & platform fundamentals
Structures an app around the platform's lifecycle, threading and navigation model so it stays responsive, testable and maintainable as it grows.
- Weak
- Describes architecture as a pattern name (MVVM, Clean) without saying what problem it solved; cannot explain lifecycle events, background execution limits or why work must leave the main thread.
- Adequate
- Explains the layers of a real app, how lifecycle and configuration changes are handled, and one refactor that improved testability, but cannot quantify the effect or name what they would change.
- Strong
- Walks through a real app's architecture, the alternatives rejected and why, how it handles lifecycle, process death and background limits, and a concrete case where the structure made a large change cheap.
Performance, memory & battery
Keeps the app smooth and light on real, often low-end devices by measuring frame drops, startup time, memory and battery use, and fixing the causes.
- Weak
- Performance is described as 'it felt fine on my phone'; has never profiled; cannot name a cause of jank, a memory leak they fixed, or the app's startup time.
- Adequate
- Has used the platform profiler to find a leak or a slow screen and fixed it, but cannot give before/after numbers or describe testing on low-end devices and poor networks.
- Strong
- Gives measured before/after results (cold start, frame time, memory, battery), explains the root cause found with profiling tools, how they tested on low-end devices and 3G, and the budget or CI check that prevents regression.
Networking, offline & data sync
Designs data flow that works with intermittent connectivity: caching, retries, conflict handling, and secure local storage.
- Weak
- Assumes the network is always available; errors are handled with a generic toast; cannot explain what happens if the app is killed mid-request or how local data is protected.
- Adequate
- Implements local caching and retry for key flows and handles no-network states, but conflict resolution and sync ordering are hand-wavy and sensitive data storage is not thought through.
- Strong
- Describes an offline-first feature they built: the local store, the sync strategy, how conflicts were resolved, idempotency of requests, encryption of stored data, and the bugs found in the field that shaped it.
Release, store & crash management
Ships reliably through app store review, staged rollouts and crash monitoring, and can roll back or hotfix without breaking users on old versions.
- Weak
- Releases are ad hoc; cannot describe a staged rollout, a store rejection they handled, or the app's crash-free rate; old versions and API compatibility are not considered.
- Adequate
- Uses staged rollouts and crash reporting and has handled a store rejection, but cannot explain how they decide to halt a rollout or how they keep old app versions working against a changing backend.
- Strong
- Gives a concrete release incident: the crash spike detected, the halt/rollback decision with numbers, the hotfix path, and how they maintain backward compatibility and forced-update policy for old versions.
Platform UI, UX & accessibility
Builds interfaces that follow platform conventions, adapt to screen sizes and settings, and work with TalkBack/VoiceOver and dynamic text.
- Weak
- Implements designs pixel for pixel regardless of platform conventions; has never tested with a screen reader or large text; cannot explain why a design would feel wrong on the other platform.
- Adequate
- Follows platform guidelines, supports dynamic type and basic screen reader labels, and has adapted a design to platform norms, but has not handled complex custom controls accessibly.
- Strong
- Describes making a complex custom control accessible and tested with VoiceOver/TalkBack, handling dynamic type and rotation, and negotiating with design to respect platform conventions with user evidence.
Testing & quality on devices
Protects the app with the right mix of unit, UI and device tests, and knows how to make device tests trustworthy.
- Weak
- Testing is manual on their own device; unit tests are few or test nothing meaningful; UI tests are absent or described as too flaky to bother with.
- Adequate
- Has unit tests around business logic and some UI tests for key flows, and uses a device farm or emulator matrix, but cannot explain how they keep UI tests stable or what they chose not to automate.
- Strong
- Explains a testing strategy tailored to the app with examples of what each layer caught, how they made UI tests reliable, how they test on a device matrix, and a regression that their tests prevented.
Cross-functional delivery & ownership
Works with backend, design and product to ship features that fit the mobile constraints, negotiating API and design changes early and owning the outcome for users.
- Weak
- Builds against whatever API and design are handed over and blames them when the app is slow or awkward; does not look at crash or usage data after release.
- Adequate
- Reviews API contracts and designs before building and has requested changes, and checks crash reports after release, but improvements are reactive rather than driven by user data.
- Strong
- Describes shaping an API or design for mobile constraints with evidence (payload size, battery, offline needs), and finding a problem in analytics or reviews after release and fixing it with measured effect.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Android Developer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns a product area of the app including performance, release quality and crash-free rate; accountable in production.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: handling app lifecycle, process death and state restoration, keeping the main thread free: threading, coroutines or async patterns and designing an offline-first feature with sync and conflict resolution, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns screens or features end to end with review, including tests and handling of loading, error and offline states. | Owns a product area of the app including performance, release quality and crash-free rate; accountable in production. | Owns the app's architecture, release process and technical direction; accountable for stability and scalability across the codebase. |
| Tolerance for ambiguity | Fills small gaps sensibly and asks targeted questions on real ambiguities. | Turns a rough product idea into a working feature, resolving API and design gaps directly with the people involved. | Defines mobile approach for new product areas from business goals; makes framework and native-vs-cross-platform decisions and owns the consequences. |
| People leadership | None formally. | Mentors juniors, reviews most PRs in their area, may lead a small feature. | Technical lead for mobile engineers, drives design reviews and standards, mentors across teams. |
| Who they deal with | Own team, designer, QA, backend developers. | Product manager, designers, backend team, QA, support for user-reported issues. | Product and design leadership, backend and platform teams, security, app store relations. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Android Developer would have said them.
- Describes an offline-first feature they built: the local store, the sync strategy, how conflicts were resolved, idempotency of requests, encryption of stored data, and the bugs found in the field that shaped it.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report