Поведенческое интервью

Интервьюер проверяет, умеете ли вы коротко и по делу рассказать о себе и почему подходите на эту роль. Уложитесь в одну-две минуты: настоящее (роль, стек, чем заняты сейчас), прошлое (как к этому пришли, один результат), будущее (почему следующим шагом должна стать именно эта вакансия). Подстройтесь под вакансию: начните с того, что нужно по описанию; учёбу, хобби и пересказ резюме пропустите Один результат с цифрой: ускоренный холодный старт, снижение доли крашей Красные флаги: пересказ резюме по местам работы, монолог на пять минут, ни слова о том, чего вы хотите дальше Пример Настоящее: «Я iOS-разработчик, опыт четыре года. Работаю над банковским приложением на Swift, наполовину UIKit, наполовину SwiftUI, и отвечаю за экраны карт и платежей.» Прошлое: «После фриланс-приложений пришёл в продуктовую команду и перевёл наш сетевой слой на async/await.» Будущее: «Хочу работать с модульной кодовой базой, где SwiftUI служит основным инструментом, как её описывает ваша команда.»

Интервьюер проверяет мотивацию и то, не уйдёте ли вы от них по той же причине. Назовите одну честную причину как движение к чему-то (задачи сложнее, продукт крупнее, команда сильнее), а затем две конкретные вещи, которые привлекают вас в этой компании. К чему-то, а не от чего-то: «я перерос свои задачи» или «хочу больше масштаба», но никогда «у меня бесполезный руководитель» Конкретно про них: их продукт, стек, статья в блоге или доклад; «отличная компания» не говорит ничего Сокращение или короткий срок работы: скажите прямо одной фразой и переходите дальше Красные флаги: критика своего работодателя, «только ради денег», незнание компании Пример «Я многому научился на нашем банковском приложении, но оно уходит в поддержку, и новых функций почти нет. Ваше приложение сделано в первую очередь на SwiftUI и быстро растёт, а я хочу работать именно над таким продуктом.»

Интервьюер проверяет масштаб того, что вы делали, и ваш личный вклад в работу команды. Отвечайте по STAR: ситуация и проблема, ваша задача, ваши действия и их причины, измеримый результат. «Я» для своей части: «мы» только о работе команды; оценивают то, что сделали вы Одно решение подробно: ждите вопроса «почему так, а не X?» Результат в цифрах: crash-free users, время загрузки, конверсия, обращения Красные флаги: технологии без проблемы за ними, архитектура, которую вы не можете объяснить, успех команды, выданный за свой Пример Ситуация: клиенты постоянно звонили в поддержку узнать, где их заказ Задача: я сделал отслеживание заказа на экране блокировки Действия: Live Activity, которая обновляется пушами, с моделями, общими с приложением через Swift-пакет Результат: звонков «где мой заказ» за два месяца стало примерно на четверть меньше

Интервьюер проверяет, насколько трезво и честно вы себя оцениваете. Назовите две-три сильные стороны, важные для этой роли, каждую с фактом, и одну настоящую слабую сторону, которая не мешает работе, вместе с тем, что вы с ней уже делаете. Сильные стороны с доказательством: факт из работы, а не прилагательные вроде «ответственный» Настоящая слабость: трудно высказываться на больших встречах, привычка поздно просить о помощи, мало опыта в области, которая для роли не главная Что вы с ней делаете: привычка, которая уже работает, чтобы ответ заканчивался прогрессом Красные флаги: «слабых сторон нет», скрытое хвастовство («я перфекционист») Пример Сильная сторона: «Память и потоки. Я нашёл retain cycle, из-за которого целый экран оставался в памяти после закрытия.» Слабая сторона: «Я избегал выступлений. С прошлого года показываю демо своей работы на каждом командном обзоре, и становится легче.»

