Разработка для операционной системы Ай-Оу-Эс (iOS) редко срывается из-за одного слабого ответа на собеседовании. По разговору о задачах, коде, публикации и поддержке видно, перед вами исполнитель экранов или инженер, который держит в голове продукт, ограничения магазина приложений Эппл (App Store) и цену ошибки.
С чего начать разговор о роли и опыте
Начинать разговор надо с реальных задач: какие приложения человек делал, за что отвечал сам и где подключался к чужой архитектуре. Ответы про роль в команде быстро отделяют опыт от красивого резюме.
На практике слабое место многих интервью — разговор уходит в названия технологий. Человек перечисляет язык Свифт (Swift), среду разработки Икс-код (Xcode), библиотеку, пару шаблонов, и вроде звучит солидно. Но мобильная разработка живёт не в названиях. Она живёт в конфликте между скоростью, памятью, сетью, интерфейсом и ожиданиями пользователя, который закроет приложение через три секунды, если экран завис.
Хороший старт — попросить рассказать об одном проекте от первой задачи до релиза. Не о «командной работе» вообще, а о конкретике: какие экраны были сложными, где менялись требования, что ломалось перед публикацией, как команда ловила ошибки после обновления. Тут человек либо вспоминает детали, либо прячется за общими фразами. Детали почти всегда честнее.
| Тема | Что спросить | Что слышно в сильном ответе |
|---|---|---|
| Опыт | Какая часть приложения была на вашей стороне? | Экран, модуль, слой данных, релиз, поддержка после публикации |
| Команда | С кем чаще всего спорили по задаче? | Дизайн, серверная часть, тестирование, владелец продукта |
| Ответственность | Какая ошибка дошла до пользователей? | Причина, исправление, выводы для следующих релизов |
| Релиз | Что делали перед отправкой в магазин приложений? | Проверка сборки, сертификаты, описание, тестовые устройства |
Есть ещё один простой приём. Попросите объяснить старый проект так, будто его завтра забирает другой разработчик. Уверенный инженер быстро называет слабые места: где долг в коде, почему выбрана такая структура, какие файлы трогать нельзя перед релизом. Исполнитель без глубины чаще говорит о том, что «всё работало», и на этом рассказ заканчивается.
Как проверить инженерное мышление
Инженерное мышление видно по тому, как разработчик разбирает проблему до причин, а не по количеству знакомых фреймворков. Просите описать ход мысли: от симптома до исправления, от идеи экрана до устойчивого кода.
Хороший вопрос звучит буднично: «Приложение стало медленно открывать экран с лентой. Что будете проверять?» В ответе должны появиться сеть, кэш, работа с изображениями, главный поток, размер данных, повторные запросы. Если человек сразу предлагает переписать всё, разговор тревожный. В реальной разработке полная переделка редко первая мера; сначала ищут место поломки.
Отдельно спросите про архитектуру. Не надо устраивать экзамен по модным сокращениям. Гораздо полезнее узнать, почему в одном проекте разработчик разделил экран на несколько слоёв, а в другом оставил решение проще. Сильный специалист объясняет цену выбора: где ускорили выпуск, где потеряли гибкость, где тесты спасли от регресса. Слабый прячется за фразой «так принято».
- Как вы отделяете работу с сетью от интерфейса?
- Что делаете, если сервер вернул неполные данные?
- Как проверяете экран без реального сервера?
- Когда пишете тесты, а когда ограничиваетесь ручной проверкой?
- Что меняете в коде, если приложение начинает расходовать слишком много памяти?
Здесь всплывает и отношение к пользовательскому интерфейсу (UI). После первого упоминания хватит простого слова «интерфейс», но смысл не меняется: мобильный экран не терпит небрежности. Разработчик под Ай-Оу-Эс обязан понимать, почему кнопка не должна прыгать после загрузки данных, зачем обрабатывать пустые состояния и чем плоха анимация, которая мешает нажатию.
Кстати, спросите про чужой код. Это почти ночной тест на зрелость. В мобильных командах редко бывает чистый лист; чаще приходит проект с историей, странными решениями и комментариями пятилетней давности. Зрелый разработчик сначала читает, запускает, пишет маленькие правки, смотрит связи. Спешка с массовым переписыванием выдаёт не силу, а риск для сроков.
Что выяснить про сроки, релиз и поддержку
Разговор о сроках раскрывает опыт быстрее, чем спор о технологиях. Разработчик должен назвать зависимости: дизайн, серверные методы, тестовые устройства, публикацию, аналитику, обработку ошибок и время на исправления.
Если кандидат обещает назвать срок сразу после двух предложений о задаче, это плохой знак. Нормальная оценка рождается после вопросов. Сколько экранов? Есть ли готовые макеты? Нужна ли авторизация? Работает ли интерфейс программирования приложений (API)? Какие версии Ай-Оу-Эс поддерживаются? Будет ли офлайн-режим? У каждого ответа есть цена в часах и рисках.
Для разговора с подрядчиком или штатным кандидатом удобно держать перед глазами карту рисков. Она не заменяет техническое задание, зато показывает, видит ли разработчик продукт шире своего редактора кода.
| Зона риска | Вопрос | Зрелая реакция |
|---|---|---|
| Сервер | Что произойдёт при ошибке запроса? | Появится сценарий повтора, текст ошибки, журналирование |
| Устройства | На чём проверять сборку? | Названы разные размеры экранов и версии системы |
| Публикация | Кто готовит материалы для магазина? | Учтены скриншоты, описание, доступы, сборка |
| Поддержка | Что происходит после релиза? | Мониторинг ошибок, разбор отзывов, план исправлений |
Не забудьте про систему контроля версий Гит (Git). Вопрос простой: «Как вы оформляете изменения перед слиянием?» В ответе слышны культура работы и уважение к другим разработчикам. Нормальная история включает ветки, описание правок, просмотр кода, проверку сборки. Если человек работал один, пусть расскажет, как вернётся к изменению через месяц и поймёт собственный замысел.
Про поддержку после релиза говорят неохотно, а зря. Приложение начинает жить именно там: пользователи ставят обновление, сервер отвечает медленнее обычного, магазин задерживает проверку, на старом телефоне внезапно ломается экран. Разработчик, который видел такие ночи, заранее спросит про аналитику, журнал ошибок, доступы и порядок выпуска срочной версии.
Какие ответы должны насторожить
Тревожные сигналы слышны в размытых обещаниях, отказе говорить о прошлых ошибках и презрении к тестированию. Сильный разработчик не изображает безошибочность; он показывает, как снижает риск.
Честно говоря, идеальных собеседований не бывает. Уставший кандидат путает термин, сильный инженер долго формулирует мысль, новичок честно говорит «не делал». Это не приговор. Гораздо опаснее уверенный тон без содержания: «сделаю быстро», «там всё просто», «потом поправим». В мобильном продукте слово «потом» часто означает плохие отзывы, срочный релиз и разговор с бизнесом в пятницу вечером.
- Человек не задаёт встречных вопросов о задаче и пользователях.
- Любую проблему предлагает закрыть новой библиотекой.
- Не помнит примеров ошибок в своих проектах.
- Считает тестирование делом отдельной команды и не проверяет собственные изменения.
- Не понимает процесс публикации в магазине приложений.
Есть и хороший признак, который часто недооценивают: разработчик умеет сказать «не знаю» и тут же называет, как проверит. В инженерной работе незнание не страшно само по себе. Страшна самоуверенность там, где нужны данные, устройство в руках и час на разбор лога. Особенно в Ай-Оу-Эс-разработке, где мелочь в настройках сборки иногда съедает полдня.
Финальный вопрос перед выбором кандидата звучит просто: «Что вы уточните перед началом работы?» Если в ответе появляются цели продукта, сценарии пользователей, макеты, серверные ограничения, сроки публикации и порядок связи, перед вами человек, который думает не только о коде. Такой разговор не гарантирует безупречный релиз, зато резко снижает шанс нанять исполнителя вслепую.
Итог
Сильное интервью с разработчиком под Ай-Оу-Эс строится вокруг опыта, инженерного разбора, релиза и поддержки. Не названия технологий решают исход разговора, а способность объяснить выбор, признать ограничения, увидеть риск и довести приложение до пользователей без лишней героики.
Собеседование держите ближе к реальным ситуациям: медленный экран, ошибка сервера, чужой код, срочный релиз, спор с дизайном. В таких вопросах быстро проявляется уровень специалиста. Один отвечает общими словами. Другой начинает разбирать задачу по слоям — и вот тогда разговор становится деловым.