Вернуться в видеотекуРеальное собеседование Senior iOS разработчика. Виталий Кузьменко / Мобильный разработчик
Публичное system-design-собеседование iOS-разработчика на примере архитектуры почтового клиента. Разговор охватывает UI, данные, производительность, память, многопоточность и базовые принципы проектирования Swift-приложений.
- Направление
- Mobile
- Формат
- Техническое собеседование
- Грейд
- Senior
- Длительность
- 1 ч 4 мин
Коротко о видео
Алексей Гладков проводит публичное онлайн-собеседование с iOS-разработчиком Виталием Кузьменко, которого описание видео представляет как Senior iOS Developer. На примере почтового клиента, похожего на Spark, кандидат рассуждает о Clean Architecture, MVI, реактивности, таблицах и коллекциях, хранении данных, зависимостях и производительности. Во второй части интервью разбираются ARC и слабые ссылки, интеграция Objective-C, многопоточность GCD, Firebase-пуши, диплинки, SOLID и различия структур и классов в Swift.
Затронутые темы
Что взять на заметку
- Кандидат начинает проектирование с документации API и предлагает разделить почтовый клиент на слои Clean Architecture, выделив сетевой, доменный и presentation-слои.
- Для presentation-слоя он выбирает MVI и ReactiveKit; повторяющиеся события предлагает при необходимости не дедуплицировать на конкретной подписке, а не менять поведение всех экранов.
- Для сложных UITableView/UICollectionView кандидат описывает модели строк и секций, отдельные типы ячеек и сравнение старой и новой структур, чтобы обновлять только изменившиеся элементы.
- При лагах скролла собеседники предлагают сначала воспроизвести проблему и проверить Time Profiler; в приведённом опыте кандидата повторная инициализация шрифта в ячейках была вынесена в статическое значение.
- Для офлайн-почты кандидат предлагает локальное хранилище, а вложения держать в файловой системе с ссылками в базе, ограничением занятого места и ленивой загрузкой.
- В ответе о зависимостях кандидат отделяет интерфейсы доменного слоя от реализаций data-слоя, использует репозиторий и DI-контейнер; при смене пользователя предлагает пересоздавать контейнер сервисов.
- При обсуждении параллельности рассматриваются очереди GCD, возврат на main queue для UI, deadlock при sync на текущей очереди, race condition и priority inversion из-за захваченного общего ресурса.