Рекрутер проверяет, вписываетесь ли вы в бюджет и знаете ли свою цену на рынке. Назовите изученную вилку для вашего уровня и рынка, поясните, до или после налогов и в месяц или в год, и добавьте, что итог зависит от задач и всего предложения. Сначала исследование: обзоры зарплат, похожие вакансии, знакомые, которые недавно меняли работу Честная нижняя граница: офферы приходят близко к ней, так что назовите число, которое вас устроит Знайте принятую форму: за рубежом обычно сумма до налогов (gross) в год, в русскоязычных компаниях часто на руки в месяц Спросите их вилку первыми: на этом этапе это нормально, и всё чаще работодатели обязаны называть её заранее Красные флаги: «сколько предложите», цифра с потолка, текущая зарплата, которую вы назвали без вопроса Пример Зарубежная компания: «Для middle iOS-разработчика я ориентируюсь на X–Y gross в год. А какая у вас вилка?» Русскоязычный рынок: «Я ориентируюсь на X–Y в месяц на руки. А какая у вас вилка?»

Интервьюер проверяет ваш интерес и то, что для вас важно; «вопросов нет» звучит как равнодушие. Подготовьте три-четыре вопроса о самой работе (команда, как выпускают релизы, что значит успех на этой роли) и выберите те, что подходят человеку перед вами. Работа: «Чем я буду заниматься первые три месяца?», «Кто делает код-ревью и сколько человек в команде?» Как выпускают: частота релизов, тестирование, дежурства, техдолг и кто решает, когда им заниматься Успех: «Как через полгода вы поймёте, что я хорошо справляюсь?» По собеседнику: процессы у тимлида, планы продукта у руководителя, условия у рекрутера Красные флаги: нет ни одного вопроса, вопросы об отпуске на техническом интервью Пример «Какая у вас минимальная версия iOS и как быстро вы переходите на новые SDK?» «Какая часть приложения на SwiftUI и куда вы движетесь?»

Интервьюер проверяет, как вы отлаживаете: как сужаете проблему, какими инструментами пользуетесь и исправляете ли причину, а не симптом. Рассказывайте по STAR и больше всего времени отдайте действиям: гипотезам, тому, как вы их проверяли, и тому, что не даст багу вернуться. Почему было сложно: только на некоторых устройствах, только под нагрузкой, нет стектрейса; скажите это сразу Поиск по шагам: краш-репорты и логи, профайлер, минимальное воспроизведение, git bisect, ложные следы, которые вы отбросили Корневая причина одной фразой: чтобы интервьюер мог уследить за мыслью Профилактика: тест, алерт или правило линтера, добавленные после Красные флаги: банальная опечатка, «не помню», баг, который нашёл коллега, исправление, которое вы не можете объяснить Пример Ситуация: приложение само закрывалось на старых iPhone с 2 ГБ памяти, а Crashlytics ничего не показывал Задача: выяснить почему Действия: отчёты JetsamEvent в аналитике устройства показали, что система убивала приложение из-за нехватки памяти. Allocations в Instruments показал, что выбор фото держит 20 полноразмерных изображений сразу, около 900 МБ. Я перешёл на даунсэмплинг через ImageIO (CGImageSourceCreateThumbnailAtIndex) до размера на экране Результат: пик памяти упал примерно до 150 МБ, принудительные закрытия прекратились, а старый iPhone теперь входит в нашу проверку релиза

