Как нанять iOS-разработчика и не прогадать: портфолио, собеседование и тестовое задание

Представьте, что вашей компании нужен новый iOS-разработчик под Swift. Вы публикуете вакансию – и получаете десятки откликов. У всех в резюме язык Swift, у многих – pet-проекты на GitHub и даже приложения в App Store.

Казалось бы, бери первого попавшегося. Но не всё так просто. Рынок мобильной разработки пережил потрясения: в 2022 году Apple и Google ввели ограничения для российских разработчиков, удалили тысячи приложений из магазинов и запретили публиковать платные приложения от ряда компаний (источник habr.com).

В результате количество вакансий для iOS-разработчиков упало почти на 30% (см. график ниже). При этом дефицит хороших специалистов никуда не делся – просто теперь бизнес охотится в основном за мидлами и сеньорами, а джунов берут разве что через стажировки. То есть выбор вроде бы большой, но и риск нанять «не того» высок как никогда. Как же HR-специалисту отличить будущую звезду мобильной разработки от новичка с парой уроков программирования за плечами?

Динамика количества вакансий для iOS (синяя линия) и Android (зелёная) разработчиков в России с лета 2022 по лето 2023. К июню 2023 число вакансий для iOS-специалистов сократилось на ~30% (до 410 позиций), для Android – на ~20% (до 664). Источник: исследование «Технократия».

Давайте разберёмся, на что смотреть в портфолио iOS-разработчика, какие вопросы на собеседовании помогут раскрыть его уровень, и нужно ли вообще давать кандидату тестовое задание. Спойлер: подходы меняются, и слепо следовать старым шаблонам найма уже недостаточно.

Портфолио: приложение лучше тысячи слов

Ещё десяток лет назад у мобильных разработчиков не было портфолио в привычном смысле – достаточно было указать в резюме навыки Objective-C или Swift. Сегодня же портфолио для iOS-разработчика почти обязательный атрибут, особенно для сильных кандидатов. Причина проста: лучший доказатель навыков – это реально сделанные приложения. Хороший разработчик либо выложил своё приложение в App Store, либо хотя бы опубликовал код на GitHub, чтобы его могли оценить (источник qna.habr.com).

Не случайно в вакансиях часто просят прислать ссылки на опубликованные приложения или репозитории с кодом. Например, встречаются требования вроде: «Опыт iOS разработки от 3 лет. Приветствуются ссылки на приложения в App Store, GitHub, статьи на Habr...» – то есть работодателю важно увидеть плоды труда, а не только строчки в CV. Один из участников сообщества разработчиков метко заметил: “Не надо клепать проекты «в стол» – лучше сразу публиковать их в App Store или на GitHub”.

Что именно искать в портфолио? Во-первых, обращайте внимание на сложность и качество проектов. Одно дело – учебный калькулятор или очередной ToDo-список по туториалу, и совсем другое – полноценное приложение с оригинальной идеей. Если кандидат представил лишь десяток простейших программ по учебнику, это повод задуматься: человек умеет только следовать инструкциям, но не факт что способен решать реальные задачи (источник contra.com).

«Портфолио, забитое только калькуляторами и списками задач, говорит о том, что разработчик пока не вышел за рамки учебных примеров», предупреждает один из экспертов. В таких случаях на собеседовании стоит прямо спросить: делал ли он что-то свое, сталкивался ли с нестандартными задачами, пробовал ли силы в open source? Настоящий энтузиаст, даже без коммерческого опыта, наверняка найдёт что показать: пусть небольшое, но оригинальное приложение или вклад в чужой проект.

Во-вторых, качество реализации. Посмотрите, как выглядят приложения кандидата: продуман ли интерфейс, нет ли грубых багов, не напоминает ли дизайн эпоху iOS 6. Если приложение постоянно вылетает или выглядит так, будто его делали на коленке, это тревожный звоночек. Конечно, возможны объяснения – например, проект давно заброшен и не обновлялся. Но если соискатель сам демонстрирует багованный продукт как лучшее, на что он способен, представьте, что будет в продакшене.

