Explain the purpose of a UseCase and how it fits into MVVM

WHAT THIS TESTS: This question probes whether you understand separation of concerns at scale. Basic MVVM puts too much responsibility on the ViewModel and leaves the Repository as a dumb data fetcher. The interviewer wants to see that you know where business rules belong, why ViewModels become unmaintainable when they contain complex logic, and how a domain layer solves this without turning the Repository into a god object. They are also checking if you can articulate the difference between presentation logic and business logic.

A GOOD ANSWER COVERS: First, define a UseCase or Interactor as a class that encapsulates a single business operation, such as ValidatePassword or GetActiveUserWithPermissions. Second, place it in a domain layer between the ViewModel and Repository. Third, clarify responsibilities: the ViewModel becomes a state coordinator that maps UI events to UseCase invocations and exposes UI state; the Repository remains a data source abstraction that handles where data comes from, not what it means; the UseCase owns the business rule, validation, mapping to domain models, or orchestration of multiple repositories. Fourth, list concrete benefits: logic becomes reusable across different ViewModels, unit tests run fast because UseCases are plain Kotlin with no Android framework dependencies, and ViewModels stay lean. Fifth, mention that this aligns with clean architecture and Google's recommended domain layer guidance, and note that UseCases often expose suspend functions or Flows that the ViewModel consumes.

COMMON WRONG ANSWERS: Saying a UseCase is just a wrapper that forwards calls to the Repository with no added value. Arguing that business logic belongs in the ViewModel because it already holds UI state. Claiming the Repository should contain business logic since it knows about data. Suggesting UseCases are only for massive apps and add unnecessary boilerplate in normal projects. Confusing a UseCase with a Repository pattern or with a ViewModel helper class. Insisting that adding a domain layer slows down the team without explaining the testability payoff.

LIKELY FOLLOW-UPS: How do you handle threading and coroutine scopes in UseCases? When should a UseCase call multiple repositories versus delegating to another UseCase? How does this pattern change with Jetpack Compose and unidirectional data flow? What is the cost of too many fine-grained UseCases? How do you share a UseCase between different feature modules? Would you inject a UseCase into another UseCase or prefer composition?

ONE CONCRETE EXAMPLE: Imagine a banking app with a transfer screen. The ViewModel calls a TransferFundsUseCase. That UseCase first calls a ValidateSufficientBalanceUseCase, then calls the AccountRepository to deduct funds, then calls the TransactionRepository to log the record, and finally emits a TransferResult sealed class. The ViewModel never knows about account rules or logging requirements; it only receives the result and updates a TransferUiState. If the transfer rule changes, you edit one UseCase without touching the ViewModel or Repository. This same UseCase can be reused by a scheduled transfer worker or an admin override screen without duplicating logic.

Source: developer.android.com