Skip to content
Android App Development
All coursesPlacement Report
‹ Back to previous sectionCourse homeAll page URLs

App Architecture, MVVM and Hilt Interview Questions for Android App Development

25 App Architecture, MVVM and Hilt questions with answers for android app development roles — 6 easy, 16 medium, 3 hard.

About App Architecture, MVVM and Hilt

Google's recommended architecture uses a UI layer with ViewModels, an optional domain layer and a data layer with repositories. This topic covers MVVM, unidirectional data flow, MVI, dependency injection with Hilt, SavedStateHandle, modularisation and design decisions. Senior interviews focus heavily on these trade-offs and how you structure large codebases.

Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
3 questions free Unlock the rest in seconds
01

What is MVVM and why is it recommended for Android?

App Architecture, MVVM and HiltEasy
Save to ▾
Show answer
MVVM splits an app into Model (data and business logic), View (Activity, Fragment or composable that renders state) and ViewModel (holds UI state and handles user events). The ViewModel survives configuration changes and has no reference to views, so it is easy to unit test. The View observes state from the ViewModel through StateFlow or LiveData. This separation reduces bugs from lifecycle issues and keeps UI code thin.
02

Why should a ViewModel never hold a reference to an Activity, Fragment or View?

App Architecture, MVVM and HiltEasy
Save to ▾
Show answer
A ViewModel outlives the Activity during configuration changes. If it holds the old Activity or a view, that Activity cannot be garbage collected after rotation, causing a memory leak and possibly crashes when updating a dead view. Expose state for the UI to observe instead. If you need a Context for resources, inject the Application context or better, move that work into a repository or use resource IDs in state.
03

What is unidirectional data flow?

App Architecture, MVVM and HiltEasy
Save to ▾
Show answer
In unidirectional data flow, state flows down from the ViewModel to the UI, and events flow up from the UI to the ViewModel. The UI never changes state directly; it calls functions like onAddToCart(id), the ViewModel updates an immutable state object, and the UI re-renders. This makes state changes predictable, traceable and testable, and it is the model that Jetpack Compose is built around.
04

What is dependency injection and why use Hilt?

App Architecture, MVVM and HiltEasy
Save to ▾
Show answer
Dependency injection means classes receive their dependencies from outside rather than creating them, making code testable and loosely coupled. Hilt, built on Dagger, is Jetpack's recommended DI library. It generates code at compile time, provides standard components tied to Android lifecycles (SingletonComponent, ActivityRetainedComponent, ViewModelComponent), and integrates with ViewModels via @HiltViewModel. Errors appear at compile time rather than runtime.
05

Unit tests for a ViewModel are hard to write because it creates the repository inside itself. What do you change?

App Architecture, MVVM and HiltEasy
Save to ▾
Show answer
Constructor-inject the repository as an interface, so tests can pass a fake implementation. With Hilt, add @Inject to the constructor and bind the real implementation in a module. Also inject dispatchers rather than using Dispatchers.IO directly. Then tests create ViewModel(FakeRepository()) and control results precisely. This change improves design too, because the ViewModel no longer knows how data is created.
06

A new developer asks why we need interfaces for every repository. How do you answer?

App Architecture, MVVM and HiltEasy
Save to ▾
Show answer
Interfaces let us swap implementations, mainly fakes in tests and alternate data sources, and they define clear contracts between modules so feature modules depend on abstractions instead of concrete network code. But the rule is not absolute: if a class has one implementation and is easy to test directly, an interface adds noise. I would explain the reason with an example test and our team convention.
07

Explain the recommended layers in Android app architecture.

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
The official architecture guide recommends a UI layer (composables or views plus ViewModels as state holders), an optional domain layer (use cases that combine or reuse business logic), and a data layer (repositories that expose data and coordinate data sources like Room and Retrofit). Dependencies point inward: UI depends on domain or data, never the reverse. The repository is the single source of truth for each data type.
08

What is the difference between MVVM and MVI?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
Both separate UI from logic. MVI (Model-View-Intent) is stricter: the UI sends intents or actions, a reducer produces a single new immutable state, and side effects are handled separately. It gives one state object per screen and an easy-to-replay history. MVVM is more flexible, sometimes exposing several streams. In practice many Compose apps use MVVM with a single UiState data class, which is close to MVI.
09

