What the Android Take-Home Assignment Actually Tests

An Android take-home assignment tests judgment more than code. The brief is usually small. Call an API, show a list and let the user open an item. What the reviewer grades is how you read that brief. Did you handle what any production app must handle, even though the brief didn’t mention it? Did you keep the architecture in proportion to a four-hour exercise? And can the reviewer see why you made each call? Candidates tend to fail in one of two directions. Some build exactly what’s written and nothing more. Others build a framework for a problem that needs a screen. The fix has three parts. Handle the unstated basics. Size the design to the problem. Explain your choices in a short README. Below is a complete sample README for a typical brief. After it comes what each section shows the reviewer.

Building only what’s written misses the unstated requirements

A brief that says “display a list of items” rarely lists everything a reviewer will check. They’ll rotate the device. They’ll turn off the network. They’ll leave the app and come back. None of that appears in the brief. A production app still has to handle it.

Android’s guide to saving UI states covers the basics. A ViewModel survives configuration changes like rotation. SavedStateHandle and rememberSaveable keep small pieces of UI state through process death. The guide also says none of these replace a database for data you don’t want to lose. Picture a take-home that loses its scroll position or crashes offline. It tells the reviewer you need a fully specified ticket.

Over-building fails for the opposite reason

Some candidates sense that one list screen can’t be the whole test. So they add modules, layers of abstraction and every library they know. For a single endpoint, that shows you can’t size a design to a problem. That’s the skill senior roles screen for.

Dependency injection is a common example. Android’s manual dependency injection guide recommends Hilt when possible. Its overview says manual injection gets tedious mainly in big apps with many layers. So for a small take-home, either choice is defensible. Hilt matches the official recommendation. A few hand-written constructors are simpler for one screen. What matters is that you chose on purpose and said why.

An Android take-home assignment README that shows your judgment

Say the brief is a GitHub repository browser. Fetch a user’s repositories, show them in a list and open a detail screen on tap. Here’s a README that fits a four-hour budget.

What's implemented:
- A list of a user's public repositories and a detail screen.
- Loading, empty and error states on both screens, with retry on error.

Edge cases handled:
- Rotation keeps the list and scroll position (ViewModel + rememberSaveable).
- The last successful result is cached in Room. Offline, the list shows it
  with a "showing saved data" banner.
- Process death restores the selected repository ID (SavedStateHandle).

Architecture choices:
- One module: repository, one ViewModel per screen, Compose UI.
- Hilt for DI. It's Android's recommended default and keeps test wiring simple.
- No domain layer. There's no business logic yet to put in it.

Tests:
- ViewModel tests: loading, success, error, retry.
- Repository test: falls back to the cache when the network fails.
- No Compose UI tests, to stay within the time budget.

What I'd do next:
- Paging for users with many repositories.
- UI tests for the error state.
- A cache expiry policy.

The app details are illustrative. Adapt the sections to your brief.

What each section tells the reviewer

The edge-case section proves you thought past the brief. It names rotation, offline and process death. It also says how each is handled. The reviewer doesn’t have to discover them by testing.

The architecture section shows proportion. It names one choice you made and one layer you skipped on purpose. A skipped layer with a reason reads as judgment, not as a gap.

The tests section shows you know what’s worth testing. State transitions and error fallback matter here. A big suite of getter tests wouldn’t add much.

The next-steps section shows what you’d do with more time. It also tells the reviewer that anything missing was a choice, not an oversight.

Current tooling and the size of the ask

Start from current stable versions of Gradle, Kotlin and the Jetpack libraries, unless the starter project pins them. Old versions cost nothing to avoid. A reviewer may read them as a sign you aren’t working in the current ecosystem.

Also read the size of the assignment itself. A stated budget of a few hours is normal. An unpaid assignment that expects days of work tells you something. It shows how the company values candidates’ time. Weigh it like anything else you learn in a loop. The live versions of this test are covered in our post on the Android machine coding round.