Статьи
Как Foursquare меняет процесс собеседования с разработчиками и ищет идеальных кандидатов
Ещё год назад Foursquare проводила самые типичные интервью. Но изъяны процесса не давали компании покоя, и она начала эксперименты для самого эффективного отбора разработчиков в свою команду.
Ещё год назад Foursquare проводил самые обычные интервью. Но изъяны этого процесса не давали компании покоя, и она начала эксперименты для самого эффективного отбора разработчиков в свою команду.
Раньше мы начинали с телефонного звонка, во время которого кандидат отвечал на один или два простых вопроса. Если ему это удавалось, то мы приглашали его в офис для серии длинных интервью, которые включали преимущественно разработку и обсуждение проектирования систем.
Этот процесс позволял убедиться в способностях инженеров. И таким образом мы собрали отличную команду. Но, тем не менее, мы были обеспокоены тем, что такие интервью отсеивали многих других хороших разработчиков по причинам, не связанным с их способностями. Это могли быть различия между интервьюерами, волнение кандидатов или неестественность процесса разработки в целом. Многое свидетельствовало о том, что такие проблемы были, поскольку наши партнеры брали на работу тех, кому мы отказали. Помимо этого, исследования показали, что нет прямой взаимосвязи между интервью и результатами труда.
Кстати о вакансиях Foursquare:
Новый подход
Сегодня мы отказываемся от технических интервью по телефону насколько это возможно. Они никому не приятны, и по телефону сложно всесторонне судить о способностях кандидата. Вместо этого мы высылаем трехчасовое домашнее задание. Оно состоит из трех вопросов:
- Вопрос по разработке с несложной функцией
- Более сложный вопрос, который включает создание структуры данных
- Небольшой проект внедрения конкретного сервиса и его ожидаемые результаты
Каждый вопрос, который мы задаем, основан на реальной проблеме, которую нам надо решить, и содержит объяснение, почему мы должны решить эту проблему. Если есть очевидное её решение с плохим временем выполнения, то мы упоминаем об этом, поскольку не можем контролировать процесс. Мы также предоставляем «костяк» программы для разработки, чтобы сэкономить время кандидата.
После получения выполненного домашнего задания, мы анонимизируем его и отправляем на анализ кода. Код и проект отправляются инженеру, который производит оценку. Так как задания анонимны, оценки ставятся вслепую и это уменьшает потенциальное смещение выборки в самом начале процесса. По вопросам разработки у нас есть следующие критерии для оценки: правильность, подход и читаемость. Третий вопрос используется как основа для очного обсуждения проектирования систем.
Если кандидат успешно справляется с заданиями, мы приглашаем его в офис на личное интервью, которое включает разбор домашнего задания. По двум первым вопросам мы просим кандидата пробежаться по коду и объяснить, как он работает. Мы используем ошибки или другие интересные места кода для инициации обсуждения и не придираемся по мелочам. Что касается третьего вопроса, кандидат берет отрывок проекта и пытается подробно его рассмотреть.
Мы всё же задаем некоторые вопросы по разработке во время очного интервью, в зависимости от опыта кандидата. Мы стараемся поддерживать диалог и атмосферу сотрудничества. Помимо разработки, мы разговариваем на такие темы как: создание функции для системы, предыдущие проекты и задействованные технологии (или новые и воодушевляющие) и так далее.
Что мы узнали
https://twitter.com/jeffwjenkins/status/717093944014848000
Самым важным выводом является то, что домашнее задание, основанное на реальных проблемах, которые нам нужно решить, оказалось более точным способом проверки, чем телефонный разговор. Когда кандидаты приходят в офис, их общий результат на интервью очень близок к тому уровню, на каком было выполнено домашнее задание.
Когда у интервьюера и кандидата в начале интервью уже есть написанный код, они могут углубиться и вести более содержательный разговор. Такой процесс кажется более естественным, потому что он больше похож на ежедневную работу наших инженеров.
Поначалу мы просили, чтобы кандидат находил и объяснял свои ошибки. Это было гораздо сложнее для интервьюера и приводило к менее корректным оценкам и худшим впечатлениям кандидата.
Поскольку мы начинаем интервью с чего-то знакомого, это помогает уменьшить волнение и служит хорошей разминкой. И отзывы от кандидатов стали преимущественно положительными. Им нравится интерактивность интервью.
Еще в начале мы просили кандидата предоставить тесты для своего кода. Они обычно ни о чем важном не говорили, а только прибавляли работы, поэтому мы отказались от них. Мы также добавляем «костяк» программы, чтобы сэкономить время кандидата. Так еще и проще проводить наши авто-тесты.
Не останавливаться на достигнутом
Мы знаем, что процесс всё ещё не идеален, но мы рады, что сделали этот первый шаг. После того, как другие отделы Foursquare увидели наши успехи, они тоже начали менять свой процесс интервьюирования! Мы продолжим совершенствовать его, потому что мы стремимся создать отличную команду и сделать это наилучшим способом.
-
Интегрированные среды разработки2 недели назад
Лучшая работа с Android Studio: 5 советов
-
Новости4 недели назад
Видео и подкасты о мобильной разработке 2024.43
-
Новости3 недели назад
Видео и подкасты о мобильной разработке 2024.44
-
Исследования2 недели назад
Поможет ли новая архитектура React Native отобрать лидерство у Flutter в кроссплатформенной разработке?