С чего начать работу в новой команде
Что проверяют
Умеете ли вы встроиться, не выжигая время команды и не начиная с переписывания проекта. Вопрос часто задают на старших позициях: важно, чтобы опыт не превратился в спор с чужими решениями с первого дня.
Как отвечать
Первое это окружение и полный цикл. Доступы к репозиторию, трекеру и аккаунту разработчика, сборка проекта, запуск на устройстве, разбор зависимостей и схем, сертификаты и профили, тестовая сборка, доехавшая до раздачи. Пока сборка не прошла весь путь, любые оценки сроков ничего не стоят.
Второе это устройство приложения. Как сделана навигация, где живёт состояние, как устроен сетевой слой и модель данных, что написано на UIKit, что на SwiftUI и почему так, где границы модулей. Быстрый способ понять принятый стиль: прочитать недавние пул-реквесты и замечания на ревью.
Третье это люди и правила: кто ставит задачи, кто отвечает за дизайн, бэкенд и релиз, как принято задавать вопросы, какой ритм выпусков и что попадает в срочное исправление.
Дальше берите маленькую задачу и доводите до релиза, чтобы пройти ветку, ревью, конвейер и выкладку целиком. Замечания по архитектуре копите, но выносите позже, когда узнаете причины текущих решений.
Где спотыкаются
Начинают с предложения всё переписать на другую архитектуру. Даже если по существу правы, доверия ещё нет, а история решений неизвестна.
Молчат неделю, боясь показаться незнающими, и делают первую задачу в несколько раз дольше. Вопросы, собранные пачкой и заданные один раз в день, стоят команде минуты.
Не трогают релизный процесс, пока он не понадобился. Просроченные профили, проблема с подписью, отсутствующий доступ к аккаунту или к сервису раздачи сборок выясняются в день сдачи.