Привет, Habr!

Меня зовут Паша, я тимлид iOS-команды в IT-компании крупного российского ретейлера. В силу должности я непосредственно связан с процессом найма людей и за семь лет прошел и провел огромное количество собеседований. Знаю этот процесс с обеих сторон и рискну утверждать, что классические собеседования «Вопрос-ответ» давно морально устарели.

Вопросы на собеседовании — вчерашний день 

Есть минимум пять причин, почему я считаю собеседования в формате допроса неэффективными.

Для кандидата:

1. Обычно люди испытывают очень сильный стресс от собеседований-допросов. На фоне стресса они часто что-то забывают, путают, иногда даже начинают гуглить, делая вид, что вспоминают. Словом, делают то, что на самом деле ничего не говорит об их технических знаниях. Мне доводилось встречать кандидатов, которым жизненно необходимо было курить на собеседовании — из-за нервов. Кто-то может на это возразить, что кандидат должен быть стрессоустойчив, но стресс на собеседовании никак не соотносится со стрессом на работе: мой опыт показывает, что это абсолютно разные вещи.

2. У разработчиков часто прослеживается синдром самозванца, который собеседующий на подобных интервью часто пытается использовать, «задавив»  кандидата, чтобы он не попросил высокую зарплату. Это негативно влияет и на личность кандидата, и на его последующую работу.

Для работодателя:

3. Такие собеседования, особенно если кандидаты в итоге получают отказ, как правило, оставляют только негативные эмоции о работодателе. В перспективе это отрицательно влияет как на репутацию компании, так и на вероятность того, что кандидат, повысив свой уровень, попробует пройти собеседование снова.

Для тимлида:

4. После таких собеседований сложно определить soft skills претендента на вакансию, потому что в основном весь процесс завязан на технических вопросах. Приходится либо полагаться на удачу, либо проводить дополнительное собеседование на проверку soft skills. При высокой занятости такой вариант не подходит — мне хотелось успевать понять все необходимое за одно собеседование длительностью час-полтора.

5. В эпоху Chat GPT на любой вопрос, который не требует размышлений, можно легко найти ответ и заучить его. Поэтому ценность ответов на такие вопросы на собеседовании при приеме на работу для меня как тимлида очень низкая. Я даже вывел для себя небольшую закономерность: чем ниже уровень разработчика, тем четче он рассказывает базовые понятия и определения. 

Идеальный тип собеседования: бизнес-кейс

В итоге я вывел для себя идеальный способ проведения собеседований. В нем смешаны мой опыт участия в хакатонах, опыт решения бизнес-кейсов и различные игровые механики на улучшение софт-скилов.

Перед тем, как рассказать подробнее про план собеседования, определим понятия:

Бизнес-кейс — это ситуация, которая возникает в работе компании и требует принятия решений. Разрешение бизнес-кейса может потребовать от сотрудника не только знаний и навыков, но и креативного мышления и способности быстро принимать решения.

Основная цель собеседования, которое включает в себя бизнес-кейс — проверить, может ли разработчик решать проблемы бизнеса. На первом месте стоит то, насколько хорошо разработчик может решить проблему, на втором — насколько правильно он это сделает технически.

Как я провожу собеседования 

Весь процесс основан на моделировании ситуаций, которые кандидату нужно решить. Параллельно я углубляюсь в технические тонкости — про эту важную часть тоже не стоит забывать.

Этап 1. Планирование разработки

В начале я рассказываю про проект, который мы разрабатываем, не затрагивая технические детали. После этого моделирую ситуацию, в которой кандидату нужно будет разработать этот же проект, но в одиночку. Мы составляем небольшой план проекта и закладываем базовую архитектуру.

Хард-скилы: архитектура, сторонние зависимости.

Софт-скилы: планирование и целеполагание, тайм-менеджмент, самостоятельность, системное мышление.

История из практики: однажды на этом этапе закончилось мое самое быстрое собеседование. На «С чего ты начнешь разработку приложения?» мне ответили, что я задаю глупые вопросы.

Этап 2. Начало разработки

На этом этапе мы чуть больше погружаемся в конкретный модуль приложения и говорим о технической части. Решаем, как будем верстать UI, взаимодействовать с бэкендом, кешировать данные. Иногда, если ответы на вопросы меня не до конца устраивают, я могу добавлять новые вводные в ситуацию и наблюдать, как меняются решения у кандидата:

• увеличение / уменьшение минимальной версии iOS: это проверка на знание и использование новых технологий.

• запрет на использование каких-то технологий: проверяю умение решать проблемы различными способами.

