Какие архитектурные подходы и паттерны использовались в проектах

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

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

Как отвечать

Назовите то, с чем работали, и обязательно почему.

• MVC от Apple: контроллер быстро собирает в себе всё, отсюда прозвище «раздутый контроллер». Годится для маленьких экранов;
• MVVM: модель представления держит состояние и логику подготовки данных, экран только отображает. Хорошо ложится на привязку данных: раньше через RxSwift, сейчас через Combine или наблюдаемые объекты SwiftUI. Главная выгода в тестируемости, модель представления проверяется без интерфейса;
• MVP: близко к MVVM, но презентер сам управляет отображением через протокол вместо привязки;
• VIPER: пять ролей на экран. Даёт строгое разделение и много файлов, оправдан в большой команде на большом проекте, на маленьком становится обузой;
• Clean Architecture: слои с правилом зависимостей внутрь, сценарии использования в центре, интерфейсы репозиториев в домене;
• Coordinator: навигация вынесена из контроллеров, экраны не знают, кто идёт следующим. Один из самых полезных приёмов на практике;
• TCA: однонаправленный поток, состояние в одном месте, побочные эффекты описаны явно. Строгий и предсказуемый, но требует принять его правила целиком;
• модуляризация: разделение на пакеты, ускоряет сборку и не даёт слоям слипнуться.

SwiftUI меняет расклад, и это стоит проговорить: экран уже является функцией от состояния, поэтому отдельная модель представления нужна не всегда. Для простого экрана хватает состояния прямо во вью, а слой добавляют, когда появляется логика, которую хочется тестировать отдельно.

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

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

Перечисляют аббревиатуры без объяснения выбора.

Называют MVVM, но держат сетевые запросы прямо во вью.

Считают VIPER универсально лучшим.

Не могут назвать ни одного минуса выбранного подхода.