От чата с рекрутером до оффера за несколько дней

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

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

  1. Чат с рекрутером
  2. Автоматизированный тест кодирования
  3. Техническое интервью
  4. Последующий чат с менеджером и командой, устное предложение

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

Давайте рассмотрим каждый шаг.

Шаг 1. Общайтесь с рекрутером

В этом шаге не было ничего особенного; он был направлен на то, чтобы отфильтровать кандидатов, которые вряд ли прошли собеседование или искали что-то отличное от того, что предлагала роль, или не подходило.

Рекрутер рассказал кандидату о компании и проекте, объяснил обязанности, спросил об опыте и карьерных устремлениях, объяснил процесс собеседования.

Перспективные кандидаты перешли к следующему шагу.

Шаг 2. Автоматический тест кодирования

На этом этапе отфильтровывались кандидаты, которым было бы сложно реализовать простую задачу кодирования.

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

Шаг 3. Техническое интервью

На этом этапе интервьюеры подтвердили четыре важные вещи о кандидате:

  • если бы они могли кодировать
  • если бы они знали, как проектировать приложения или системы
  • если они подходят культурно
  • если бы они хотели работать с нами

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

Этот шаг состоял из трех частей.

Шаг 3.1. Общие и поведенческие вопросы

Во-первых, нам нужно было:

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

Эта часть обычно занимала около 20 минут. Вот некоторые вопросы, которые задают интервьюеры:

  1. Расскажите о себе. Мы хотели узнать, что кандидат хотел бы рассказать о себе и своем профессиональном опыте.
  2. Почему вы решили подать заявку на эту должность и почему выбрали нашу компанию? Нам нужно было выяснить, что побудило их присоединиться к нам и что они знают и ожидают найти здесь.
  3. Расскажите о вашей нынешней команде. Мы хотели подтвердить, что кандидат хорошо работает в команде.
  4. Расскажите о своем нынешнем руководителе. Цель состояла в том, чтобы убедиться, что кандидат будет конструктивно работать с руководителем.

Я поделился, почему я задаю эти вопросы в другом посте.

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

Шаг 3.2. Вызов кодирования

Затем мы хотели посмотреть, как кандидат:

  • решает проблемы,
  • пишет код,
  • общается,
  • и как они реагируют на подсказки и инструкции.

Задача кодирования требовала лишь базовых навыков программирования, и я видел, как недавние выпускники и опытные инженеры решали ее примерно за 10 минут.

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

Мы ожидали, что эта часть займет около 30 минут, и не возражали давать кандидатам советы и подсказки. Это была возможность для нас понять, как они воспримут обратную связь на работе.

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

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

Шаг 3.3. Задача разработки программного обеспечения

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

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

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

На это мы выделили около 40 минут. Обычно у нас оставалось время с некоторыми опытными кандидатами, чтобы обсудить дизайн системы: как развернуть и запустить это приложение, сделать его масштабируемым, высокодоступным и т. д. Опять же, задача была достаточно простой для этого.

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

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

Шаг 4. Последующая беседа с менеджером по найму и командой

На этом этапе мы более подробно обсуждали проект, команду и роль с кандидатом и могли ответить на его вопросы.

Если все были довольны, мы делали устное предложение.

Обычно мы выделяем на это 30 минут.

Выводы

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