Интервьюер проверяет ответственность: признаёте ли вы ошибку, быстро ли ограничиваете ущерб и меняете ли процесс, чтобы она не повторилась. Выберите настоящую ошибку с ограниченными последствиями, расскажите по STAR, а последнюю часть отдайте тому, что изменили. Признайте прямо: «я выкатил», а не «так получилось»; не вините QA или ревьюера, который пропустил Сначала ограничьте ущерб: кому и как быстро вы сообщили, откат или хотфикс, сколько пользователей задело Исправьте систему: тест, проверка в CI, правило ревью или алерт; «буду внимательнее» исправлением не считается Красные флаги: «я не ошибаюсь», история, где виноват кто-то другой, катастрофа без выводов, мелкая опечатка, выбранная, чтобы не рисковать Пример «Я сделал force unwrap поля, которое наш API иногда не присылает. После релиза около 1% сессий падало на экране профиля. Я поставил phased release на паузу, написал команде в релизный канал и за день выпустил исправление, где поле декодируется как опциональное. После этого мы включили правило force_unwrapping в SwiftLint и добавили тесты декодирования на реальных ответах API.»

Интервьюер проверяет, как вы справляетесь с блокером, который от вас не зависит, под давлением срока: сохраняете спокойствие, держите в курсе команду и ревьюера и исправляете процесс. Расскажите по STAR: отказ и что было на кону, что вы сделали, как быстро всё решилось и что изменилось. Прочитайте, прежде чем реагировать: указанный пункт гайдлайнов, заметки и скриншоты ревьюера; многие отказы оказываются недоразумением или недостающей деталью Предупредите заранее: продакт и маркетинг узнают о риске для даты от вас в течение часа, вместе с оценкой Один путь, один ответственный: ответить в App Store Connect, исправить и отправить заново или подать апелляцию, решается быстро Предотвратите следующий: чеклист перед отправкой и рабочий демо-аккаунт в заметках для ревью Красные флаги: «Apple несправедлива», гневный ответ ревьюеру, команда узнаёт об отказе в день запуска Пример «За два дня до кампании обновление отклонили по пункту 2.1: ревьюер не смог войти, потому что демо-аккаунту нужен был код из SMS. Я сообщил продакту в течение часа. Команда бэкенда выдала демо-номеру фиксированный код, я ответил ревьюеру с шагами, и на следующий день сборку одобрили. Теперь в нашем чеклисте есть вход под демо-аккаунтом в день отправки.»

Интервьюер проверяет, умеете ли вы не соглашаться, не портя рабочие отношения. Возьмите настоящее рабочее разногласие, часто техническое или на код-ревью, и покажите, как вы перевели его от мнений к общим критериям, что решили и как работали вместе после. Говорите рано и напрямую: длинную ветку комментариев переведите в короткий созвон или разговор один на один Сначала поймите их позицию: честно перескажите её, прежде чем доказывать свою Сначала критерии, потом решение: цифры, договорённости команды, быстрый прототип; если согласия всё равно нет, решает владелец решения, а вы его принимаете Проиграть нормально: история, где вы приняли чужой подход, показывает зрелость Красные флаги: «у меня не было конфликтов», коллега в роли злодея, сразу к руководителю, победа ценой отношений Пример «Коллега раз за разом отклонял мои PR в сетевом слое, потому что я использовал async/await в модуле, написанном на Combine. Вместо ответов по пунктам я предложил поговорить. Настоящее его опасение касалось отмены запросов на лету. Я показал, что отмена Task отменяет и запрос URLSession, и мы договорились: новый код запросов пишем на async/await, а Combine остаётся там, где значения идут потоком. После этого ревью пошли быстрее.»

Интервьюер проверяет, реалистично ли вы планируете и поднимаете ли риск сразу, как только его видите, а не в день дедлайна. Расскажите, как вы декомпозируете и оцениваете работу, а затем историю, где вы заметили срыв срока заранее, вовремя предупредили и предложили варианты. Декомпозиция: куски от половины дня до двух дней, включая тесты, ревью, QA и релиз, о которых часто забывают Неизвестное отдельно: ограниченный по времени спайк на всё, что вы ещё не делали; называйте диапазон, а не одно число Сравнение с прошлым: сколько на самом деле заняли похожие задачи Если срок срывается: скажите тимлиду или продакту в тот же день, с вариантами: урезать объём, сдвинуть дату, добавить людей; никогда не сидите молча по ночам в надежде успеть Красные флаги: «я всегда успеваю», оценка без декомпозиции, сообщение о срыве в день релиза Пример «У маркетинга была жёсткая дата запуска, и в моём плане был заложен день на App Review. На третий день всплыл пограничный случай с покупками через Family Sharing. Я сразу сказал продакту и предложил оставить Family Sharing на следующее обновление. Мы отправили сборку за два дня до даты и прошли ревью с первого раза.»

