Cohesyve · Practice for candidates
Going for an Android Developer role? Find out how you'd actually score.
Run an Android Developer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Android assessments are rarely a quiz about the framework. You are usually handed a small app, a screen to build, or a crash to diagnose, and scored on whether your code survives the things Android does to it — rotation, process death, a slow network, a low-end device. This page covers the formats employers actually use, what the marking scheme rewards, and how to prepare so your first timed attempt is not the one that decides an offer.
Why employers assess this role
Android has a long tail of platform behaviour that only shows up in production: lifecycle, configuration changes, background execution limits, and fragmentation across OS versions. Two candidates can both list Kotlin and Jetpack Compose, and only one of them writes a screen that still holds its state after the process is killed in the background. Employers assess up front because that difference is expensive to find after someone has joined.
What gets tested
The format
Duration
60–120 minutes
Question types
- Build a screen against a provided API
- Fix a crash or a lifecycle defect in an existing app
- Code reading and explanation
- Short written reasoning about architecture trade-offs
Levels
Entry · Mid · Senior
What you'll be asked to do
Build a screen from a spec
The most common format. A short brief, sometimes a design, and a provided endpoint. The brief usually omits what happens when the request fails, which is deliberate.
- •Build a paginated list that loads more as the user scrolls and shows a retry on failure
- •Implement a search screen with debounced input and a visible empty state
- •Build a detail screen that survives rotation without re-fetching
Survive the lifecycle
The section that separates Android developers from general mobile developers. Assessors rotate the device, background the app, and enable "Don't keep activities" to see what breaks.
- •Keep in-progress form input after a configuration change
- •Restore scroll position and selected item after process death
- •Stop a coroutine correctly when the screen goes away mid-request
Diagnose a crash or a jank problem
You are given a stack trace, a bug report, or a screen that stutters, and asked to work back to the cause. The reasoning is scored as heavily as the fix.
- •A NullPointerException occurs on a fragment view after the view is destroyed
- •A list drops frames while scrolling on a mid-range device
- •An ANR is reported at app start; identify what is blocking the main thread
Explain your architecture choices
Usually a short written section. Employers use it to separate a considered decision from a template someone copied from a sample project.
- •Why does this state live in the ViewModel rather than the composable?
- •What would change if this screen had to work fully offline?
- •Which dependency would you drop if you had to reduce the build?
Cohesyve for candidates
Practise an Android Developer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Sample tasks — and what strong looks like
Build a list screen that fetches a page of items from a provided endpoint, appends further pages on scroll, and handles failure.
MidWhat strong looks like: Loading, empty, error and end-of-list states are all visible and distinguishable, the in-flight page is not requested twice, and the fetch is cancelled with the screen scope. Weak submissions render only the success case and re-request the same page whenever the user scrolls near the bottom.
A provided screen loses the user's typed input when the device is rotated. Fix it.
EntryWhat strong looks like: Identifies that the state is held somewhere that dies with the Activity, moves it into a ViewModel with saved state so it also survives process death, and demonstrates the fix under "Don't keep activities". Weak answers lock the orientation or override the configuration change to make the symptom disappear.
Given a crash log showing a leaked view reference, find the cause and fix it.
MidWhat strong looks like: Reads the trace before touching code, recognises that the reference outlives the view lifecycle, ties the observation to the correct lifecycle owner, and explains why the leak occurred rather than adding a null check at the crash site.
Make a screen work offline: show cached data immediately, refresh when the network returns, and never present stale data as fresh.
SeniorWhat strong looks like: A single source of truth in local storage with the network as an updater, a clear rule for staleness, and a visible indication of when the data was last refreshed. Weak answers cache in memory only and lose everything the moment the process is killed.
How to prepare
- #1
Practise under a real timer, because most candidates who fail an Android task are competent but discover their pacing during the assessment itself.
- #2
Turn on "Don't keep activities" in developer options and rebuild a screen you have already written, so lifecycle correctness becomes a habit rather than an afterthought.
- #3
Rehearse the unhappy paths deliberately — no network, slow network, empty response, and a failure mid-pagination — since these are the most commonly skipped and most heavily marked.
- #4
Get fluent at reading a stack trace and naming the lifecycle boundary that was crossed, as diagnosis tasks reward navigation more than framework depth.
- #5
Practise structured concurrency until scoping and cancelling a coroutine to a screen is automatic, because leaked work is an easy and visible loss of marks.
- #6
Do one complete mock run end to end, including the written reasoning section, rather than a set of isolated exercises.
Common mistakes
Locking orientation or handling the configuration change manually to hide a state-management problem.
Holding UI state in the Activity or Fragment so it disappears on rotation and process death.
Doing disk or network work on the main thread and only noticing when the emulator hides the cost.
Leaving a coroutine or observer running after the screen it belonged to has gone.
Pulling in a large dependency graph for a task that needed two classes.
Submitting without running the app once from a cold start on a clean install.
How it's scored
| Criterion | What strong looks like |
|---|---|
| Does it work on device | The stated behaviour functions on a real run, including rotation and a cold start. This carries the most weight and is where most failures happen. |
| Lifecycle correctness | State is owned at the right level, work is scoped to something that can cancel it, and nothing leaks past the screen it belonged to. |
| Handling of failure and edge states | Loading, empty, error and offline states are all present and distinguishable, with a way for the user to recover. |
| Code structure | A clear separation between UI, state and data, with boundaries drawn for a reason rather than copied from a sample app. |
| Reasoning | Assumptions about the incomplete brief are stated, trade-offs are named, and the candidate can say what they would do with more time. |
Frequently Asked Questions
Will I be assessed in Compose or in XML layouts?
Usually whichever the employer runs, and it is normally stated in advance. Where it is left open, pick the one you are quickest in — the marking is generally about state ownership and lifecycle rather than the specific view system.
Do I need to write tests?
Write at least one meaningful test even when it is not demanded. A single unit test over the state-holder logic demonstrates more than several instrumentation tests over the obvious path, and its complete absence is noticed.
How much architecture is expected for a short task?
Enough to keep the state and the UI separable, and no more. Assembling a multi-module clean-architecture skeleton for a one-screen task usually costs marks, because it consumes the time the working behaviour needed.
What is the most common reason candidates fail?
State that does not survive a configuration change or process death. The happy path looks fine in a demo, and the assessor finds the problem within seconds of rotating the device.
How do I practise if I have never sat an Android assessment?
Sit a scored simulation before the real one. Cohesyve runs three free assessments with a full report, so you can see which criteria you actually lose marks against while nothing is at stake.
Practise another role
Cohesyve · Practice for candidates
Practise an Android Developer assessment now — free.
Three free scored assessments, a full report on every run, and a learning pathway built from what you got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for an Android Developer role? See how your applicants perform before you spend interview time.