What is a repository and why is it the single source of truth?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
A repository hides where data comes from and gives the rest of the app one API, such as getProducts(): Flow<List<Product>>. With an offline-first design, the repository reads from Room and refreshes from the network in the background, writing results to the database. The UI always observes the database, so it is the single source of truth. This avoids inconsistent copies of data across screens.
10

What is a use case in the domain layer and when is it worth adding?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
A use case is a class with one job, like GetDiscountedCartTotalUseCase, typically exposing operator fun invoke. It holds business logic that combines repositories or is reused by several ViewModels. It keeps ViewModels thin and logic testable. For simple apps where the ViewModel only calls one repository method, use cases add boilerplate without benefit, so the domain layer is optional in the official guidance.
11

Write a Hilt module that provides Retrofit and a repository binding.

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
@Module @InstallIn(SingletonComponent::class) object NetworkModule { @Provides @Singleton fun provideRetrofit(): Retrofit = Retrofit.Builder() .baseUrl("https://api.example.com/") .addConverterFactory(Json.asConverterFactory("application/json".toMediaType())) .build() @Provides @Singleton fun provideApi(retrofit: Retrofit): ShopApi = retrofit.create(ShopApi::class.java) } @Module @InstallIn(SingletonComponent::class) abstract class RepoModule { @Binds abstract fun bindRepo(impl: ProductRepositoryImpl): ProductRepository }
12

Write a HiltViewModel that exposes a single UiState using StateFlow.

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
data class ProductUiState( val loading: Boolean = true, val items: List<Product> = emptyList(), val error: String? = null ) @HiltViewModel class ProductViewModel @Inject constructor( private val repo: ProductRepository ) : ViewModel() { private val _state = MutableStateFlow(ProductUiState()) val state: StateFlow<ProductUiState> = _state.asStateFlow() init { refresh() } fun refresh() = viewModelScope.launch { _state.update { it.copy(loading = true, error = null) } runCatching { repo.fetchProducts() } .onSuccess { list -> _state.update { it.copy(loading = false, items = list) } } .onFailure { _state.update { it.copy(loading = false, error = "Try again") } } } }
13

What is the difference between @Provides and @Binds in Hilt?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
@Provides is used in a module function that constructs and returns an object, needed for third-party classes like Retrofit or Room that you cannot annotate with @Inject. @Binds is used on an abstract function in an abstract module to tell Hilt which implementation to use for an interface, when the implementation already has an @Inject constructor. @Binds generates less code and is slightly more efficient.
14

What is SavedStateHandle and when do you use it?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
SavedStateHandle is a key-value map available to a ViewModel that is saved into the instance state Bundle, so it survives process death as well as configuration changes. Navigation arguments are also placed in it automatically. Use it for small, essential UI state like a search query, selected filter or the ID of the item being edited. Do not put large lists in it; reload those from the repository.
15

A ViewModel has grown to 1500 lines handling many responsibilities. How would you refactor it?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
First add tests around current behaviour so refactoring is safe. Then extract business logic into use cases or domain classes, move data mapping into repositories or mappers, and split UI state into smaller, focused data classes. If the screen truly has separate areas, consider separate state holders or child ViewModels per section. Refactor in small pull requests so reviewers can follow and regressions are easy to locate.
16

Two screens show different values for the same cart count. How do you fix the architecture?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
Each screen probably fetches and caches its own copy. Create a single CartRepository, scoped as a singleton, that owns cart data in Room or an in-memory StateFlow, and have both ViewModels observe its Flow instead of keeping private copies. Mutations go through the repository so every observer updates automatically. This enforces the single source of truth and removes the need for manual refresh calls between screens.
17

You are starting a new app for a fintech startup. Which architecture and libraries would you choose and why?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
I would use Kotlin, Jetpack Compose with Material 3, MVVM with unidirectional data flow, Hilt for DI, Coroutines and Flow, Retrofit with OkHttp and kotlinx.serialization, Room for offline data, DataStore for preferences, WorkManager for background sync, and Navigation Compose. For fintech, add certificate pinning considerations, encrypted storage via Keystore, Play Integrity checks, and strong test coverage. Start modular from day one with core and feature modules.
18