Интервьюер проверяет, думаете ли вы о продукте и умеете ли возражать аргументами, а не молча делать или отказываться. Покажите, что вы спросили о цели, принесли доказательства цены, предложили альтернативу, которая ведёт к той же цели, и приняли итоговое решение. Сначала спросите о цели: требование часто лишь один из путей к ней, и есть путь дешевле Принесите доказательства: запись экрана на реальном устройстве, замер, гайдлайн платформы, оценку каждого варианта Предложите альтернативу: «X к пятнице не успеем, но Y даст большую часть результата» Уважайте решение: когда владелец продукта решил, видя все компромиссы, вы делаете это хорошо Красные флаги: «я делаю, что скажут», отказ без альтернативы, решать вопрос через голову продакта Пример «В редизайне системный navigation bar заменили собственной шапкой, и это сломало жест свайпа назад и порядок чтения VoiceOver. Я показал обе проблемы на устройстве и предложил вместо этого стилизовать нативный navigation bar. Внешний вид мы сохранили, а системное поведение вернули бесплатно.»

Интервьюер проверяет, умеете ли вы слышать критику, не защищаясь, и сказать коллеге о проблеме, не задев его. Расскажите, как вы делаете и то и другое, и подкрепите историей, где обратная связь изменила вашу работу. Принимать: дослушать, попросить конкретный пример, поблагодарить и позже вернуться с тем, что вы изменили Давать: наедине, вскоре после события, о поведении и его последствиях, а не о человеке («в этом PR не было тестов, и баг дошёл до QA»), с предложением На код-ревью: объяснять почему, отделять блокирующие замечания от мелочей, отмечать хорошее Красные флаги: «негативной обратной связи у меня не бывает», спор с каждым пунктом, обратная связь только через руководителя, резкие публичные комментарии Пример «Коллега сказал, что мои комментарии на ревью звучат как приказы. Я перечитал несколько и согласился. Теперь пишу их вопросом с причиной („это замыкание сильно захватывает self, может, здесь [weak self]?“) и помечаю мелочи как необязательные. Тон наших ревью изменился за несколько недель.»

Интервьюер проверяет, учитесь ли вы постоянно и планируете ли изменения платформы до того, как они станут авралом. Опишите годовой цикл: что смотрите в июне, как тестируете на бетах летом, как планируете обязательную работу с продуктовой командой, и один релиз, который вы так подготовили. Июнь: сессии WWDC, которые касаются вашего приложения, распределены по команде, по каждой короткое письменное резюме Лето: приложение собирается в бете Xcode и запускается на тестовом устройстве с бетой iOS; список того, что ломается, новых предупреждений и deprecated API План с продуктом: обязательная работа получает слот до сентября (новый SDK становится обязательным для загрузок следующей весной); новые возможности вроде виджетов или App Intents предлагаются как варианты Политика deployment target: например, две последние мажорные версии, сверенные с аналитикой Красные флаги: узнавать об изменениях из сентябрьских отзывов, внедрять все новые API сразу, «я не слежу за WWDC» Пример «Когда в iOS 26 появился Liquid Glass, мы в июне собрали приложение в бете Xcode 26 и увидели, что наш собственный таб-бар и шапки конфликтуют с новым видом. Я составил список экранов со скриншотами, дизайнеры за лето обновили собственные компоненты, и адаптированную версию мы выпустили в ту же неделю, когда вышла iOS 26.»

