Долой допросы! Тимлид iOS-команды рассказывает о том, как проводить собеседования, используя бизнес-кейсы

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

Вопросы на собеседовании — не самый эффективный способ отбора кандидатов
Вопросы на собеседовании — не самый эффективный способ отбора кандидатов

Вопросы на собеседовании: кому они нужны?

Ответ: никому.

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

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

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

  • На подобных интервью представители компании нередко хотят сыграть на синдроме самозванца кандидата, продавить его по зарплатным условиям. Это негативно отражается на личности специалиста — человек, которому уронили самооценку и работает потом соответственно.

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

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

Для тимлида:

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

  • Неинтересно и малоинформативно слушать ответы про базовые понятия и определения — сейчас «матчасть» легко найти и заучить. Я даже вывел для себя небольшую закономерность: чем ниже уровень разработчика, тем четче он отвечает на вопросы, не требующие особого размышления.

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

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

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

Этапы проведения собеседования

  1. Планирование разработки
  • делюсь общей информацией о проекте, который мы в настоящее время разрабатываем, без технических подробностей;

  • даю общее понимание и цели проекта;

  • моделирую ситуацию, где кандидату предстоит разработать схожий проект в одиночку;

  • составляем краткий план действий и строим базовую архитектуру.

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

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

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

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

  • погружаемся в конкретный модуль приложения, обсуждаем техническую часть;

  • решаем, как будем верстать UI, взаимодействовать с бэкендом, кешировать данные;

  • добавляю новые вводные в ситуацию и наблюдаю, как меняются решения кандидата (увеличение / уменьшение минимальной версии iOS; запрет на использование каких-либо технологий; резкое увеличение количества данных).

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

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

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

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

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

  • даю вводную о самых характерных проблемах в приложении, чаще всего постановка задачи звучит так: «Мы выложили протестированное приложение, а пользователи жалуются, что оно не работает»;

  • самое интересное — отследить желание кандидата помочь пользователям в соответствии со своим уровнем знаний.

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

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

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

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

  • «1221Systems» — компания, для которой важны командные игроки, поэтому обязательно рассматриваем ситуацию, когда к разработчику (кандидату) приходят несколько джуниоров.

  • наблюдаю, какие варианты улучшения процессов предлагают кандидаты.

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

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

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

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

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

Собеседование в режиме бизнес-кейса — это огонь, потому что:

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

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

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

Кандидаты с удовольствием принимают офферы, если прошли собеседование, а если нет — готовы попробовать снова спустя время.

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

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

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

Сразу видно, как специалист применяет знания на деле.

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

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

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

Собеседование в формате бизнес-кейса легко уложить в один звонок на 1-1.5 часа.

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

1414
Начать дискуссию