Android interviews focus on Kotlin idioms, coroutines, and the platform lifecycle — most senior questions are really asking whether you understand that your process can be killed at any moment. Below are the questions asked most often, each with a model answer. Senior: architecture, trade-offs, mentoring, and decision-making.
By the boundary that changes together and by build time. A feature module that can be built and tested without the rest pays for itself in compile speed and in making the dependency direction explicit. Splitting by layer — one module of all view models — usually produces modules that always change together, which is the cost without the benefit.
Make the local database the source of truth and the network a synchroniser, so the UI never waits on connectivity. Then the hard part is conflicts and ordering: a queue of pending operations that survives a restart, idempotent requests so a retry is safe, and an explicit rule for what wins when both sides changed. Bolting this on later means rewriting the data layer.
Start with the crash grouping — which devices and which screens, since low-memory devices surface what others tolerate. Bitmaps are the usual answer: a full-resolution image decoded for a thumbnail costs megabytes each. LeakCanary in a debug build names the retained objects, and the memory profiler shows whether the heap grows and never returns.
WorkManager, because it persists the request and honours the constraints the system enforces — network, charging, Doze. A coroutine in a scope dies with the process, and an alarm is not a scheduler. The work itself has to be idempotent, since the system will retry it, and a task that is not may run twice.
Incrementally, in both directions: Compose inside a fragment, a ComposeView in an existing layout, and the interop that lets one screen be converted at a time. Convert a screen when it needs work anyway rather than as a project, because a rewrite with no product change is the first thing cut when priorities move.
Business logic and state reduction as plain unit tests — they run in seconds and are the ones that catch real defects. Repository and database behaviour with an in-memory database, since ORM assumptions are exactly what mocks hide. Then a handful of instrumentation tests over the flows that must never break, accepting they are slow enough that a big suite of them stops being run.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Android (Kotlin) interview →