В-третьих, технологии. Стек iOS-разработки за последние годы эволюционировал: Swift практически вытеснил Objective-C, появился новый фреймворк SwiftUI для интерфейсов. Идеально, если в портфолио отражено владение современными подходами. Допустим, у кандидата проекты только на UIKit, без единого упоминания SwiftUI – это не приговор, но вопрос: старается ли он идти в ногу с временем?

С другой стороны, не стоит автоматом отбрасывать специалиста, если он использует “старые” технологии – возможно, поддерживает легаси-продукт или в его нише без них никак. Главное, чтобы сам кандидат понимал плюсы и минусы своего выбора и был в курсе актуальных трендов. Хороший разработчик объяснит, почему где-то до сих пор пишет на Objective-C, и одновременно расскажет, что изучает SwiftUI и новые фичи iOS SDK.

Наконец, учтите уровень соискателя. Для джуниора естественно иметь скромный портфолио – парочку учебных приложений, пару экспериментов. Здесь важно не количество, а потенциал.

Обратите внимание на качество кода (например, вы можете попросить тимлида просмотреть GitHub кандидата): аккуратен ли код, понятны ли названия переменных, есть ли попытки следовать архитектуре? Приложения начинающего могут быть простыми, зато видно, что человек старается писать чисто и учится на своих проектах. Любопытный факт: некоторые новички выкладывают свои пет-проекты не ради славы, а чтобы найти ментора или получить фидбек сообщества – это хороший знак, говорящий об открытости к обучению.

Для опытного разработчика одного уровня «джун+» и выше требования строже. Если претендует на мидла, хотелось бы увидеть хотя бы одно-два реально запущенных приложения или серьёзных проекта. Один из ветеранов iOS-сообщества отмечал: «Для разработчика под айось минимум – одно опубликованное в App Store приложение, причём посложнее, чем банальные крестики-нолики». Причём не обязательно демонстрировать десятки проектов – достаточно одного, но действительно качественного. Пусть лучше кандидат покажет один классный продукт, которым гордится, чем двадцать однотипных работ.

В случае сеньора помимо самих приложений ценны детали: были ли в них нестандартные технические решения, как кандидат повлиял на архитектуру, как оптимизировал производительность, какую часть ответственности на себе нёс. Топовый инженер в портфолио часто указывает, например, что реализовал сложный модуль с нуля, улучшил скорость работы приложения на N%, наставлял джунов в команде и т.д. – то есть демонстрирует глубину и лидерские качества. Если же у «сеньора» портфолио пустоватое и он расплывчато рассказывает «ну, работал над разными фичами», это повод насторожиться. Неумение чётко сформулировать свой вклад – возможный признак либо приукрашивания опыта, либо проблем с коммуникацией.

Подытожим раздел о портфолио: лучшее, что может сделать HR, – ещё до технического интервью собрать максимум информации о реальных проектах кандидата. Посмотрите приложения (или покажите их тем, кто сможет оценить), попросите при случае исходники или фрагмент кода. Портфолио не заменяет собой собеседование, но задаёт тон разговору. Если у человека горят глаза, когда он рассказывает, как сделал своё приложение и решил в нём какую-то нетривиальную задачу – это уже хороший знак. А если мямлит что-то невнятное про «участвовал в разработке разных модулей» – возможно, и говорить-то особо не о чем.

Собеседование: какие вопросы раскрывают профессионала

Переходим к самому собеседованию. Здесь у HR-специалиста двойная задача. С одной стороны, организовать грамотную техническую проверку – подключив тимлида или разработчиков, которые смогут оценить хард скиллы кандидата. С другой – самому сориентироваться в общении с айтишником, понять, тот ли это человек, кого вы ищете в команду. Как это сделать, если вы не пишете код на Swift?

Во-первых, важно правильно провести первичный скрининг. Обычно он ложится на плечи HR. В продвинутых IT-компаниях HR-ы сами освоили базовые технические вопросы, чтобы отсеивать совсем не подходящих людей еще на ранней стадии (источник habr.com).

