Why the Android Machine Coding Round Isn’t One Test, It’s Three

The Android machine coding round comes in three formats. Each tests something different. The first is building a small feature from a blank project. Fetching data and showing it in a list is typical. The second is extending a codebase you didn’t write. The third is reviewing or debugging someone else’s code. Most candidates prepare only for the first, often with algorithm practice. Then they stall when handed an unfamiliar codebase or a bug to find. So ask the recruiter which format you’ll get. If they can’t say, prepare for at least two. For blank-project rounds, practice writing the scaffolding from memory. For extend and debug rounds, practice reading code cold and narrating what it does before you change it. Below is a short description of each format. After it comes a scaffolding drill you can run from an empty file.

The Android machine coding round runs in three formats

Build from scratch. You get a prompt and an empty project. A typical one is to fetch data from an API and show it in a list. You also handle loading and error states. It often runs about an hour. This format leans on speed and on getting the basics right without references.

Extend an existing codebase. You get a working project and add a screen, a layer or a feature. Meta’s AI-enabled coding interview follows this shape. Evan King of Hello Interview describes it in his writeup of the round. There are phases built around one extended problem, starting with a bug in provided code. His company sells prep for it. This format tests whether you can read someone else’s structure and fit into it.

Review and debug. You get code with a problem and have to find it, explain it and fix it. Stripe describes its version in its Atlas guide to scaling engineering. The candidate and interviewer sit side by side and fix a real historical bug in an open-source project. The candidate chooses the language. This format tests how you search, not how fast you type.

Each format needs different preparation

Algorithm practice helps a little with the first format and barely at all with the others. Reading a stranger’s architecture under time pressure is its own skill. So is forming a hypothesis about a bug before touching the code. Neither comes from writing solutions on a blank file.

The format also decides how much Android depth matters. An extend or debug round usually weighs framework knowledge heavily. You need to spot lifecycle mistakes, threading errors or state that doesn’t survive rotation. A blank-project round leans more on getting a working screen up quickly.

The example: a scaffolding drill from an empty file

Many Android engineers start new screens by copying an old one. That’s fine at work. It fails when an interviewer asks you to type from scratch with no references. The weak spot is usually the scaffolding, not the logic. Here’s a minimal screen to practice writing from memory until it takes a few minutes.

sealed interface UiState {
    data object Loading : UiState
    data class Success(val items: List<Item>) : UiState
    data class Error(val message: String) : UiState
}

class ItemsViewModel(private val repo: ItemRepository) : ViewModel() {
    private val _state = MutableStateFlow<UiState>(UiState.Loading)
    val state: StateFlow<UiState> = _state

    init { load() }

    fun load() {
        viewModelScope.launch {
            _state.value = UiState.Loading
            _state.value = try {
                UiState.Success(repo.items())
            } catch (e: IOException) {
                UiState.Error("Couldn't load items")
            }
        }
    }
}

@Composable
fun ItemsScreen(viewModel: ItemsViewModel) {
    val state by viewModel.state.collectAsStateWithLifecycle()
    when (val s = state) {
        UiState.Loading -> CircularProgressIndicator()
        is UiState.Error -> Button(onClick = viewModel::load) { Text("Retry") }
        is UiState.Success -> LazyColumn {
            items(s.items) { Text(it.title) }
        }
    }
}

Type it from an empty file, run it and time yourself. Then change one thing without looking anything up. Adding pull-to-refresh is a good test. The goal is that the scaffolding stops costing you thought. That leaves your attention for the part being scored.

How to prepare for the round you’ll get

  • Ask the recruiter which format the round takes. If they can’t say, prepare for two.
  • For build rounds, run the scaffolding drill above until it’s automatic.
  • For extend rounds, open an unfamiliar open-source Android project. Add one small screen. Narrate the structure as you read it.
  • For debug rounds, check out a commit just before a real bug fix in an open-source app. Find the cause yourself, out loud, then compare with the real fix.

A related format, the live pairing round, adds a changing requirement. Our post on the Android pairing round covers it.

6 thoughts on “Why the Android Machine Coding Round Isn’t One Test, It’s Three”

Leave a Comment