Android Developer Interview Questions & Answers (with Model Answers)

Model Answer

I start by defining the feature's UI states and user flows, then pick an architecture such as MVVM or MVI to keep state unidirectional. I expose state from a ViewModel via StateFlow, keep the UI layer declarative with Jetpack Compose, and push business rules into use-case classes backed by a repository. I wire dependencies with Hilt so each layer is testable in isolation. Before writing UI, I sketch the data contracts so the network and persistence layers can be built in parallel.

Model Answer

I keep the main thread free of blocking work by moving I/O, parsing, and heavy computation onto Dispatchers.IO or Default with coroutines. I profile with the Android Studio profiler and StrictMode to catch disk or network calls on the UI thread. For long lists I use paging and avoid over-recomposition in Compose with stable keys and remembered state. I also watch for synchronous Binder calls and main-thread database queries, which are common ANR sources.

Model Answer

In a media app, scrolling stuttered on mid-range devices. I captured a systrace and found bitmap decoding happening on the main thread during binding. I moved decoding off-thread, added a memory and disk cache, and downsampled images to the target view size. Jank dropped from frequent dropped frames to a smooth 60fps, confirmed by the frame-timing metrics.

Model Answer

I set a sensible minSdk based on the user base and use the AndroidX libraries and Jetpack so newer APIs are back-ported where possible. I guard version-specific calls with Build.VERSION checks and lean on compat wrappers like ContextCompat. I test on a matrix of API levels via emulators and Firebase Test Lab, paying special attention to behavior changes like background execution limits and scoped storage.

Model Answer

I write unit tests for ViewModels and use cases with JUnit and mock the repository, using a test dispatcher to control coroutines. For UI I use Compose testing or Espresso for critical user journeys. I keep a fast unit layer and a thinner instrumented layer, and run them in CI on every pull request. I treat flaky tests as bugs and isolate timing dependencies with idling resources or fake clocks.

launch starts a coroutine that returns a Job and is used for fire-and-forget work, while async returns a Deferred that produces a result you retrieve with await. Use async only when you need a concurrent result, and call await inside a coroutine scope. Both respect structured concurrency, so a failure cancels the parent scope unless you use a SupervisorJob.

An Activity moves through onCreate, onStart, onResume, onPause, onStop, and onDestroy as it becomes visible or is torn down. onSaveInstanceState lets you persist transient UI state before the system may destroy the Activity, for example on rotation or low memory, so you can restore it in onCreate or onRestoreInstanceState. ViewModel survives configuration changes, so I keep durable UI state there and use the bundle only for small parcelable data.

Compose tracks state reads inside composables and re-invokes only the composables that read changed state, skipping the rest. To make this efficient, state should be stable and observable through State or StateFlow, and lists should provide stable keys. Unstable parameters or unnecessary lambdas can force extra recompositions, which the Layout Inspector and recomposition counts help you detect.

A ViewModel holds and exposes UI-related state and survives configuration changes because it is retained by the ViewModelStore tied to the lifecycle owner, not the Activity instance. This avoids reloading data on rotation. It should never hold a reference to a View or Context that can leak, and it is cleared in onCleared when the owner is permanently destroyed.

I store tokens in EncryptedSharedPreferences or the Jetpack Security library, which uses keys backed by the Android Keystore. I avoid plain SharedPreferences and never log tokens. For higher sensitivity I keep tokens in memory only and refresh them, and I gate access behind biometric or device credentials where appropriate.

Situation: a release pushed crash rate up sharply the morning after rollout. Task: I had to stabilize users fast. Action: I checked Crashlytics, traced the top crash to a null map response on a new endpoint, and used staged rollout controls to halt the release while shipping a hotfix with a null-safe parse. Result: crash-free users returned to baseline within hours and I added a contract test to catch the missing field earlier.

Situation: a designer wanted an animation that dropped frames on older devices. Task: I needed to honor the intent without harming performance. Action: I profiled the animation, showed the jank on a mid-range device, and proposed a lighter property animation that preserved the feel. Result: we shipped a version that looked polished and held 60fps, and we agreed on a device-tier checklist for future motion work.

Situation: a god-Activity blocked a new feature and was untestable. Task: I had to add the feature without a risky rewrite. Action: I carved the logic into a ViewModel and repository behind tests, migrating one screen at a time using the strangler pattern. Result: the feature shipped on time, and the extracted code gained unit coverage that prevented later regressions.

Situation: the APK was too large and rejected by users on limited data plans. Task: I needed a meaningful size cut. Action: I enabled R8 shrinking and resource optimization, switched to App Bundles for per-device delivery, and replaced bulky drawables with vectors and WebP. Result: download size dropped notably and install conversion improved on emerging-market devices.