Например, HR может спросить: «С какими фреймворками iOS вы работали? Какие библиотеки используете? Развёртывали ли вы приложение в App Store?» – и по ответам понять общий уровень.

Конечно, рекрутер – не разработчик, и тут действует поправка на волнение кандидата и возможные неточности. Но если человек на элементарный вопрос про, скажем, Auto Layout или REST API впадает в ступор, это явный тревожный сигнал. Цель телефонного интервью – отсеять явно неподходящих и сэкономить время команды.

Вопросы на «харды» (технические знания) лучше согласовать с вашими же айосерами: пусть составят короткий чек-лист из ключевых тем. Например, знает ли кандидат про SwiftUI, работал ли с многопоточностью GCD/Operation, понимает ли, что такое ARC (Automatic Reference Counting) и зачем нужны unit-тесты. Эти вещи можно проговорить даже без погружения в код – и уже получить представление, соответствует ли человек заявленному уровню.

Во-вторых, техническое собеседование. Здесь бразды правления стоит передать профессионалам – одному или двум опытным iOS-разработчикам из вашей компании. Интересный факт: в некоторых командах практикуют формат, когда на техинтервью присутствуют сразу два интервьюера от компании. Один ведет беседу, второй наблюдает и подмечает детали, потом они сверяют впечатления – так снижается субъективность оценки. В любом случае, важно чтобы техническая часть была структурированной.

Плохой вариант – когда каждый интервьюер спрашивает что вздумается, хаотично прыгая с темы на тему. Хороший вариант – единой план собеседования, охватывающий основные компетенции, и вопросы, близкие к задачам реальной работы. Например, команда Альфа-банка делится, что у них ушли от шаблонных головоломок и теперь стараются спрашивать только то, что напрямую касается проектов и ситуаций в команде. Это общая тенденция: меньше академических викторин про алгоритмы и больше обсуждения реального опыта кандидата.

Так что же обычно проверяют у iOS-разработчика на интервью? Несколько ключевых областей:

