Долой допросы! Тимлид iOS-команды рассказывает о том, как проводить собеседования, используя бизнес-кейсы
В «1221Systems» мы считаем, что классические собеседования формата «Вопрос-ответ» давно морально устарели. Тимлид iOS-команды Паша Мальков подробно рассказал, как в течение часа понять, что за специалист пришел на интервью и стоит ли брать его в штат — и при этом не задавать кандидату прямых вопросов о том, что он знает и умеет. Уверены, что этот опыт пригодится не только тем, кто трудится в сфере разработки, но и тем, кто ведет найм в других направлениях.
Вопросы на собеседовании: кому они нужны?
Ответ: никому.
За семь лет работы в IT я прошел и провел множество собеседований и считаю, что классические интервью аля «допрос» неэффективны для всех участников процесса.
Для кандидата:
«Допросы» вызывают сильный стресс, и на этом фоне претенденты на вакансию часто забывают или путают элементарные вещи, что ничего не говорит об их технических знаниях. Да, стрессоустойчивость — это важно, но мой опыт показывает, что стресс на собеседовании никак не соотносится со стрессом по работе.
На подобных интервью представители компании нередко хотят сыграть на синдроме самозванца кандидата, продавить его по зарплатным условиям. Это негативно отражается на личности специалиста — человек, которому уронили самооценку и работает потом соответственно.
Для работодателя:
- Чем жестче было собеседование, тем хуже оно влияет на репутацию работодателя. Возможно, человек, который не подошел сейчас, подучится и через год будет обладать в разы большими знаниями или навыками. Но вряд ли он попробует пройти такое собеседование снова.
Для тимлида:
Важно увидеть полную картину soft skills претендента, но это очень сложно сделать, если весь процесс найма завязан на технических вопросах. Мне хотелось понять все необходимое о новом специалисте за одно собеседование длительностью час-полтора, а на деле — приходилось либо полагаться на интуицию, либо планировать повторную встречу.
- Неинтересно и малоинформативно слушать ответы про базовые понятия и определения — сейчас «матчасть» легко найти и заучить. Я даже вывел для себя небольшую закономерность: чем ниже уровень разработчика, тем четче он отвечает на вопросы, не требующие особого размышления.
Идеальный тип собеседования в IT: бизнес-кейс
Настал момент, когда я задумался: как проводить собеседования с претендентами так, чтобы понимать их профессиональный уровень и одновременно видеть личные скилы. И тогда я взял свой опыт участия в хакатонах и решения бизнес-кейсов, смешал это с игровыми механиками на улучшение софт-скилов и получил формулу идеального собеседования.
Берем ситуацию, которая возникает в работе компании и требует принятия решений и моделируем ее в процессе беседы. Разрешение бизнес-кейса требует от сотрудника не только знаний и навыков, но и креативного мышления, и способности быстро принимать решения, — то, что нужно, чтобы проверить, может ли разработчик решать проблемы бизнеса.
Этапы проведения собеседования
- Планирование разработки
делюсь общей информацией о проекте, который мы в настоящее время разрабатываем, без технических подробностей;
даю общее понимание и цели проекта;
моделирую ситуацию, где кандидату предстоит разработать схожий проект в одиночку;
- составляем краткий план действий и строим базовую архитектуру.
Хард-скилы: архитектура, сторонние зависимости.
Софт-скилы: планирование и целеполагание, тайм-менеджмент, самостоятельность, системное мышление, планирование.
История из практики: однажды на этом этапе закончилось мое самое быстрое собеседование. На «С чего ты начнешь разработку приложения?» мне ответили, что я задаю глупые вопросы.
2. Начало разработки:
погружаемся в конкретный модуль приложения, обсуждаем техническую часть;
решаем, как будем верстать UI, взаимодействовать с бэкендом, кешировать данные;
- добавляю новые вводные в ситуацию и наблюдаю, как меняются решения кандидата (увеличение / уменьшение минимальной версии iOS; запрет на использование каких-либо технологий; резкое увеличение количества данных).
Хард-скилы: UI, модульная архитектура, API, многопоточность, debug-инструменты.
Софт-скилы: командная работа, самостоятельность, адаптируемость, креативность, открытость к новому.
История из практики: мое самое любимое условие в этом пункте — работа в режиме отсутствия команды бэкенд-разработки. Мой самый «любимый» ответ — «попрошу доступы к коду и напишу все сам».
Один конкретный модуль приложения на словах проговорили — остальные реализуются по аналогии.
3. Выкладка в магазин приложений:
даю вводную о самых характерных проблемах в приложении, чаще всего постановка задачи звучит так: «Мы выложили протестированное приложение, а пользователи жалуются, что оно не работает»;
- самое интересное — отследить желание кандидата помочь пользователям в соответствии со своим уровнем знаний.
Хард-скилы: исследование крашей, логирование, фичатоглы, поэтапная раскатка, аналитика, backend driven ui.
Софт-скилы: инициативность, нацеленность на результат, критическое мышление, умение слушать, эмоциональный интеллект, клиентоориентированность, ответственность за результат.
История из практики: однажды собеседование завершилось на этом этапе после слов кандидата: «но у меня же всё воспроизводится, это их проблемы».
4. Набираем команду.
«1221Systems» — компания, для которой важны командные игроки, поэтому обязательно рассматриваем ситуацию, когда к разработчику (кандидату) приходят несколько джуниоров.
- наблюдаю, какие варианты улучшения процессов предлагают кандидаты.
Хард-скилы: гитфлоу, автотесты, таск-трекер, автогенерация, ci/cd, кодревью.
Софт-скилы: многозадачность, проектное мышление, убеждение и аргументация, командная работа, делегирование, наставничество.
История из практики: однажды кандидат предложил урезать ему будущую зарплату в обмен на то, что мы дадим ему работать одному. Это важный момент, чтобы отсечь тех, кто не сможет в перспективе работать в коллективе.
Этап 5. Кодревью.
На последнем этапе интервью я даю провести кодревью небольшого куска кода. Это менее стрессово, чем лайвкодинг, но дает возможность закрыть вопросы по квалификации, которые остались к этому моменту.
Собеседование в режиме бизнес-кейса — это огонь, потому что:
- Низкий уровень стресса у кандидата.
А значит, возможность понять истинный уровень технических знаний и софт-скилов кандидата.
- Позитивный образ работодателя.
Кандидаты с удовольствием принимают офферы, если прошли собеседование, а если нет — готовы попробовать снова спустя время.
- Проверка софт-скилов.
Возможность узнать кандидата с разных сторон, не затягивая этот момент до испытательного срока.
- Практика, а не теория.
Сразу видно, как специалист применяет знания на деле.
- Погружение в проект.
Интервью проходят с обсуждением реальных проектов, поэтому, когда кандидат принимает оффер и вливается в команду, он уже имеет базовое представление о том, над каким проектом мы работаем.
- Экономия времени.
Собеседование в формате бизнес-кейса легко уложить в один звонок на 1-1.5 часа.
Откровенно говоря, раньше я как тимлид не любил проводить собеседования. Мне было жаль тратить на «допросы» свое рабочее время и силы. Сейчас мы разбираем реальные ситуации, погружаем кандидатов в тему и даем им раскрыться. Удовольствия от процесса больше с обеих сторон, а главное — теперь я уверен, что так мы действительно отбираем наиболее подходящих нам специалистов.