Support us

Как Foursquare ищет идеальный процесс собеседования с разработчиками

Оставить комментарий
Как Foursquare ищет идеальный процесс собеседования с разработчиками
Ещё год назад Foursquare проводил самые обычные интервью. Но изъяны этого процесса не давали компании покоя, и она начала эксперименты для самого эффективного отбора разработчиков в свою команду. О том, как это происходило, они рассказали в своём блоге.

Читать далее

Основатели Foursquare Деннис Кроули и Навин Селвадураи. Фото: hbr.org.

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

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

Новый подход

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

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

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

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

Если кандидат успешно справляется с заданиями, мы приглашаем его в офис на личное интервью, которое включает разбор домашнего задания. По двум первым вопросам мы просим кандидата пробежаться по коду и объяснить, как он работает. Мы используем ошибки или другие интересные места кода для инициирования обсуждения и не придираемся по мелочам. Что касается третьего вопроса, кандидат берёт отрывок проекта и пытается подробно его рассмотреть.

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

Что мы узнали

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

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

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

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

Ещё в начале мы просили кандидата предоставить тесты для своего кода. Они обычно ни о чем важном не говорили, а только прибавляли работы, поэтому мы отказались от них. Мы также добавляем «костяк» программы, чтобы сэкономить время кандидата. Так ещё и проще проводить наши автотесты.

Не останавливаться на достигнутом

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

Место солидарности беларусского ИТ-комьюнити

Далучайся!

Читайте также
«‎‎Главная ошибка собеса — подгонять ответы»‎. Рекрутеры рассказали о найме в IT
«‎‎Главная ошибка собеса — подгонять ответы»‎. Рекрутеры рассказали о найме в IT
Bubble
«‎‎Главная ошибка собеса — подгонять ответы»‎. Рекрутеры рассказали о найме в IT
ИТ-сектор Беларуси потерял 10000+ человек с начала 2022 года
ИТ-сектор Беларуси потерял 10000+ человек с начала 2022 года
ИТ-сектор Беларуси потерял 10000+ человек с начала 2022 года
44 комментария
Как составить резюме на английском. Инструкция
Как составить резюме на английском. Инструкция
Как составить резюме на английском. Инструкция
3 комментария
Google замедляет наём сотрудников
Google замедляет наём сотрудников
Google замедляет наём сотрудников

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.