• Знание языка и экосистемы. Разумеется, кандидат должен хорошо разбираться в языке Swift: понимать его возможности, особенности (например, отличия классов и структур, работу Optional’ов, generics и пр.), следить за современными подходами и изменениями версии языка. Наряду с этим – знание платформы iOS: жизненный цикл приложения, основные фреймворки (UIKit/SwiftUI для интерфейса, URLSession/Alamofire для сетевых запросов, CoreData/Realm для базы данных и т.д.). Хороший вопрос: какие последние новинки представила Apple для разработчиков, и успел ли кандидат с ними поработать? Например, что он думает о переходе на SwiftUI, пробовал ли Concurrency (async/await) в Swift и т.п. Это показывает, насколько он следит за трендами или застрял ли в прошлом веке. С другой стороны, в реальной работе ценится и гибкость с технологиями: скажем, спросить, приходилось ли поддерживать старый проект на Objective-C и как он к этому относится (источник uplers.com). Вопрос на эту тему – не ловушка, а признание реальности: многие компании до сих пор имеют legacy-код на Obj-C, и важно, чтобы новый сотрудник не растерялся, увидев его.
• Опыт разработки и архитектура приложений. Тут очень полезно расспросить кандидата о его прошлых проектах. Например: «Расскажите о самом сложном приложении, которое вы делали. В чём состояла идея, какие технологии использовали, с какими трудностями столкнулись и как их преодолели?» – такой открытый вопрос позволяет человеку проявить себя во всей красе. Хорошие кандидаты обычно охотно делятся деталями: как планировали работу, как выбирали архитектуру, почему применили именно MVVM, а не MVC, как оптимизировали работу со сложным API или с большими данными. Когда человек глубоко погружён в проект, он расскажет и про сотрудничество с дизайнерами, и про исправление багов перед релизом, и про выпуск обновлений. Внимательно слушайте: понимает ли он весь цикл разработки? Например, кандидат может упомянуть, как вместе с дизайнером улучшал UX одной из функций или как привлекал бета-тестеров через TestFlight – это признак зрелости мышления. Отличный вопрос, советуемый в одном из гайдлайнов: «Можете пошагово рассказать, как ваш проект прошёл путь от концепции до запуска в Store?». Ответ покажет, участвовал ли разработчик во всех фазах – от проработки требований и дизайна до деплоя на App Store. И, конечно, уточняйте роль самого кандидата: что конкретно он реализовал, за что отвечал в команде. Сильный кандидат честно разделит, где его личный вклад, а где общие успехи команды, и при этом не умолит достоинств коллег.
• Навыки отладки и решения проблем. Разработка приложений полна скрытых граблей: утечки памяти, крэши, странное поведение UI на старых устройствах… Поэтому интервьюеры обычно проверяют, как кандидат ведёт себя, столкнувшись с проблемой. «Представьте: ваше приложение начало вылетать при запуске на iOS 17 – как будете искать и исправлять ошибку?» Или: «Какое самое сложное баг-репорт вам доводилось раскручивать?». Тут смотрят на подход к диагностике: например, будет ли человек воспроизводить баг, читать логи, использовать инструменты типа Crashlytics или Instruments для поиска утечек и т.д. Опытный разработчик расскажет, как выстраивает гипотезы и методично их проверяет. Возможно, вспомнит случай, когда бился над проблемой, прочесал Stack Overflow, привлёк коллег и всё-таки нашёл решение – это и есть реальная работа. Важно, чтобы кандидат не боялся признать, что чего-то не знает и готов гуглить или спрашивать помощь: честность и умение учиться ценятся выше показного всезнайства.
• Алгоритмическое и системное мышление. Вопрос об алгоритмах – больная тема многих айтишных собеседований. В продуктовых командах, особенно в России, всё реже просят написать сортировку или решить задачу про графы на доске – это оправданно считают избыточным. «Мы не заставляем вращать красно-чёрные деревья», как образно выразился один техлид. Однако это не значит, что вопросы на сообразительность вовсе исчезли. Кандидату могут предложить небольшую прикладную задачку: например, как получить уникальные элементы из массива, или как оптимально спарсить JSON с большим количеством вложенных объектов. Цель – проверить базовую эрудицию и умение писать код в принципе. Нередко практикуется формат live-coding: когда просят поделиться экраном и решить простую задачу прямо в Xcode или в онлайн-редакторе. Не для того, чтобы придраться к каждой запятой, а чтобы увидеть ход мыслей: как человек берет проблему, разбивает на шаги, насколько аккуратно пишет код, комментирует ли свои действия. Для многих соискателей это стресс, но хороший специалист обычно справляется: даже если не сразу помнит точный синтаксис, он покажет структурированное мышление и навыки «debugging on the fly» (например, пишет юнит-тест, чтобы проверить свою функцию).
• Командная работа и процессы. Современный разработчик не живёт в вакууме кода – он постоянно взаимодействует с людьми и инструментами. Поэтому на интервью всё чаще затрагивают темы soft skills и опыта сотрудничества. Например: «Как вы обычно выстраиваете работу с дизайнерами и менеджерами? Что делаете, если дизайн-макет сложно воплотить на практике?» – ответ покажет, умеет ли кандидат говорить с недевелоперами, понимает ли принципы UX. Или спросят про опыт код-ревью: «Приходилось ли вам просматривать код коллег? Как реагируете на замечания к своему коду?». Важный аспект – контроль версий и проекты командой: тут HR может спросить хотя бы про опыт с Git и GitHub («Знаете ли вы, что такое pull request и как пользуетесь branching-стратегиями?»). Хорошо, если кандидат вспомнит, как он совместно с командой релизил фичу, как делили задачи в Jira, как оценивал свои таски. Всё это говорит о зрелости инженера. В конце концов, как отмечают сами разработчики, написание кода – далеко не вся работа. Большая часть – это обсуждение требований, общение с коллегами, планирование (источник thecode.media). Поэтому умение ясно излагать мысли, договариваться и быть командным игроком для iOS-разработчика так же важно, как знание Swift. В Apple есть даже специальные гайдлайны по дизайну и code style, следование которым требует внимательности и умения работать по стандартам – и это тоже своего рода soft skill.

