What the interviewer is testing

The interviewer is checking whether you understand the UI model behind the two toolkits, not whether you can list syntax differences.

A strong answer explains who is responsible for keeping the screen consistent as state changes, then shows enough judgement to recognise why Compose fits modern state-driven Android UI without pretending that existing View-based applications are badly designed.

❌ Common mistake

If they ask you to elaborate

Why Android moved toward Compose

The View system was designed around a hierarchy of UI objects that your code changes over time. That model works, and Android applications have used it successfully for years.

The friction becomes clearer as screens get more dynamic.

Imagine an order screen that can be loading, showing content, refreshing, or displaying an error. With Views, the screen might react to a new state by changing several things independently:

progressBar.isVisible = state.loading
contentGroup.isVisible = state.order != null
errorView.isVisible = state.error != null
ordersAdapter.submitList(state.items)

Your code owns that coordination. If one update is missed, the View hierarchy can temporarily represent a state the application never intended—for example, showing old content and a new error at the same time.

Compose was designed around a different model: describe the UI for the state you have now.

when (state) {
    OrderUiState.Loading -> LoadingScreen()
    is OrderUiState.Content -> OrderScreen(state)
    is OrderUiState.Error -> ErrorScreen(state.message)
}

Now the code describes the possible screens instead of spelling out every mutation required to move the old UI into the new one.

That is the practical meaning of declarative UI.

The difference is bigger than XML versus Kotlin

Compose being Kotlin-first matters because UI pieces are ordinary composable functions. They take data, emit UI, call other composables, and can use normal Kotlin control flow.

That makes reusable components, conditional UI, custom styling, and dynamic layouts easier to compose without spreading the same screen across XML, View objects, adapters, listeners, and update code.

But Kotlin is not the real architectural change. The bigger change is still the relationship between state and UI.

A well-designed View-based application can already use a ViewModel, immutable UI state, and unidirectional data flow. Compose does not invent those ideas; it makes the UI layer fit them more naturally because the screen can be rendered directly from state.

What happens when state changes

Compose does not blindly redraw the entire screen whenever one value changes.

When observed state changes, Compose can re-run the affected composable work and skip parts whose inputs have not changed. Depending on where state is read, later layout or drawing work can also be avoided.

You do not need to explain the recomposition machinery in this answer. The useful interview point is simply that Compose can update the UI from state without requiring your code to manually mutate every affected View.

Production thinking

For new Android UI, Compose is Google's recommended direction. That still does not make a rewrite of a healthy View-based application an automatic engineering win.

Views and Compose interoperate, so mature applications can adopt Compose incrementally. A team might use Compose for a new feature, migrate a screen when it is already being redesigned, and leave stable View screens alone until there is a reason to change them.

The trade-off is less about which toolkit is "better" and more about the cost of the UI model you are maintaining:

Compose also does not fix poor architecture for you. If state ownership is unclear, a ViewModel exposes several conflicting sources of truth, or side effects are mixed into rendering logic, the UI can still become difficult to reason about.

A senior engineer therefore separates two decisions: how the application owns state, and which UI toolkit renders it.

What separates a senior answer

Key takeaways

Learn more