Как ты онбордишь нового разработчика?
Что проверяют
Системность и зрелость: вы отвечаете за результат команды, а не только за свой код. Ответ «сам разберётся, у нас есть README» — красный флаг для senior-позиции.
Скелет ответа
- До выхода: доступы (репозиторий, CI, TestFlight, трекер), ноутбук с Xcode и сертификатами, назначенный наставник (buddy).
- Первый день: сборка проекта из чистого клона (если не собирается за час — это ваш техдолг), обзор архитектуры и модулей за 30 минут, где лежат гайды по коду и ревью.
- Первая неделя: маленькая изолированная задача с видимым результатом (баг, UI-правка) → первый PR → парное ревью с подробными комментариями «почему», а не «как».
- Первый месяц: задачи по нарастающей, участие в планировании, встреча 1:1 с обратной связью в обе стороны: что непонятно в проекте, что мешает.
- Метрика: время до первого смёрженного PR и до первой самостоятельной фичи.
Пример ответа
S: В команду из трёх человек вышел middle-разработчик без опыта с нашим стеком (TCA + SwiftData).
T: Нужно было вывести его на самостоятельные фичи за месяц, не роняя темп остальных.
A: За неделю до выхода собрал чек-лист доступов и обновил onboarding-doc: схема модулей, «как выглядит типичная фича», где тесты. В первый день он собрал проект за 40 минут и поправил опечатку в UI — первый PR в тот же день. Дальше давал задачи, каждая из которых затрагивала один новый слой: сначала вью, потом reducer, потом хранилище. Ревью первых пяти PR делал лично с развёрнутыми пояснениями, по пятницам — 15-минутный созвон «что было непонятно».
R: Через три недели он самостоятельно закрыл фичу, через два месяца сам онбордил следующего по тому же документу. Побочный эффект — документ выявил два места, где проект собирался только на машинах «старожилов».