Подытоживая: хорошее интервью с iOS-разработчиком – это не допрос с пристрастием на знание мелочей API, а живой профессиональный разговор. Опытные тимлиды советуют обсуждать с кандидатом его опыт и задачи, с которыми он реально сталкивался. Тогда и сложные вопросы задаются естественно: из рассказа про проект плавно вытекает вопрос про выбор архитектуры, из упоминания про баг – вопрос про отладку, из слов о взаимодействии с дизайнером – вопрос про удобство UI. Такой подход позволяет кандидату показать себя, а интервьюерам – понять, как он думает и работает. И HR-у важно организовать именно такую беседу, вовремя направляя её в нужное русло и наблюдая, как кандидат раскрывается.

Тестовое задание: друг или враг?

Наконец, перейдём к тестовым заданиям – пожалуй, самому спорному этапу отбора. Ещё недавно казалось нормой: прежде чем нанять разработчика, дайте ему «домашку» – пусть напишет небольшой проект, покажет код в деле. Сейчас отношение меняется. Все чаще можно услышать мнение: тестовое – пережиток прошлого, оно лишь отнимает время и демотивирует сильных кандидатов. Так ли это, и что делать HR-у?

Начнём с позиции «против тестовых», тем более её активно отстаивают сами разработчики. Сергей Копытов, iOS TechLead Альфа-банка, который провёл десятки собеседований, говорит прямо: «Тестовые задания мы не даём принципиально». По его мнению, толк есть только для стажёра, чтобы понять базу новичка. Джуниору тестовое уже может быть неприятно, хотя иногда приходится, если у человека нет вообще никаких примеров кода.

А вот кандидат уровня джун+ и выше воспринимает домашнее задание как пустую трату времени: «Кто-то откажется его делать, и мы потеряем хорошего кандидата», делится опытом Копытов. Действительно, представьте: сильный специалист, у которого и так несколько офферов на руках, получает от вас задачку на 8 часов кодинга «в свободное время». Велика вероятность, что вы его больше не увидите – человек просто выберет компанию, где уважают его время.

Есть и объективная проблема: сложно придумать тестовое задание, по которому реально можно что-то оценить. Если сделать его коротким и простым, то джун+ и сеньор решат его примерно одинаково, и толком не поймёшь, кто лучше. Если сделать объёмным и приближенным к боевым условиям – велика шанс, что никто не захочет его выполнять, а потом и проверять столь обширную работу будет затруднительно. Копытов признаётся, что в его практике за последние несколько лет не было случая, чтобы потребовалось тестовое для опытного кандидата – все вопросы и так решаются на этапах интервью. Вместо домашек в Альфа-банке делают ставку на хорошо выстроенное собеседование (о чём мы говорили выше) и просмотр кода кандидата прямо на интервью или по его же репозиторию.

Однако бывает и другая ситуация. Например, вы ищете джуниора, который только окончил курсы, и по его разговору пока не ясно, как он справляется с задачами. Или у кандидата нет опубликованных работ и кода: ну сделал он пару учебных проектов, но они закрыты, и сложно судить о стиле его программирования. В таких случаях тестовое задание может пригодиться – как говорит тот же Копытов, неприкольно, но бывает необходимо, если нет примеров кода. Тестовое для начинающего – это как вступительный экзамен: проверяет базовые навыки и усердие, с которым человек подходит к делу.

Как сделать тестовое эффективным? Несколько советов из практики разных компаний:

