Нужно ли проводить несколько собеседований, чтобы определить, хотим ли мы сделать предложение о работе инженеру-программисту? Вероятно, не для большинства должностей. Многочисленные собеседования только растягивают процесс найма на "обычные" должности разработчиков программного обеспечения, увеличивая нагрузку на рекрутеров и интервьюеров, а также риск упустить лучших кандидатов в пользу более быстрых конкурентов.
Я хотел бы поделиться оптимизированным процессом собеседования с одним техническим интервью. Я использовал его, чтобы заполнить некоторые роли в моей команде за короткое время на конкурентном рынке талантов. Мне нельзя было терять время и нельзя было снижать планку, поэтому я придумал эти шаги:
- Чат с рекрутером
- Автоматизированный тест на программирование
- Техническое собеседование
- Последующий разговор с менеджером и командой, устное предложение
Весь процесс обычно занимал три-четыре рабочих дня для кандидата и экономил время для всех участников. Интервьюеры получали информацию для принятия решения о найме, а кандидат узнавал результат на следующий день после единственного собеседования. Кроме того, шанс, что кандидат отсеется, был невелик.
Давайте рассмотрим каждый шаг.
Шаг 1. Беседа с рекрутером
В этом шаге не было ничего особенного; его цель - отсеять кандидатов, которые вряд ли пройдут собеседование, или ищут что-то отличное от того, что предлагает роль, или не впишутся в нее.
Рекрутер рассказывал кандидату о компании и проекте, объяснял обязанности, спрашивал об опыте и карьерных устремлениях, а также объяснял процесс собеседования.
Перспективные кандидаты переходили к следующему шагу.
Шаг 2. Автоматизированный тест на программирование
На этом этапе отсеивались кандидаты, которым будет сложно справиться с выполнением простой задачи по программированию.
Все наши задачи были простыми, а время на их выполнение было ограничено. Не было смысла заставлять кандидатов тратить часы на решение. Кроме того, мы принимали неоптимальные решения, поскольку на следующем этапе мы снова проверяли навыки программирования и решения задач у успешных кандидатов.
Шаг 3. Техническое интервью
На этом этапе интервьюеры проверяли четыре важные вещи о кандидате:
- умеют ли они программировать
- знают ли они, как разрабатывать приложения или системы
- подходят ли они нам по культуре
- хотят ли они работать с нами
Два интервьюера проводили это интервью, чтобы собрать больше информации и минимизировать неосознанное предубеждение. Мы не хотели добавлять дополнительных интервьюеров, так как это могло напугать некоторых кандидатов и, вероятно, не дало бы нам значительно больше данных.
Этот этап состоял из трех частей.
Шаг 3.1. Общие и поведенческие вопросы
Во-первых, нам нужно было
- узнать больше о кандидате как о человеке и инженере-программисте,
- выяснить, подходит ли он нам по культуре,
- и понять, сможем ли мы предложить им то, что они ищут в плане обязанностей, профессионального роста, карьеры и т.д.
Эта часть обычно занимает около 20 минут. Вот некоторые вопросы, которые задают интервьюеры:
- Расскажите мне о себе. Мы хотели узнать, что кандидат хотел бы рассказать о себе и своем профессиональном опыте.
- Почему вы решили претендовать на эту должность и почему вы выбрали нашу компанию? Нам нужно было выяснить, что побудило кандидата присоединиться к нам и что он знает и ожидает найти здесь.
- Расскажите о вашей нынешней команде. Мы хотели убедиться, что кандидат является хорошим командным игроком.
- Расскажите о вашем нынешнем руководителе. Мы хотели убедиться, что кандидат будет конструктивно работать с руководителем.
О том, почему я задаю эти вопросы, я рассказал в другом посте.
В зависимости от темпа интервью у нас могло остаться время на более поведенческие вопросы, чтобы выяснить, как кандидат справляется с критикой, ошибками, неудачами, справляется с давлением.
Шаг 3.2. Задача по программированию
Затем мы хотели увидеть, как кандидат
- решает проблемы,
- пишет код,
- общается,
- и как они реагируют на подсказки и инструкции.
Задача по программированию требовала только базовых навыков программирования, и я видел, как недавние выпускники и опытные инженеры решали ее примерно за 10 минут.
Кандидаты могли выбрать язык для реализации и использовать интернет для поиска любых функций, классов или синтаксиса языка, как если бы они решали реальную задачу на работе.
Мы ожидали, что эта часть займет около 30 минут, и не возражали против подсказок и советов кандидатам. Для нас это была возможность понять, как они воспримут обратную связь на работе.
Мы поощряли кандидатов задавать вопросы, чтобы прояснить задание, если что-то было непонятно. Мы также хотели увидеть, насколько хорошо они смогут объяснить нам ход выполнения и ход мыслей, чтобы понять их стиль общения и подход к решению проблем.
К концу этой части интервьюеры могли получить представление о том, какой код будет создавать кандидат, будет ли он думать, прежде чем действовать, как он будет общаться и будет ли он хорошо играть в команде.
Шаг 3.3. Задание по проектированию программного обеспечения
Наконец, мы хотели оценить навыки кандидата в области разработки приложений и систем. Мы попросили разработать базовое веб-приложение. Это задание подходит для инженеров-программистов всех уровней. Хотя решения младших и старших курсов будут отличаться, как и их подходы к решению проблем и уровень поддержки и руководства, которые им требуются.
Мы хотели посмотреть, как они исследуют проблему, будут ли они уточнять задачу и задавать нам вопросы, чтобы убедиться, что они проектируют правильно. Мы бы не хотели, чтобы будущие члены команды разрабатывали и внедряли что-то, не спросив у своих коллег по команде обратной связи как можно раньше. Если кандидат мог предложить несколько вариантов дизайна, это было огромным плюсом. Кроме того, если они могли применять соответствующие паттерны проектирования и принципы разработки программного обеспечения, это было идеальным вариантом.
Мы ожидали увидеть проект потенциально рабочего решения, которое будет гибким и может быть расширено и развито. Задание было достаточно простым и могло быть выполнено примерно за полчаса.
Мы выделили на это около 40 минут. Обычно у нас оставалось время для обсуждения с опытными кандидатами дизайна системы: как развернуть и запустить это приложение, сделать его масштабируемым, высокодоступным и т.д. Опять же, задача была достаточно простой для этого.
После собеседования интервьюеры обсуждали, стоит ли делать предложение кандидату. К тому времени мы знали достаточно о навыках, поведении и мотивации кандидата, чтобы принять обоснованное решение.
На следующий день мы обсудили это с рекрутером и сообщили кандидату о результате. Мы сделали это на следующий день, чтобы дать интервьюерам возможность поделиться любыми мыслями и опасениями и избежать поспешных решений.
Шаг 4. Последующая беседа с менеджером по подбору персонала и командой
На этом этапе мы более подробно обсуждали с кандидатом проект, команду и роль и могли ответить на его вопросы.
Если все были довольны, мы делали устное предложение.
Обычно мы планировали на это 30 минут.
Выводы
- Этот процесс собеседования позволял нам за 90 минут оценить твердые и мягкие навыки кандидата и уверенно сделать предложение о работе.
- Этот процесс охватывал все критические аспекты: навыки программирования, навыки разработки программного обеспечения, поведение и мотивацию кандидата.
- Присутствие двух интервьюеров обеспечило наличие более чем одного мнения, и мы могли сравнить наши наблюдения, чтобы снизить вероятность упустить значимые сигналы и, надеюсь, свести к минимуму неосознанную предвзятость.
- Процесс не тратил время кандидатов на многочисленные собеседования, растянутые на несколько дней или недель, и не требовал отслеживания множества кандидатов, проходящих процесс одновременно. Это снизило нагрузку на интервьюеров и рекрутеров и минимизировало риск того, что отличный кандидат уйдет в другую компанию.