Android Architecture Interview Questions

There's rarely one right architecture answer. Interviewers listen for whether you know the options, can explain trade-offs, and can tie choices to a real context: team size, app complexity, offline needs. Use "it depends, and here's on what" well.

Layers and data flow

Describe your recommended Android architecture.

UI layer (stateless composables plus ViewModels exposing one immutable UiState), optional domain layer for reusable business logic, and a data layer of repositories hiding data sources. Unidirectional data flow, DI and lifecycle-aware collection. Then mention where you'd simplify for small apps.

What is unidirectional data flow, and why does it matter?

State flows down, and events flow up to the state owner. It creates a single source of truth, predictable updates and easy testing.

Where should business logic live?

Not in composables. Screen-specific presentation logic goes in ViewModels, reusable business rules in use cases or domain classes, and data policies in repositories.

Patterns

MVVM vs MVI: which would you choose?

MVVM with a single state for most screens, and MVI-style intents and reducers for complex, highly interactive screens where traceability matters. Consistency across the team matters more than the label.

How do you handle one-off events like navigation or snackbars?

Preferably as state that the UI consumes and then clears. Alternatively a buffered Channel collected lifecycle-aware. Explain the risk of lost events with a SharedFlow without replay.

Do you always use use cases?

No, only where logic is reused, complex or combines repositories. Pass-through use cases add files without value.

Data

What is a single source of truth?

One owner for each piece of data, often the local database for offline-capable data. The network updates it, and the UI observes it.

How would you design offline support?

Room as the source of truth, local-first writes with pending flags, WorkManager sync with backoff, and a conflict policy. See Offline-First.

How do you handle errors across layers?

Classify errors at the data boundary into typed errors, then map them to UI messages and recovery actions in the ViewModel. Pick one convention: exceptions or Result.

Scaling

When would you modularize, and how?

When build times, ownership or boundaries hurt. Feature modules over core modules, convention plugins, implementation by default, and no feature-to-feature dependencies. See Modularization Strategies.

How does DI help architecture?

It decouples creation from use, enables fakes in tests, and manages lifetimes (scopes). Hilt adds compile-time validation for Android.

How would you migrate a legacy app?

Incrementally: characterization tests, extract ViewModels and repositories, coroutines instead of callbacks, Compose for new screens, and the strangler pattern rather than a rewrite.

Showing judgement

Frequently asked questions

Conclusion

Strong architecture answers explain layers, data flow, sources of truth and boundaries, and always tie choices to context and trade-offs. Practise sketching the reference architecture and adapting it to small and large scenarios.

Next step: practise async questions with Coroutines and Flow Interview Questions.