Explain the purpose of a UseCase or Interactor layer

WHAT THIS TESTS: This question tests your understanding of Clean Architecture principles, specifically the role of the domain layer. The interviewer wants to see if you can articulate why putting business logic directly in a ViewModel or Repository becomes problematic in large, complex applications. They are looking for your ability to reason about code organization, reusability, and testability at an architectural level. It's a test of moving beyond a basic MVVM implementation.

A GOOD ANSWER COVERS: A strong answer explains four key points in order. First, define a UseCase (or Interactor) as a class that contains a single, specific piece of business logic. It should have one public method, often using an invoke operator override in Kotlin. Second, explain its position: it sits in the optional domain layer, between the UI layer (ViewModels) and the data layer (Repositories). Third, describe its function: a ViewModel calls a UseCase to perform an action. The UseCase, in turn, may fetch data from one or more Repositories, apply business rules (e.g., combining data, filtering, complex calculations), and return the result to the ViewModel. Fourth, highlight the main benefits: reusability (the same logic can be used by multiple ViewModels), testability (business logic can be unit-tested in isolation), and improved separation of concerns (ViewModels handle UI state, Repositories handle data sources, UseCases handle business rules).

COMMON WRONG ANSWERS: A major red flag is describing UseCases as simple pass-throughs that just call a single repository method. This indicates the candidate doesn't understand their purpose and is just adding boilerplate. For example, a GetUserUseCase that only calls repository.getUser() adds no value. Another mistake is placing UI-related logic (like formatting strings for display) inside a UseCase. Business logic should be platform-agnostic. Finally, candidates who can't articulate why this layer is beneficial, beyond "it's good practice," show a lack of deep architectural understanding. They might say "it makes the code cleaner" without explaining how.

LIKELY FOLLOW-UPS: Expect questions like: "When is a UseCase layer overkill? Give an example." (Answer: For simple CRUD apps where the ViewModel logic is just repository.getData()). Another follow-up could be: "How would you handle a UseCase that needs to combine data from two different Repositories?" (Answer: The UseCase's constructor would take both repositories as dependencies). A third is: "Should a UseCase be a suspend function or return a Flow?" (Answer: It depends on the data source and the need. A one-shot operation is a suspend function, while subscribing to continuous updates would use a Flow).

ONE CONCRETE EXAMPLE: Imagine a feature that shows a user's "progress badge". The logic is: fetch the user's last 10 workout sessions from WorkoutRepository and their subscription status from UserRepository. If the user is a "premium" subscriber and has completed more than 5 sessions in the last 7 days, they get a "Committed" badge. This logic—combining data from two sources and applying rules—is perfect for a GetProgressBadgeUseCase. The ViewModel simply calls this UseCase and displays the resulting badge, without knowing the complex rules involved.

Source: developer.android.com/topic/architecture/domain-layer