Сто лет собеседований: почему наём в IT так переусложнён
А у вас тоже уже глаз дергается от пузырьковой сортировки и балансировки красно-черных деревьев?
Наём — это решение задачи с двумя неизвестными. Работодатель оценивает кандидата по его резюме, портфолио, тестовому заданию и общению на собеседованиях, но всё равно не может быть до конца уверен в том, что нашёл подходящего сотрудника. Кандидат выбирает работодателя по HR-бренду, описанию вакансии, может запросить в LinkedIn отзыв у сотрудника компании, но на 100% понимает, подходит ли ему рабочее место, только спустя пару месяцев после трудоустройства.
В результате ситуация дискомфортна для обеих сторон: компании тратят много сил и времени на поиск квалифицированных кадров, ошибки найма стоят дорого, а специалисты страдают от переусложнённого отбора.
Рассмотрим, как выглядит наём глазами обеих сторон и попытаемся понять, может ли ситуация измениться в будущем.
*Дисклеймер: ничью сторону не занимаем, просто рассуждаем и пытаемся найти точки взаимопонимания.
Почему соискатели горят из-за собеседований
При общении с потенциальными работодателями в поисках новой работы, любой специалист уровня Middle или Senior сталкивается с моментами, о которых с грустью рассказывает друзьям.
Очевидные вопросы
«Какие типы данных есть в этом языке программирования?» или «Что выдаст этот очевидно неверно написанный код?». У автомехаников вряд ли спрашивают, в какую сторону закручивается гайка — мидлы с синьорами так же недоумевают в ответ на подобные вопросы.
Теоретические вопросы, незнание которых ни на что не влияет
В повседневной работе специалист использует три/семь/десять технологий и прекрасно в них разбирается. Когда ему нужен новый инструмент, он осваивает его за несколько дней чтения документации (если это не что-то фундаментальное). Но если на собеседовании он не напишет пузырьковую сортировку или не вспомнит, как балансировать красно-чёрное дерево, о котором он в последний раз слышал в вузе, работодатель может посчитать его компетенции недостаточными.
А решение алгоритмических задач, которые нередко дают на собеседованиях, демонстрирует исключительно способность решать алгоритмические задачи. Специалист, который работает с алгоритмом сортировки данных, легко его напишет. Но в повседневной жизни действительно сложные алгоритмы пишут те, кто делает поисковые движки, работают с геоданными, хайлоад-проектами или занимаются суперхардовой оптимизацией на C++/C#. И если специалист проходит собеседование не на проект подобного уровня, он может не написать алгоритм, потому что в рабочей рутине он ему не был и не будет нужен.
По этой же причине раздражает этап пре-скрининга, на котором эйчар полчаса зачитывает с листочка технические вопросы и ставит галочки да/нет.
Вопросы сложнее задач, которые нужно решать после трудоустройства
Нередко компании ищут уникального специалиста на решение чуть более чем рядовых задач, и на этапе отбора задают такие вопросы, словно ему предстоит собственноручно построить марсоход. Но когда специалист проходит пять уровней собеседований и LeetCode, может оказаться, что рабочие задачи заключаются в перекладывании JSONов. Или, например, у него спрашивают об архитектурной разнице между Kafka и RabbitMQ, а потом оказывается, что на проекте нет ни того, ни другого.
Иногда есть ощущение, что синьоры, уже работающие в компаниях, могут не знать ответов на каверзные вопросы, которые задают кандидатам на собеседованиях.
Кажется, это не единственная история
Но есть и другая точка зрения.
Почему работодатели переусложняют отбор
Во-первых, чаще всего компания нанимает специалиста в штат, а не на конкретный проект. Чем крупнее компания, тем выгоднее ей создать универсальный опросник под специальность или роль, потому что кастомизировать вопросы под отдельные проекты — чрезмерно трудозатратно. Кроме того, в аутсорс-компаниях бывает ротация между проектами, поэтому при отборе в начале спрашивают о том, что может понадобиться везде, а специфику дают на последних этапах. Отсюда возникают вопросы о технологиях, которые могут не встретиться в работе и на которые могут не знать ответов специалисты, уже работающие в компании.
Во-вторых, при выборе между риском нанять некомпетентного сотрудника и ресурсными издержками, работодатели выбирают второе. Чем выше уровень вакансии, тем выше риски при найме нового специалиста, ведь цена ошибки синьора может быть очень высока для бизнеса и его клиентов. Поэтому компания больше времени тратит на его поиск и валидацию. Работодатель может растянуть этапы отбора на несколько недель или месяцев, чтобы оценить навыки и способности кандидата со всех сторон и избежать ошибки найма.
В третьих, мидлы, синьоры и лиды иногда не те, кем кажутся. Поработав несколько лет в одной компании, специалист может закономерно стать лидом, но при этом ему будет не хватать навыков, чтобы занять позицию лида или даже синьора в другой компании. В рынке нет унифицированной системы грейдов, поэтому во время отбора работодателю нужно досконально изучить кандидата, чтобы присвоить ему грейд в своей системе координат.
Что в итоге
Каждая сторона преследует свои интересы и имеет право на своё мнение. Конфликт очевиден: кандидаты не хотят тратить время на многоэтапные собеседования и не любят, когда их способности оценивают по энциклопедическим знаниям, а работодатели хотят минимизировать ошибки найма.
Однако, как любая подвижная система, наём постепенно эволюционирует. И вот несколько идей, как можно сделать его более комфортным для кандидатов и не потерять в качестве отбора.
Перейти от экзаменационного формата собеседований к разговорному
Все большую популярность набирает формат System Design Interview. Например, бэкенд-разработчику во время него дают задачу спроектировать сокращатель ссылок. И рассказать, как он будет выстраивать архитектуру, какие технологии и компоненты использует, где придумает оптимизацию. Кто-то предлагает сразу масштабировать по железу и даже по стоимости.
Соискатели хорошо реагируют на этот формат — разговор почти по душам приятный и менее стрессовый, на YouTube можно найти mock-interview и подготовиться. А интервьюерам он показывает системность мышления и кругозор кандидата, помогает найти коллегу, который думает похожим образом и с которым будет приятно работать в команде. У этого тренда есть все шансы стать популярнее, чем написание кода на бумажке без Гугла.
Проявить гибкость при оценке кандидатов
На собеседовании адекватно спрашивать у кандидата о том, приходилось ли ему работать с технологией, понимает ли он, что это такое и зачем нужно. Но оценивать ответ надо гибко. Если он не знает о ней просто потому, что ещё не использовал, но при этом по пулу его навыков очевидно, что при необходимости он способен освоить ещё один, нет смысла ставить на нём крест.
Предлагать нестандартные задачи
Например, мы даём математическую задачу уровня третьего класса и просим воплотить её в коде. Это позволяет оценить ход мышления и уровень рассуждений кандидата. А задачи категории сортировок показывают только знания этих алгоритмов, которые никому не приходится писать заново, потому что они уже реализованы на всех языках.
Собирать обратную связь
Хорошая идея — запрашивать фидбек о собеседовании у кандидатов (по крайней мере у тех, кто получил оффер). Как тебе вопросы, не было ли слишком скучно или хардкорно, что бы ты добавил или убрал. Ведь при поиске работы специалисты сравнивают общение с разными компаниями, и делают выбор в том числе на основе того, с кем больше понравилось общаться.
Мы считаем, что человекоориентированный наём — конкурентное преимущество для IT-компании, поэтому перманентно работаем над компромиссными решениями.
А вы как думаете, может ли наём в IT стать проще, и, если да, то за счёт чего?
