Pull to refresh
865.37
OTUS
Цифровые навыки от ведущих экспертов

Как я начал проводить технические собеседования за 30 минут

Level of difficultyMedium
Reading time7 min
Views32K

Задача

За последние несколько лет я значительно изменил свой подход к проведению технических собеседований. Если когда‑то (лет 7 назад) я мог весело и задорно интервьюировать джавистов два часа, то на текущей позиции у меня нет столько времени на каждого кандидата. При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где‑то надо найти. Плюс накинуть 10 минут на переключение между задачами, получается ещё 400 минут (~6.5 часов).

Поэтому я задумался над вопросом повышения эффективности собеседований.

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

Ограничение по времени достаточно сильное, но тем интереснее анализировать свой опыт и искать способы сократить время, необходимое для принятия решения о найме. Ещё раз подчеркну ключевую мысль: чтобы проводить техническое собеседование за 30 минут, мне нужно научиться принимать решение о найме за эти 30 минут. Тогда при умеренной рабочей загрузке, я смогу увеличить длительность собеседования до 50 или 60 минут, чтобы лучше узнать кандидата. А при значительной рабочей загрузке, я смогу тратить 40 минут на собеседование. Да, нужно быть честным: 5 минут на вхождение в режим собеседования (чтение резюме, вход на звонок), 30 минут само собеседование, 5 минут на написание отзыва для HR и выход из режима собеседования. Как вы понимаете, это идеальный тайминг.

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

Ограничения и предварительные требования

Чтобы понять как решать какую-то задачу, нужно понять или сформулировать ограничения:

  1. Я не могу эффективно проводить больше 2 собеседований в день или всего 7 в неделю. Лучше 1 собеседование в день. Иначе я теряю способность понять и почувствовать кандидата.

  2. Длительность собеседования не должна превышать 1 часа в самом экстремальном случае. Это искусственное ограничение. Смысл его прост: если я за час не понял, хочу ли я работать с этим человеком, значит я не хочу с ним работать.

  3. Чтобы что-то оптимизировать, нужно обладать достаточным эмпирическим и теоретическим опытом. Т.е. ставить себе задачу "быстрых" собеседований в начале проекта не слишком разумно. Ставить себе такую задачу через год и после 20-30 собеседований - вполне реально.

  4. Самое важное - после собеседования у вас может быть только 2 ответа: "брать" или "не брать". Никаких "может быть", "если не будет других", "решим позже" и прочее. Провели собеседование - приняли решение.

Предварительные требования к назначенному техническому собеседованию:

  1. Первичный скрининг проводит HR-специалист. На техсобеседование должен попасть только заинтересованный кандидат, которого устроят наши условия работы. С этим прекрасно справится кто-то из HR-отдела.

  2. Кандидат должен быть одобрен мной. После первичного скрининга, я смотрю резюме и даю добро на проведение собеседования.

Предпосылки для оптимизации собеседований

Что же может позволить сократить время на принятие решения? На какие вопросы нужно ответить самому себе, чтобы понять: как принять решение о найме в течение 30 минут?

Понимание требований к кандидату

Первый вопрос, на который нужно ответить, следующий: насколько хорошо я понимаю требования к кандидату?

Я разделяю требования к кандидату на два разных вопроса:

  • Что минимально должен уже уметь кандидат?

  • Чему ему нужно будет научиться?

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

В своей карьере я смог чётко сформулировать эти требования к бэкенд‑джавистам (8 лет руководства разработкой веб‑приложений) и дата‑инженерам (2 года разработки платформы обработки данных).

Понимание требований к кандидату подводит к следующему важному вопросу —

Возможность сформулировать тестовое задание

Хорошее тестовое задание позволяет ответить как минимум на 4 вопроса:

  • как кандидат понимает задание, что коррелирует с тем как он будет понимать требования в дальнейшем

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

  • может ли кандидат выполнять задание до конца

  • как кандидат относится к требованиям, пытается ли их осмыслить, задаёт ли уточняющие вопросы

Сейчас я предпочитаю лайв‑кодинг на 10–15 минут. Самые ценные 15 минут собеседования. Не раз наталкивался на кандидатов, которые прекрасно отвечают на теоретические вопросы, но написать SQL‑запрос на позицию дата‑инженера могут с большим трудом. Нормальный специалист напишет мои тестовые два запроса минут за 5–7 без ошибок и промахов. И это тестовое задание великолепно коррелирует с тем, как люди потом работают. Просто магическим образом по всем 4 пунктам выше.

Раньше я давал джавистам оффлайн‑задание на 30–40 минут, чтобы было что потом обсудить на собеседовании. Опыт и подход был сразу виден. А если кандидат присылал код, который не работал, то как я мог положиться на такого кандидата в работе? Постоянно контролировать наличие ошибок? Нет, спасибо.

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

Ошибки в найме - это норма

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

Допустить мысль о возможности ошибки жизненно важно. При найме можно допустить две ошибки:

  • нанять неподходящего

  • отказать подходящему

Очевидно, что при наличии потока кандидатов пропустить хорошее не так страшно как нанять неподходящего. Даже при отсутствии потока кандидатов лучше не брать неподходящего.

Я не боюсь отказать хорошему кандидату по своим каким‑то формальным критериям. Или в силу личной антипатии, потому что мне с ним ещё работать и работать. Поэтому приходим к тому, что —

Эмпатия и эмоциональный интеллект решают

Чтобы быстро принимать решение, часто необходимо положиться на чутьё. В случае с собеседованиями чутью помогает эмоциональный интеллект. Или ощущение от того, насколько вы сработаетесь с человеком. Иногда с каким‑то очень крутым специалистом невозможно работать в силу его характера. Так зачем оно вам надо? Кандидат должен вписываться в коллектив и команду. А раз уж вы принимаете решение, тогда на ваших плечах, с одной стороны, возможность отказать неприятным кандидатам, а с другой стороны — груз ответственности найти того, кто впишется.

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

Хорошо, разрешили себе полагаться на эмоции («эмоции как данные»), что ещё может помочь быстрее принимать решение?

Вопросы двойного назначения

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

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

Попробуйте сформулировать для себя 2 вопроса, которые позволят вам понять, «выживет» ли кандидат на данной позиции или будет постоянно «тормозить».

Всё вместе и сразу

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

Я думаю, что каждый может дописать ещё несколько предпосылок, но перечисленное выше стало для меня достаточно формальным обоснованием того, что могу принять решение о найме за 30 минут. Если брать прямо точный тайминг, то он будет следующим:

  • 5 минут я рассказываю о проекте и почему мне важно дать тестовые задания

  • 12 минут — тестовые задания

    • Если тестовые задания сделаны плохо, тогда можно сказать «нет» и пойти делать дела дальше. Итого — 17 минут

  • 5 минут кандидат рассказывает о себе

  • 8 минут — теоретические вопросы

    • После 30 минут я точно должен определить для себя «да» или «нет».

    • Если мой ответ кандидату «да», тогда можно продолжить собеседование и познакомиться получше.

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

«Быстрые» собеседования — не миф, но большой объём работы над собой и по анализу проекта и команды.

Хороших вам кандидатов и интересных собеседований!

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

Tags:
Hubs:
Total votes 36: ↑20 and ↓16+10
Comments75

Articles

Information

Website
otus.ru
Registered
Founded
Employees
101–200 employees
Location
Россия
Representative
OTUS