[Перевод] Как нанимать разработчиков: Выводы из 300 собеседований за 30 дней
В нашем блоге на Мегамозге мы много пишем об интересных подходах к менеджменту (которые стараемся применять в работе над облачным сервисом 1cloud) и интересных способах решения проблем, с которыми сталкиваются ИТ-компании. В прошлый раз мы писали о том, как разработчикам переходить в руководители, а сегодня речь пойдет о том, как этих самых разработчиком можно нанимать. Представляем вашему вниманию адаптированный перевод заметки команды сервиса Triplebyte о том, чему их научил марафон по проведению 300 технических интервью за 30 дней.
Мы основали Triplebyte месяц назад, чтобы вывести процесс найма программистов на новый уровень. Слишком много компаний проводят собеседования в стандартном формате: смотрят их резюме, просят написать пример кода, полагаются на интуицию. Мы описали свои идеи касательно данной проблемы в нашем манифесте. Итак, прошло чуть больше месяца. За эти тридцать дней мы провели триста интервью, так сказать, начали воплощать свои идеи в жизнь, чтобы посмотреть, как они работают на практике. В этом посте я собираюсь рассказать вам о том, что мы узнали.
Вас ждет множество подробностей о наших открытиях. Вот основные из них:
- Электронный тест может многое рассказать о том, как пройдет собеседование;
- FizzBuzz-тест менее показателен в предсказании успешности собеседования;
- Рассказы кандидатов о прошлых программных проектах, над которыми они работали, не показательны.
Собеседования
Собеседования проходили в четыре этапа:
- Онлайн-проверка технических навыков;
- 15-минутный телефонный звонок, в ходе которого обсуждается технический проект;
- 45-минутное собеседование по сети с демонстрацией экрана, в ходе которого соискатель пишет код;
- 2-часовая работа над большим проектом с демонстрацией экрана.
Кандидаты работали на своих компьютерах, могли использовать любую среду разработки и программировать на удобном для них языке. Во время 45-минутного и 2-часового собеседований соискатели самостоятельно выбирали задание или проект из короткого списка: мы хотели выявить их сильные стороны, потому предположили, что они выберут те темы, в которых хорошо разбираются. Список был коротким, чтобы можно было легко стандартизировать оценку работы. По каждому пункту списка нам нужно было получить как можно больше информации.
Было важно, чтобы человек понимал, что он делает, а не действовал наугад, поэтому к каждому заданию прилагался алгоритм выполнения (за его использование не налагалось никаких штрафов). Оценка производилась с помощью оценочной карты. Мы дополнительно отмечали время, за которое кандидат справлялся с той или иной частью задачи. Помимо этого, мы оценивали уровень знаний соискателя (употребляет терминологию или говорит в общих словах), уровень волнения и еще многое другое (в принципе, все, что смогли придумать). Большинство этих показателей, разумеется, являются плохими критериями оценки качества работы, но мы их учитывали, чтобы позже выделить наиболее эффективные.
Отбор
Сначала нам нужно было провести отбор кандидатов – здесь отсеивается большинство соискателей. Чтобы сэкономить время специалистов по подбору персонала, компаниям нужен инструмент, позволяющий отбирать достойных людей на раннем этапе. Обычно в роли этого инструмента выступает резюме. Горькая правда состоит в том, что большинство специалистов, оставляющих свои резюме, оказываются некомпетентными. Как показала Элин Лернер (Aline Lerner), с его помощью нельзя отличить плохого программиста от хорошего. Это проблема. Индустрии нужно отбирать работников, оценивая их навыки и способности, а не то, где они учились или работали [1]. Мы предложили провести отбор в два этапа:
- FizzBuzz-тест, где претендентам нужно выполнить два простых задания. Мы учитывали время, потраченное на выполнение каждого из них, а затем вручную оценивали правильность и качество кода.
- Электронный тест. Вопросы имели несколько вариантов ответа и требовали понимания кода (например, выявление ошибок в коде).
Мы сопоставили результаты этих двух этапов с результатами трехсот 45-минутных собеседований.
Мы видим, что электронный тест является хорошим показателем успешности собеседования: с его помощью можно предсказать, как пройдет практически четверть из них (23%). Успешность 15% собеседований можно оценить по времени выполнения теста (быстрее значит лучше). Скорость выполнения теста и количество набранных баллов слабо связаны между собой (правильность выполнения не означает, что человек быстро сделал все задания), поэтому мы можем их объединить – это позволяет нам спрогнозировать результат 29% собеседований [2]!
FizzBuzz-тесты показали себя не так хорошо. Хотя доверительные интервалы очень большие, полученные данные слабо коррелируют с результатами собеседований. Я был удивлен. Кажется очевидным, что при приеме на должность программиста, следует попросить человека написать пару строк кода. Однако данные говорят обратное. Более того, на решение FizzBuzz-задачи кандидаты тратили вдвое больше времени, чем на тестирование.
Рассказы о проектах или программирование
Перед созданием проекта мы пообщались с огромным количеством людей, имеющих опыт найма технических специалистов, чтобы почерпнуть свежие идеи. Наиболее удачной мыслью мне показалось общение с кандидатами об их технических проектах (включая просмотр исходного кода). Этот подход выглядел наиболее дружественным.
Как только мы начали проверять эту идею, я заметил одну вещь – практически все кандидаты на должность подходили. Наш «фильтр» не «фильтровал». Мы пытались экспериментировать с продолжительностью собеседования, чтобы подробнее исследовать вопрос, и даже просматривали код с помощью Google Hangouts, однако количество отобранных кандидатов по-прежнему оставалось слишком большим.
Проблема была в том, что рассказ кандидата о прошлых проектах не давал нам достаточно оснований для отказа. Поэтому мы начали просить соискателей написать пару строк кода. Вдруг значительная часть людей, которая в красках расписывала впечатляющие проекты, провалила тесты с написанием программ, и, наоборот, кандидаты, рассказавшие о тривиальных проектах (или описавшие их так, что мы даже не поняли, над чем они действительно работали), справились с задачками лучше всех.
Всего мы провели около 90 таких собеседований, во время которых выставляли оценки по нескольким показателям (знает ли кандидат свое дело, разбирается ли в тонкостях проекта, уверен ли он в себе, впечатление, которое произвел проект). Затем мы сопоставили наши оценки с результатами 45-минутного собеседования. Оказалось, что уверенность человека никак не коррелирует с результатами собеседования. Впечатление, которое произвел кандидат, уровень его знаний и понимание деталей проекта – это те показатели, которые позволили предсказать исход 20% собеседований. Другими словами, автоматизированный тест показал лучший результат, чем обзор прошлых проектов.
Однако более подробное изучение прошлого опыта кандидата может дать результат. Именно благодаря ему (как мне кажется) я уверен, что мои друзья – замечательные программисты. Но 45-минутный разговор о программировании не заменит само программирование.
Длительность собеседования и поведение интервьюера
Наконец, мы проверили, в какой момент собеседования принимается решение. Ласло Бок (Laszlo Bock), вице-президент Google по персоналу, очень много писал о том, что кадровые специалисты принимают решение уже в первые минуты собеседования, а оставшееся время только укрепляются в нем. Мне хотелось убедиться, что мы действовали по-другому. Чтобы это проверить, мы внедрили в наше программное обеспечение для проведения собеседований всплывающее сообщение, которое появлялось каждые 5 минут и просило оценить кандидата – так мы могли точно сказать, в какой момент было принято решение.
Оказалось, что в половине 45-минутных собеседований решение принималось в первые 20 минут. В 20% случаев решение принималось за 5 минут до конца. Эти результаты совпадают с результатами 2-часового собеседования: судьба 60% соискателей была определена в течение первых 20 минут, а 10% – в последние минуты (большой процент ранних решений – это отрицательный показатель, поскольку мы не можем позволить себе направить в компанию ненадежного человека).
Заключение
Это был безумный месяц. Гийом, Харж и я практически все время были заняты на собеседованиях. По субботам в 10 вечера (после целого дня общения с кандидатами) я иногда думал, а зачем мы вообще основали нашу компанию? Сейчас, когда я пишу этот пост, я вспомнил. Найм человека на работу – это важное решение, которое многие компании принимают, пользуясь классическими методами. За первые 30 дней мы нашли замену резюме и показали, что наш подход отлично работает. Мы выяснили, что собеседования, во время которых оценивается опыт кандидата (используемые во множестве компаний), не так хороши, как кажутся. Еще мы написали программное обеспечение, которое помогло понять, когда и почему мы принимали решения.
Сейчас мы сопоставляем результаты наших экспериментов с итогами собеседований, которые сами же и проводили, поэтому существует вероятность, что наша группа просто подкрепляет свои собственные предубеждения. Но начать с чего-то нужно, и оценка того, как люди пишут код, кажется вполне уместной. Самое интересное начнется тогда, когда мы получим возможность сравнить результаты проведенного нами анализа с результатами работы отобранных кандидатов. Вот почему мы основали компанию.
Дальше мы хотим поэкспериментировать и выдать кандидатам задания, которые они должны будут сделать в свободное время (я убежден, что такой подход позволит соискателям справиться с волнением). Также есть мысль просить кандидатов поработать с уже существующей кодовой базой. Еще мы добавляем в тест более сложные вопросы, чтобы посмотреть, сможем ли мы повысить его эффективность.
В ранней версии поста были перепутаны коэффициенты корреляции R и R2, потому результаты оказались завышенными. С момента публикации поста мы усложнили тест, что увеличило коэффициент корреляции до 0.69 (0.47 R2).
Примечания:
- Это сложный вопрос. Есть мнение, что опытные программисты должны попадать на собеседование без очереди, минуя отбор, чтобы каждый раз не доказывать свои умения. Личных достижений должно быть достаточно. Однако такая система должна быть организована с умом, чтобы на собеседования могли попасть все, а не только бывшие сотрудники определенных компаний или выпускники определенных школ. Оценка опыта программиста – это наш следующий шаг, но сейчас мы занимаемся оценкой навыков.
- Стоит отметить погрешности (95%-й доверительный интервал). Истинное значение на графике для каждого сравнения попадает в 95%-й доверительный интервал. Значение погрешности оказалось таким большим, потому что у нас была маленькая выборка. Однако, сравнивая нижний предел нашего доверительного интервала с результатами исследования Элин Лернер (корреляция в ее исследовании была практически равна 0), мы видим, что электронный тест показал себя лучше, чем резюме.
© Megamozg