How do you share data between two screens in a checkout flow?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
Options in order of preference: pass small IDs as navigation arguments and load the rest from a repository; store flow data in a repository scoped to the session; or use a ViewModel scoped to a nested navigation graph so all checkout screens share it and it is cleared when the flow ends. Avoid activity-scoped ViewModels holding everything, and avoid passing large objects through arguments.
19

Write a use case that combines cart items and a coupon into a final total.

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
class GetCartTotalUseCase @Inject constructor( private val cartRepo: CartRepository, private val couponRepo: CouponRepository ) { operator fun invoke(): Flow<Double> = combine(cartRepo.items, couponRepo.activeCoupon) { items, coupon -> val subtotal = items.sumOf { it.price * it.qty } val discount = coupon?.let { minOf(subtotal * it.percent / 100, it.maxOff) } ?: 0.0 subtotal - discount } }
20

How do you handle one-time navigation after a successful login in MVVM?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
Recommended practice is to reflect the result in state, such as isLoggedIn = true in UiState, and have the UI react with LaunchedEffect(state.isLoggedIn) to navigate, then the ViewModel marks it consumed if needed. An alternative is a Channel exposed as Flow and collected with lifecycle awareness. Avoid calling navigation directly from the ViewModel, because it should not reference NavController or views.
21

Describe a project where you improved code quality for the whole team.

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
Situation: our app had no shared conventions and reviews took days. Task: speed up reviews and reduce bugs. Action: I proposed ktlint and detekt in CI, created a module template with a convention plugin, and wrote a one-page guide on ViewModel and repository patterns with examples. Result: review time dropped by about half over two months, and new joiners shipped their first feature faster.
22

How do you mentor junior Android developers?

App Architecture, MVVM and HiltMedium
Save to ▾
Show answer
I pair on their first tasks, explain the why behind patterns rather than only giving fixes, and review pull requests with specific, kind comments plus links to docs. I give them small features end to end so they see the full flow from API to UI, and I ask them to present one learning in our weekly tech sync. I check in regularly so they feel safe asking questions early.
23

How do you structure a large Android app into modules?

App Architecture, MVVM and HiltHard
Save to ▾
Show answer
Common practice is feature modules (feature:cart, feature:profile), core modules (core:network, core:database, core:designsystem, core:model) and an app module that wires them together. Feature modules depend on core modules but not on each other; navigation is connected through the app module or route contracts. Benefits are faster incremental builds, clear ownership and enforced boundaries. Gradle convention plugins keep module build files consistent.
24

Product wants a feature flag to turn a new checkout on or off without releasing an update. How do you design it?

App Architecture, MVVM and HiltHard
Save to ▾
Show answer
Use a remote config service with defaults bundled in the app, wrapped in a FeatureFlags interface injected via Hilt. Fetch and cache values at startup with a sensible timeout, and read the flag at navigation decision points rather than deep inside UI code. Keep both checkout paths tested, log which variant users see for analytics, and plan to remove the old path and the flag after rollout.
25

How would you lead an architecture decision when senior developers disagree?

App Architecture, MVVM and HiltHard
Save to ▾
Show answer
I would write a short decision document stating the problem, two or three options with trade-offs, and constraints such as team skill and timeline, then build a small spike of the top options on a real screen. We review with measurable criteria like test effort and build time, decide, and record it as an architecture decision record. Once decided, everyone commits, and we revisit only if new facts appear.

Frequently asked questions

How important is App Architecture, MVVM and Hilt in Android App Development interviews?

Google's recommended architecture uses a UI layer with ViewModels, an optional domain layer and a data layer with repositories. This topic covers MVVM, unidirectional data flow, MVI, dependency injection with Hilt, SavedStateHandle, modularisation and design decisions. Senior interviews focus heavily on these trade-offs and how you structure large codebases.

How should I use the App Architecture, MVVM and Hilt sheet?

Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.

More question sheets

Kotlin Fundamentals questionsCoroutines and Flow questionsAndroid Components and Lifecycle questionsJetpack Compose questionsRoom, DataStore and WorkManager questionsNetworking and APIs questionsTesting, Performance and Play Store questions