• резкое увеличение количества данных: смотрю на умение использовать асинхронные запросы, кеширование и прочие технологии для улучшения взаимодействия с сервером.

Хард-скилы: UI, модульная архитектура, API, многопоточность, debug-инструменты.

Софт-скилы: командная работа, самостоятельность, адаптируемость, креативность, открытость к новому.

История из практики: мое самое любимое условие в этом пункте — работа в режиме отсутствия команды бэкенд-разработки. Мой самый «любимый» ответ — «попрошу доступы к коду и напишу все сам».

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

Этап 3. Выкладка в магазин приложений

Здесь интересно умение анализировать проблемы в приложении, особенно в ситуациях, когда локально проблема не воспроизводится, «у меня все работает».

Обычно постановка задачи звучит так: «Мы выложили протестированное приложение, а пользователи жалуются, что оно не работает». Вариации решения и анализа проблем бывают разные, в зависимости от уровня разработчика, но основная характеристика — желание помочь пользователям.

Хард-скилы: исследование крашей, логирование, фичатоглы, поэтапная раскатка, аналитика, backend driven ui.

Софт-скилы: инициативность, нацеленность на результат, критическое мышление, умение слушать, эмоциональный интеллект, клиентоориентированность, ответственность за результат.

История из практики: однажды собеседование завершилось на этом этапе после слов кандидата «но у меня же не воспроизводится, это их проблемы».

Когда разобрались с проблемами приложения, то можем начинать наращивать силы для ускорения разработки и увеличения производительности.

Этап 4. Набираем команду

Предлагаю кандидату выстроить работу команды. Для утрирования ситуации обычно рассматриваем вариант, когда в команду к сильному разработчику (кандидату) нанимают 5 джуниор-разработчиков.

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

Хард-скилы: гитфлоу, автотесты, таск-трекер, автогенерация, ci/cd, кодревью.

Софт-скилы: многозадачность, проектное мышление, убеждение и аргументация, командная работа, делегирование, наставничество.

История из практики: на этом этапе часто «раскрываются» люди, не желающие работать в команде. Однажды кандидат предложил урезать ему будущую зарплату в обмен на то, что мы дадим ему работать одному.

Этап 5. Кодревью

На последнем этапе интервью я предлагаю кандидату провести кодревью небольшого куска кода. Это не такой сильный стресс по сравнению с лайвкодингом, но при этом позволяет закрыть вопросы по кандидату, которые у меня остались.

Плюсы собеседования в режиме бизнес-кейса

1. Низкий уровень стресса у кандидата.

Обычно, когда кандидаты понимают, что их не будут «допрашивать», они успокаиваются, что позволяет понять истинный уровень их технических знаний и софт-скилов. 

2. Позитивный образ работодателя.

После таких интервью кандидаты, как правило, оставляют положительные отзывы и с удовольствием принимают оферы, если прошли собеседование. В крайнем случае, говорят, что «через год с удовольствием приду снова».

3. Проверка софт-скилов.

Я считаю, что софт-скилы кандидата не менее важны, чем хард-скилы. Такой способ собеседования позволяет мне узнать и то, и другое. Честно говоря, при проверке софт-скилов в таком режиме мы довольно часто встречаем «красные флаги» — нежелательные особенности кандидата, о которых в ином случае мы узнали бы только на испытательном сроке.

4. Практика, а не теория.

Теорию могут заучить почти все. Применять эту теорию на практике могут немногие.

5. Погружение в проект.

Я стараюсь проводить собеседования на реальных кейсах и на реальном приложении, поэтому, когда кандидат устраивается к нам на работу, он уже имеет базовое представление о том, над каким проектом мы работаем.

6. Экономия времени.

Благодаря такому подходу удается уместить собеседование в один звонок продолжительностью 1-1.5 часа и понять все необходимое о кандидате. В режиме постоянного развития компании сейчас и постоянного просмотра кандидатов это очень ценно.

Честно признаюсь: до того, как мы в компании внедрили проведение собеседований на основе бизнес-кейсов, я не очень любил этот процесс. Мне было жаль тратить на интервью свое рабочее время. Новый подход позволяет моделировать реальные ситуации, погружает кандидатов в тему и дает им раскрыться и как профессионалам, и как личности. Я сам получаю удовольствие от процесса, а главное — уверен, что так мы действительно отбираем наиболее подходящих специалистов. В итоге наша команда на данный момент полностью укомплектована, и у нас низкая текучка (83% разработчиков продолжают работать с момента основания компании).