• Минимизируйте объём. Задание «на пару вечеров» воспринимается гораздо лучше, чем проект на неделю. Оптимально, если кандидат укладывается в 3–5 часов работы. Помните, у соискателя могут быть другие предложения и текущая работа – марафонское кодирование в свободное время мало кому удобно.
• Реальная задача вместо абстракции. Лучше, если тестовое напоминает упрощённый фрагмент ваших реальных задач. Например, не бессмысленную «игру в крестики-нолики», а небольшое приложение, решающее понятную проблему: получить список новостей через API и отобразить в таблице, например. Так кандидат видит практический смысл, а вы проверяете умение работать с тем же стеком, что и в вашей компании (сеть, UI, обработка данных и т.п.) (источник kiparo.ru). Кстати, на Хабре можно найти примеры типовых тестовых задач для мобильных разработчиков: от приложения «Погода» до поиска GIF-картинок через внешний API – эти задачи компании действительно давали кандидатам.
• Чёткие критерии оценки. Сообщите кандидату, на что будете смотреть: качество кода (читаемость, архитектура), работа приложения (корректность, отсутствие багов), может быть, наличие базовых тестов. Тогда разработчик сфокусируется на важных аспектах. Некоторые компании даже предоставляют чек-лист: мол, за что плюс, а за что минус. Это повышает объективность и прозрачность.
• Фидбек и обратная связь. Если человек потратил время на задание, обязательно дайте ему развернутый отзыв, даже если отказываете. Это элемент уважения и хорошего HR-бренда. Обидно, когда кандидат высылает проект и получает в ответ только сухое «сорри, вы нам не подходите». Лучше укажите, что было хорошо, а где не хватило. Так вы не сожжёте мосты: возможно, подтянув навыки, этот же разработчик вернётся к вам через год, помня, что с ним обошлись по-человечески. В случае успешного прохождения, разберите тестовое на финальном интервью: пусть кандидат прокомментирует свои решения, это тоже дает интересную информацию о нём.

Заметим, что во многих компаниях от практики тестовых совсем отказались. Вместо этого делают упор на живое общение, ревью кода (просят прислать небольшой фрагмент своего кода или выполняют вместе мини-задачу в режиме pair programming) или устраивают дополнительное интервью с упором на практику. Цель ведь не в том, чтобы кандидат бесплатно написал вам кусочек приложения. Цель – оценить его навык разработки. А это можно сделать разными путями.

Как ни странно, иногда проще поверить портфолио на слово, чем тратить время на искусственную проверку. Если у претендента три приложения в App Store с отличными отзывами – какой смысл гонять его писать четвёртое «для галочки»? Лучше обсудить, как он эти три сделал, и уже по разговору станет ясно, что он знает. Как говорится, хороший разработчик – он и в разговоре хороший.

Вместо заключения: найм как инвестиция

Найм iOS-разработчика в 2025 году – непростая, но решаемая задача. С одной стороны, рынок встряхнуло, и предложений от соискателей хватает. С другой – вам нужен именно ваш разработчик: тот, кто впишется в команду и создаст для ваших пользователей классное приложение. Мы обсудили, как портфолио помогает разглядеть практические навыки, как правильные вопросы на интервью раскрывают мышление кандидата, и когда стоит (и не стоит) давать тестовое задание.

Помните, что мотивация и способности человека часто важнее чек-листа технологий. iOS-разработка – сфера, которая постоянно меняется: выходят новые версии Swift, Apple придумывает что-то вроде SwiftUI, появляются то ARKit, то Machine Learning Kit. Хороший специалист отличается тем, что непрерывно учится и адаптируется. Если кандидат демонстрирует жадность до знаний, горит своими проектами, умеет рассуждать и признавать ошибки – вероятно, из него выйдет ценный сотрудник, даже если сейчас чего-то не знает.

Что до рынка – он цикличен. Сегодня вакансий для iOS-разработчиков поменьше, чем год-два назад, но спрос никуда не исчез. «До тех пор, пока люди будут пользоваться продуктами Apple, спрос на разработчиков будет», уверенно отмечает один из экспертов.

А значит, и задача HR – находить и привлекать этих самых разработчиков – останется актуальной. Хочется верить, что наши советы помогут вам в этом непростом деле. Удачного найма и классных вам приложений!