«Почему я должен делать ваше тестовое?» Инженер Wargaming о сложных собеседованиях

Представьте, вы начинаете диалог с рекрутером, и тут оказывается, что на пути к офферу шесть ступеней собеседований: и с эйчаром, и с Head of Engineering, и с CFO, и с бизнес-партнёрами. При этом между ними — значительные временные промежутки, а по окончании всех этапов компания берёт время на размышления, потому что у неё ещё 15 кандидатов в процессе. В итоге трудоустройство может растянуться на три месяца.

Я сам однажды столкнулся с таким подходом. Собеседовался на должность Senior Delivery в небольшую западную аутсорс-компанию, открывшую представительство в Минске. Общение на отдельных этапах было конструктивным, после каждого я получал обратную связь, но в конце концов мне сказали: «Ты нам понравился, правда у нас ещё несколько человек, поэтому жди». Я не видел смысла ждать и написал: сорри, ребята, но так это не работает. К тому времени, как они кого-то выбрали, я уже устроился в Wargaming.

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

Усложнять интервью имеет смысл на этапе проверки хард-скилов. Когда на интервью просят рассказать про свой опыт, это нормально. Но велика вероятность ошибочных выводов, ведь порой разработчик рассказывает о своих проектах, не фокусируясь на деталях: перечисляет технологии, которые использовала команда, хотя лично с ними не работал. Допустим, он говорит, что его команда делала распределённую систему и на бэкенде использовала MongoDB — какой из этого можно сделать вывод? Если сам кандидат на MongoDB не работал, то ожидать опыта работы с этой системой от него не стоит.

Поэтому в процессе собеседования полезно предложить соискателю решить конкретную задачу, актуальную для компании. Допустим, в Wargaming мы хотим «мигрировать» базу данных игроков, желательно бесшовно и без простоев, как это сделать? Обдумывая решение и задавая уточняющие вопросы, соискатель показывает, как он умеет структурно мыслить. В процессе рассуждения над задачей он может уточнить детали и требования. Допустим, выясняется, что в базе пользователей 130 млн человек — ага, это накладывает ограничения на выбор фреймворков, языка, базы. 

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

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

В ходе собеседования мы стараемся пройтись по всем аспектам T-shaped person: оценить не только то, как как человек умеет писать код на Python или Elixir, но и то, понимает ли он их структуру, работал ли он с Docker или Grafana, представляет ли, как его приложения живут в продакшн и т. д. 

Усложняет ли это интервью? Вполне вероятно, поскольку мы задаём много вопросов из смежных областей (QA, DevOPS, администрирование). Но это также позволяет кандидату понять, с чем он столкнётся на рабочем месте, а осознанность повышает лояльность кандидата: ну да, ребята знают, чего хотят. 

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

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

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

Во-первых, если речь о серьёзном тестовом задании для сеньора, когда он будет его выполнять? По вечерам, на выходных? Но сложное задание займёт не один уик-энд! Кандидат ведь не безработный, который мыкается в поисках работы и больше ничего не делает. 

И потом, какие у компании могут быть аргументы? Почему я должен делать ваше тестовое задание? Бла-бла… Ребята, серьезно? Это поможет вам оценить качество моего кода? Вот мой код на GitHub — посмотрите. Это позволит вам оценить мои технические решения? Так давайте поговорим о них сейчас. Любое задание — это моё время, а рынок сейчас такой, что любой толковый разработчик за три недели найдёт нужную ему работу.

Сейчас, пожалуй, только Google может себе позволить тестовые задания, потому что туда все хотят.

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

Новый рекламный формат в наших телеграм-каналах.

Купить 500 символов за $150