Интервьюер проверяет, умножаете ли вы результат команды, а не только свой. Расскажите конкретную историю: в чём был затык у человека или команды, что вы делали регулярно (парное программирование, ревью, задачи с растущей сложностью, общие практики) и какой результат можно показать. Начните с его пробела: спросите и понаблюдайте, что на самом деле мешает; общая лекция не помогает Учите на реальной работе: сделайте задачу вместе, затем дайте похожую сделать самому; на ревью объясняйте и давайте ссылки, а не переписывайте код Растите самостоятельность: задачи чуть выше уровня и место для мелких ошибок там, где они дёшевы Масштабируйте на команду: чеклист, правило линтера, шаблон PR, короткий внутренний доклад, записанные решения Результат: человек сам выпустил фичу, раундов ревью стало меньше, онбординг сократился Красные флаги: «я просто сам исправляю их код», менторство как раздача указаний, нет примера Пример «Экраны джуниора текли по памяти: замыкания захватывали self, и view controller никогда не освобождались. Я показал ей, как найти цикл через Memory Graph Debugger, и мы добавили проверку утечек в шаблон PR. Через два месяца уже она указывала на циклы в чужих ревью. Для команды я провёл часовую сессию про ARC, которая теперь входит в онбординг.»

Интервьюер проверяет, говорите ли вы на языке бизнеса и умеете ли расставлять приоритеты, вместо того чтобы просить всё переписать. Переведите долг в цену, которую бизнес уже ощущает (медленные фичи, инциденты, потерянные пользователи), предложите небольшой измеримый план и отчитайтесь о результате. Измерьте боль: время на типичную фичу, баги за релиз в этой части, инциденты, время сборки, умноженное на команду Приоритет по цене: важен долг в коде, который часто меняется; старый стабильный код может оставаться некрасивым Понемногу и постоянно: фиксированная доля каждого спринта или чистка вместе со следующей фичей в этой части, а не заморозка на три месяца Покажите эффект: цифры до и после облегчают следующую просьбу Красные флаги: «код некрасивый» как аргумент, просьба переписать всё, работа, спрятанная в оценки фич Пример «Старый сетевой слой на Objective-C стоял примерно за третью наших краш-репортов, а каждый новый эндпоинт отнимал день шаблонного кода. Я показал продакту обе цифры и предложил заменять слой за протоколом, по одной фиче, вместе с плановой работой. Через квартал crash-free sessions выросли с 99,5% до 99,8%, а новый эндпоинт стал занимать час.»

Интервьюер проверяет, умеете ли вы вести долгое изменение через людей, а не только писать код. Покажите, как обосновали его для бизнеса, начали с малого, задали общие правила, распространили знания и не остановили выпуск фич, с результатом в цифрах. Причина, которую примет бизнес: экраны делаются быстрее, меньше багов вёрстки, минимальная версия iOS наконец делает это практичным Сначала пилот: один новый экран с низким риском; замерьте, сколько времени он занял и сколько в нём было багов Общие правила: как встраивается SwiftUI (UIHostingController), как устроены состояние и навигация, что пока остаётся на UIKit (сложные списки, собственные переходы) Распространите знания: парное программирование, эталонный экран, ревью от того, кто уже это делал, короткая внутренняя сессия Без заморозки: новые экраны на SwiftUI, старые переписываются, только когда их затрагивает фича Красные флаги: переписать всё разом, «я просто начал писать на SwiftUI, и остальные подтянулись», нет плана для экранов, которым стоит остаться на UIKit Пример «Когда минимальная версия у нас дошла до iOS 16, я предложил делать новые экраны на SwiftUI. Первыми я сделал настройки, написал двухстраничный гайд по состоянию и навигации и с каждым разработчиком в паре сделал его первый экран. Через год около 60% экранов были на SwiftUI, новые экраны занимали примерно на треть меньше времени, а две сложные ленты осознанно остались на UIKit.»