Расскажите про архитектуру MVVM, кто за что отвечает и как устроены связи между компонентами
Что проверяют
Понимаете ли вы, зачем разделение вообще нужно, и знаете ли направление связей. Главный признак понимания это ответ на вопрос «почему ViewModel не должна знать про View».
Как отвечать
Три слоя и одно правило про направление зависимостей.
Model это данные и бизнес-правила: репозитории, работа с сетью и базой, доменные сущности. Про экран не знает ничего.
View: активити, фрагмент или Compose-функция. Только отображает состояние и передаёт события пользователя. Логики в ней нет.
ViewModel: держит состояние экрана и обрабатывает события. Берёт данные у Model, превращает их в то, что рисует View.
Связи однонаправленные: View подписывается на состояние ViewModel и шлёт ей события, ViewModel обращается к Model. Обратных ссылок нет: ViewModel не хранит ссылку на View, иначе при повороте экрана останется ссылка на уничтоженную активити, а это утечка.
В Android это выражается конкретно: ViewModel переживает пересоздание активити, состояние отдаётся через StateFlow или LiveData, а разовые события (навигация, показ ошибки) через Channel или SharedFlow, потому что состояние переиграется при повороте, а событие должно случиться один раз.
Что это даёт: ViewModel тестируется без Android-фреймворка, состояние переживает поворот, а логика не размазана по фрагментам.
Где спотыкаются
Передают Context или View в конструктор ViewModel. Для контекста приложения есть AndroidViewModel, а ссылка на активити это готовая утечка.
Делают ViewModel «толстой», складывая туда сетевые запросы напрямую вместо репозитория. Тогда слой Model исчезает, и тестировать нечего.
Путают MVVM с MVP: в MVP презентер знает про View через интерфейс и сам её обновляет, в MVVM View сама подписывается на состояние.
Не отличают состояние от события и показывают одну и ту же ошибку заново после каждого поворота экрана.