ТОП ошибок тех. интервьюеров01.08.2024 08:15

За последние 2 года я провел множество тех. собесов, но после статьи @AlfaTeamдолго думал »‎мне есть что сказать» или лучше помолчать. В итоге таки решил описать типовые ошибки интервьюеров, которые я не замечал «до»‎, но стал замечать «после»‎ этого марафона собесов.

Вводные

• Место действия: финтех галера

• Дано: 1 тех. этап и 1 час времени.

• Ожидаемый результат: 4 варианта грейда и общие рекомендации к отделам, куда может подойти кандидат.

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

Стандартизация подхода

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

• нужен список типовых вопросов и задач;

• нужна стандартизированная анкета результатов;

Таким образом, кто бы не проводил собеседование, его качество будет примерно одного уровня и отзыв от Пети, Васи, Маши становится более непредвзятым. У всех участников в голове +/- одна и та же линейка.

ТОП ошибок у интервьюеров

Читает по порядку вопросы, как на допросе

Нет междометий, нет шуток, нет какой-то лёгкости разговора. Ощущение, что беседу ведёт робот. Это создаёт неприятно впечатление. Если у вас не получается сходу выйти из этого режима, можете подготовить список фраз разрядки, чтобы пробовать вставлять их в диалог. Например:

• «да, всё так, а что скажешь по поводу…»‎

• «ага, есть такая особенность, а приходилось иметь дело с …»‎

• «да, почему бы и нет, можешь ещё сказать пару слов о …»‎

Года два назад, на собесе в Тиньке, мне попалось два таких парня-робота. В итоге в середине собеса я просто его прервал, сказав, что мне не особо интересно и можем не тратить время. Этот пунктик загона часто идёт в паре со следующим.

Выбивает конкретный ответ или решение

Докапывается до незначительной мелочи (типа отсутствия запятой), даже если понимает, что решение в целом верное. Это плохо, т.к. мало кто угадает формулировку задуманную автором и это не будет отражать реальные знания человека по данному вопросу. Например:

• Собес Яндекса. Задача про какой-то обход дерева. В целом все готово, но интервьюера есть два пункт «должно запуститься» и «нельзя дебажить». Чувака переклинило, и мы 30 минут ищем опечатку (пропустил запятую). При том, что я согласен был просто пропустить задачу и взять следующую, чтобы не терять время. Это было похоже на какой-то приступ ОКР.

• Ещё один такой же случай произошел через год, в другом месте на задаче про бинарный поиск. Там интервьюер уже сам начал искать опечатку и дебажить, т.к. не понимал почему решение не проходит один тест, хотя он видит, что оно верное. Потратили 15 минут (знак +/- перепутал).

Опрашивает по одной теме в глубину всё отведенное время

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

ВК или Яндекс, может выделить один из N-этапов, чтобы разобрать конкретные навыки в интересующей их области. Так, например, в ВК у меня было два собеса, на одном из которых мы час писали регулярки, а на втором 1.5 часа разбирали способы сжатия и оптимизации кода. Это было нормально, поскольку этапов много и ищут узкую специализацию. Но если вам нужен специалист широкого профиля в какой-то типовой отдел галеры с фиксированным грейдом, то вы просто не сможете сказать сможет он «в среднем писать приемлемый код» или нет, придерживаясь данной тактики интервью.

Заканчивает на негативной ноте, оставляя плохое послевкусие от процесса.

Это важный пункт, которые многие не понимают. Тут три фактора:

• с точки зрения соискателя он испытывает стресс;

• с точки зрения психологии, последняя эмоция остаётся самой яркой в памяти;

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

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

Неоднократно наблюдал странный резкий переход, когда посреди неспешного диалога у человека включается режим робота, который понимает, что нужно срочно задавать технический вопрос, который к этому моменту может вообще быть не связан с темой дискуссии. Поэтому лучше придерживаться модели бутерброда (позитив-негатив-позитив). Пример:

• начинаем с легких коротких вопросов и задач
  Через пять — десять минут человек расслабляется по мере ответов. Ему становится комфортно от того, что процесс идёт, а мы начинаем немного увеличивать сложность.

• далее выводим его на сложные вопросы и задачи
  Скорее всего кандидат поплывет. Середина интервью будет самым негативным местом и займёт больше всего времени.

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

Не спрашивает об интересных проектах

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

• кандидат 4 года в Сбере пишет перекладчик JSON-ов и это уже стало работой на мышечной памяти;

• в свободное время занимается своим ML проектом на github на 1000 звёзд или пишет шейдеры к моду Minecraft;

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

Подбирает сложную задачу

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

Потом я попал один из собесов Яндекса, который закончился за 20 минут с супер простой (как мне казалось) задачей. Я спросил у интервьюера, почему он дал такую легкую задачку? А он ответил, что она вполне норм, достаточно бытовая и больше половины валится на ней или начинают писать бред. После этого на своих собесах я старался давать простые задачи и если человек их решал, просто добавлял условие. Оказалось это реально клевый подход, чтобы на ходу вести в ту или иную сторону (по мере ответов) или оборвать затянувшееся решение (если кандидат начал буксовать), не расстраивая кандидата.

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

for (var i = 0; i < 2; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000);
}

• запрещаем трогать var;

• запрещаем писать замыкания (IIFE);

• запрещаем прокидывать 3й аргумент;

• просим убрать for в явном виде и как-то иначе вызвать N раз;

• и т.п.;

Такими маленькими задачами можно не только гибко оценить глубину по каждой теме, но и получить кучу лулзов. Пример решения подобной простой задачи от «синьора помидора, 12 лет опыта»‎:

404, так сказать

Ожидает что опыт соискателя в резюме равен его знаниям

Иногда люди долго работают, но их проекты были максимально типовыми (формошлёпство и CRUD`ошлёпство), а сами они НЕ брали чего-то больше, чем было нужно по работе (чтение статей, книг, просмотр видео, домашние проекты). В итоге Middle+/Senior Яндекс разработчик выдает такой способ убрать дубликаты из массива:

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

Как искать зоны компетенций и оценить кругозор

Я предлагаю кандидату блиц в формате да/нет и заполняю такую таблицу:

Далее выбираю пару пунктов, в которых был опыт и задаю несколько вопросов в глубь (но всё ещё поверхностных). Например, для UI-кита:

• таблицу или Select реализовывали?

• есть какие-то моменты, которые важны?

• давайте придумаем список типовых props?

• давайте придумаем список фич для таблицы?

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

Хорошо идут общие открытые вопросы, например: «как ускорить загрузку?» или «расскажите что-нибудь про безопасность?». Желательно иметь список аналогичный тому, который выше. Если кандидат на блице выбрал какое-то направление, вы можете сразу достать «открытый вопрос» и посмотреть насколько глубоко он может рассказать тему.

Итого

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

• Три плюса / три минуса. Когда по порядку или детализации ответов пытаешься понять, склонен человек к чему-то или нет.

А что вас бесит на тех. интервью?

© Habrahabr.ru