На каких архитектурах писали и какие плюсы и минусы вы видите

Что проверяют

Был ли у вас опыт за пределами одного шаблона и умеете ли вы обосновать выбор. Ответ хорошо разделяет уровни: начинающий перечисляет названия, опытный говорит про цену решения на конкретном экране.

Как отвечать

Рассказывайте от своего опыта, по схеме «что использовали, что было удобно, где заболело». Рабочий набор для iOS:

• MVC в исполнении платформы: быстрый старт, но логика стягивается в контроллер, и он превращается в файл на тысячи строк, который нечем покрыть тестами;
• MVP и MVVM: логика уезжает в отдельный объект, представление становится тонким и тестируемым. MVVM хорошо ложится на реактивные связи и на SwiftUI, где экран это функция от состояния;
• VIPER: строгое разделение ролей и навигация в роутере, удобно на больших модулях и в командах, где модули пишут параллельно. Цена: много файлов и много связующего кода даже под простой экран;
• чистая архитектура со слоем сценариев: бизнес-логика не зависит от фреймворка и легко тестируется, но требует дисциплины и заметного объёма преобразований между слоями.

Для SwiftUI стоит упомянуть однонаправленный поток: источник истины наверху, представление рисует, изменения идут через явные действия.

Сильный ход это признать, что архитектура выбирается под модуль, а не под приложение целиком: экран с одной кнопкой не нуждается в пяти слоях.

Где спотыкаются

Называют архитектуру, которую видели в чужом коде, и не могут описать, кто кого создаёт и кто отвечает за переходы между экранами. Проверяется это одним вопросом про навигацию и передачу данных назад.

Ругают подход платформы вообще. Контроллер разрастается не сам по себе, а от того, что в него кладут сеть, разбор ответа и форматирование. Часть проблемы снимается выносом в отдельные объекты без смены архитектуры.

Забывают про тестируемость, ради которой слои и вводились. Если представление создаёт свои зависимости внутри себя, подменить их в тесте нечем, и разделение остаётся только на схеме в презентации.