А у вас тоже уже глаз дергается от пузырьковой сортировки и балансировки красно-черных деревьев?
Наём — это решение задачи с двумя неизвестными. Работодатель оценивает кандидата по его резюме, портфолио, тестовому заданию и общению на собеседованиях, но всё равно не может быть до конца уверен в том, что нашёл подходящего сотрудника. Кандидат выбирает работодателя по HR-бренду, описанию вакансии, может запросить в LinkedIn отзыв у сотрудника компании, но на 100% понимает, подходит ли ему рабочее место, только спустя пару месяцев после трудоустройства.
В результате ситуация дискомфортна для обеих сторон: компании тратят много сил и времени на поиск квалифицированных кадров, ошибки найма стоят дорого, а специалисты страдают от переусложнённого отбора.
Рассмотрим, как выглядит наём глазами обеих сторон и попытаемся понять, может ли ситуация измениться в будущем.

*Дисклеймер: ничью сторону не занимаем, просто рассуждаем и пытаемся найти точки взаимопонимания.
Почему соискатели горят из-за собеседований
При общении с потенциальными работодателями в поисках новой работы, любой специалист уровня Middle или Senior сталкивается с моментами, о которых с грустью рассказывает друзьям.
Очевидные вопросы
«Какие типы данных есть в этом языке программирования?» или «Что выдаст этот очевидно неверно написанный код?». У автомехаников вряд ли спрашивают, в какую сторону закручивается гайка — мидлы с синьорами так же недоумевают в ответ на подобные вопросы.
Теоретические вопросы, незнание которых ни на что не влияет
В повседневной работе специалист использует три/семь/десять технологий и прекрасно в них разбирается. Когда ему нужен новый инструмент, он осваивает его за несколько дней чтения документации (если это не что-то фундаментальное). Но если на собеседовании он не напишет пузырьковую сортировку или не вспомнит, как балансировать красно-чёрное дерево, о котором он в последний раз слышал в вузе, работодатель может посчитать его компетенции недостаточными.

А решение алгоритмических задач, которые нередко дают на собеседованиях, демонстрирует исключительно способность решать алгоритмические задачи. Специалист, который работает с алгоритмом сортировки данных, легко его напишет. Но в повседневной жизни действительно сложные алгоритмы пишут те, кто делает поисковые движки, работают с геоданными, хайлоад-проектами или занимаются суперхардовой оптимизацией на C++/C. И если специалист проходит собеседование не на проект подобного уровня, он может не написать алгоритм, потому что в рабочей рутине он ему не был и не будет нужен.
По этой же причине раздражает этап пре-скрининга, на котором эйчар полчаса зачитывает с листочка технические вопросы и ставит галочки да/нет.
Вопросы сложнее задач, которые нужно решать после трудоустройства
Нередко компании ищут уникального специалиста на решение чуть более чем рядовых задач, и на этапе отбора задают такие вопросы, словно ему предстоит собственноручно построить марсоход. Но когда специалист проходит пять уровней собеседований и LeetCode, может оказаться, что рабочие задачи заключаются в перекладывании JSONов. Или, например, у него спрашивают об архитектурной разнице между Kafka и RabbitMQ, а потом оказывается, что на проекте нет ни того, ни другого.

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

Но есть и другая точка зрения.
Почему работодатели переусложняют отбор
Во-первых, чаще всего компания нанимает специалиста в штат, а не на конкретный проект. Чем крупнее компания, тем выгоднее ей создать универсальный опросник под специальность или роль, потому что кастомизировать вопросы под отдельные проекты — чрезмерно трудозатратно. Кроме того, в аутсорс-компаниях бывает ротация между проектами, поэтому при отборе в начале спрашивают о том, что может понадобиться везде, а специфику дают на последних этапах. Отсюда возникают вопросы о технологиях, которые могут не встретиться в работе и на которые могут не знать ответов специалисты, уже работающие в компании.
Во-вторых, при выборе между риском нанять некомпетентного сотрудника и ресурсными издержками, работодатели выбирают второе. Чем выше уровень вакансии, тем выше риски при найме нового специалиста, ведь цена ошибки синьора может быть очень высока для бизнеса и его клиентов. Поэтому компания больше времени тратит на его поиск и валидацию. Работодатель может растянуть этапы отбора на несколько недель или месяцев, чтобы оценить навыки и способности кандидата со всех сторон и избежать ошибки найма.
В третьих, мидлы, синьоры и лиды иногда не те, кем кажутся. Поработав несколько лет в одной компании, специалист может закономерно стать лидом, но при этом ему будет не хватать навыков, чтобы занять позицию лида или даже синьора в другой компании. В рынке нет унифицированной системы грейдов, поэтому во время отбора работодателю нужно досконально изучить кандидата, чтобы присвоить ему грейд в своей системе координат.
Что в итоге
Каждая сторона преследует свои интересы и имеет право на своё мнение. Конфликт очевиден: кандидаты не хотят тратить время на многоэтапные собеседования и не любят, когда их способности оценивают по энциклопедическим знаниям, а работодатели хотят минимизировать ошибки найма.
Однако, как любая подвижная система, наём постепенно эволюционирует. И вот несколько идей, как можно сделать его более комфортным для кандидатов и не потерять в качестве отбора.
Перейти от экзаменационного формата собеседований к разговорному
Все большую популярность набирает формат System Design Interview. Например, бэкенд-разработчику дают задачу спроектировать сокращатель ссылок. И рассказать, как он будет выстраивать архитектуру, какие технологии и компоненты использует, где придумает оптимизацию. Кто-то предлагает сразу масштабировать по железу и даже по стоимости.
Соискатели хорошо реагируют на этот формат — разговор почти по душам приятный и менее стрессовый, на YouTube можно найти mock-interview и подготовиться. А интервьюерам он показывает системность мышления и кругозор кандидата, помогает найти коллегу, который думает похожим образом и с которым будет приятно работать в команде. У этого тренда есть все шансы стать популярнее, чем написание кода на бумажке без Гугла.
Проявить гибкость при оценке кандидатов
На собеседовании адекватно спрашивать у кандидата о том, приходилось ли ему работать с технологией, понимает ли он, что это такое и зачем нужно. Но оценивать ответ надо гибко. Если он не знает о ней просто потому, что ещё не использовал, но при этом по пулу его навыков очевидно, что при необходимости он способен освоить ещё один, нет смысла ставить на нём крест.
Предлагать нестандартные задачи
Например, мы даём математическую задачу уровня третьего класса и просим воплотить её в коде. Это позволяет оценить ход мышления и уровень рассуждений кандидата. А задачи категории сортировок показывают только знания этих алгоритмов, которые никому не приходится писать заново, потому что они уже реализованы на всех языках.
Собирать обратную связь
Хорошая идея — запрашивать фидбек о собеседовании у кандидатов (по крайней мере у тех, кто получил оффер). Как тебе вопросы, не было ли слишком скучно или хардкорно, что бы ты добавил или убрал. Ведь при поиске работы специалисты сравнивают общение с разными компаниями, и делают выбор в том числе на основе того, с кем больше понравилось общаться.
Мы считаем, что человекоориентированный наём — конкурентное преимущество для IT-компании, поэтому перманентно работаем над компромиссными решениями.
А вы как думаете, может ли наём в IT стать проще, и, если да, то за счёт чего?
Комментарии (24)
abryazgin
23.01.2025 09:37А какие ваши предложения? Как компании убедиться, что кандидат не запутается в трёх логических условиях алгоритма? Давать задачу на булеву алгебру?
Тот же пример сортировки, даёт возможность увидеть как мыслит человек, даже если не знает алгоритма. Это самое ценное в вопросе про сортировку. А так да, можно вызубрить её решение и говорить, что это бесполезная задача.
Не всё рабочие задачи требуют алгоритма сортировки. Но вот понимание сложности выполнения алгоритма и что есть способы решить ту же задачу эффективнее - важны.
Хотя не всегда. Компьютеры мощнее, о производительности продукта можно не думать).
petropavel
23.01.2025 09:37Когда нанимают водителя, не проверяют же, как он мыслит на круглых люках. И не смотрят на его уровень в Carmageddon.
Мой подход не универсальный, у нас особый случай. Open Source проект, открытый баг-фиче-трекер. Я просто даю ссылку на тикет и прошу сделать фичу. Проверка на реальной боевой задаче.
на самом деле, не "просто". это должна быть фича, которую мы точно не хотим в релиз, и я перед этим её делаю сам, мне надо при этом уложиться в 5-10 минут. обычно это строк 10-15 максимум добавить или скопировать.
Потом интервью, обсудить. Если есть гитхаб и там достаточно кода — можно тестовое пропустить.
AdrianoVisoccini
23.01.2025 09:37Писал уже пару раз, напишу ещё - мы с коллегой раздумывали над способом проверки кандидатов без использования "100 золотых вопросов по java" и вот к чему пришли:
Делаем тестовый проект который будет отдаленно напоминать функционал будущего проекта, само собой в СИЛЬНО упрощенной форме - пару ендпоинтов, контроллер и сервисы к ним, десяток сущностей, базу там ну и прочее что в стеке используется просто в виде наброска, так сказать широкими мазками. Все пакуем в докер, пишем ридмишку как быстро все поднять и закидываем в гит репозиторий
Зовем нового кандидата. Перед интервью придумываем 1-2 задачи. Задачи должны быть простыми из разряда "добавить новый эндпоинт с такой-то логикой" или "переделать логику работы сервиса с учетом того-то" или "заменить поле в сущности на Enum и внести правки дто, мапперы и сервис" итд.
Дальше просто подключаемся по видеосвязи, даем кандидату ссылку на репу и просим сделать гит клон. Сначала говорим что в общих чертах делает приложение и как оно работает, а потом просим его разобраться с проектом. Тут он будет рассказывать общие вещи вроде "это слой с api работает так то и так то" "тут контроллер api он вот так связывает эндпоинты с сервисом" "это сервисный слой он тут туда сюда мапер, энтити и в базу" и так далее. В процессе как раз можно обсудить теоретические вопросы по архитектуре и прочему именно в виде обсуждения, мол а как бы ты это сделал а как бы ты то сделал.
Дальше даем задачу и разрешаем использовать гугл абсолютно не стыдясь, пусть будет как на работе. В процессе спрашиваем почему так или не так, подкидываем мысли, смотрим возникают ли вопросы по неполному ТЗ. Там же будет видно, человек IDE пользоваться умеет? Шорткаты там всякие делает? Как код читает на уровне мидла или сениора? и так далее. Если задачу нормально сделал пусть пушит её в репо, таким образом следующим людям будет дан уже изменившийся проект, другие задачи итд, а это значит бесконечная вариативность и практически исключает возможность подготовиться к вопросам заранее.
Кстати задачи на то что бы такого сделать можно просить генерить кандидатов на аналитиков, а декомпозировать их кандидатов на тех лидов и сениоров.
итого вокруг одного проекта вы получаете возможность проверить реальные навыки человека в реальной работе, пообщаться и посмотреть как он задачи принимает и как решает, даже что и как он гуглит. Нет смысла "сливать вопросы к собеседованию" по тому что они всегда разные будут и если у двух людей подряд еще хоть немного похож проект то у 1 и 10 кандидата уже все будет разное.
Надеюсь кто-то услышит и решит внедритьlightmaann
23.01.2025 09:37Хорошая идея, если бы я был java разработчиком, я бы одобрил. Мы делали несколько иначе, но с тем же смыслом:
Брали реальный кусок сайта, отрезали его от всех зависимостей, специально засирали код, как могли. Давали этот кусок кандидату, и он уже в привычной среде пытался делать код-ревью, что-то комментировать, исправлять. Сразу становится понятно, как долго человек работал, насколько быстро и глубоко вникает в проблемы, в специфику, а там уже можно и пообщаться подробнее. При этом всё также в формате live-coding.
ZloyLis
23.01.2025 09:37Из десятков собеседований у меня было только одно, где проверяли не память, а навык рассуждать и уметь находить решения. Хотя, перед этим ознакомились с пет-проектами.
Интервьюер не заваливал вопросами, не пытался давить. Он просто рассказал про команду, задачи и описал общий процесс работы. После чего мы ненавязчиво перешли к собеседованию в стиле - а давай представим, что нам с тобой нужно реализовать приложение для учета горюче-смазочнвх материалов на АЗС (далее шло условное ТЗ) и мы начали думать (вдвоем!!!). Накидали диаграмму условной бизнес-логики, потом плавно перешли к реализации некоторых задач. Это было самое длинное, но самое шикарное интервью. Интервьюеру не были интересны мои академические знания или то, как я вызубрил мифическую базу. Он не пожалел времени, чтобы выяснить мой скилл поиска решений и информации. И, кстати, было видно, что ему и самому интересен такой процесс прощупывания соискателя. В итоге, я с околонулевыми знаниями зашел в команду и проработал там пару лет. Команда тоже оказалась офигенной, продуктивной и в какой-то мере фанатичной и тоже многие вошли так же, как и я - с околонулевыми знаниями и росли как спецы уже на проекте. Побольше бы таких вникающих и проницательных специалистов на собесах и тогда жить стало бы проще. Действительно тупые соискатели отсеивались бы автоматически, а люди с перспективами в недалеком будущем, но околонулевыми знаниями сейчас - спокойно заходили бы на позиции.
senchik
23.01.2025 09:37У каждого даже студента есть некоторый багаж знаний и наработок, которые он может предоставить. Так что вы все занимаетесь редкостным бредом, вместо того что бы реально посмотреть наработки и оценить, что человек из себя представляет, дело 5 минут. Всë что вы описываете это когда человек приходит как чистый лист и говорит, что у него ничего ещë нет за плечами... И тут вопросы сразу, а нужен ли вам он?
xrteee
23.01.2025 09:37Все большую популярность набирает формат System Design Interview. Например, бэкенд-разработчику во время него дают задачу спроектировать сокращатель ссылок.
Все большую популярность набирает формат System Design Interview. Например, бэкенд-разработчику во время интервью дают задачу спроектировать сокращатель ссылок.
Пожалуйста, поправьте, а то кажется что бэкенд-разработчику во время бэкенд-разработчика дают задачу
Slaiter89sp
23.01.2025 09:37Особенно забавно что теперь и у QA Automation тоже стали спрашивать алгоритмы, и говорят вы не пугайтесь там алгоритмы не сложнее medium на leetCode.
Интересно было бы услышать хоть один пример где бы он мог понадобиться QA Automation.questpc
23.01.2025 09:37Скорее всего по большинству направлений избыток предложения рабочей силы. Кроме самых сложных. Последствие массовой компьютеризации 90х и особенно 2000х, когда дети все более массово росли с компьютерами. А ниши наоборот закрыты все больше, основные виды программ и движков давно написаны. Перегрев рынка, помноженный на экономические причины.
51scorp
23.01.2025 09:37В РФ никакого избытка нет.
Избыток только джунов после курсов, а если в твоей компании только фулл офис сомнительного качества, будешь по 1 человеку в год нанимать. Или студентов на стажировку.
questpc
23.01.2025 09:37По личному опыту найти хорошие подработки последние годы стало много сложнее.
Раньше было так - захотел подработать поискал по своей специализации, откликнулся - сразу милости просим. Причем без всяких технических интервью, без тестовых заданий.
Сейчас - чаще всего вообще не отвечают. Плюс очень мало предложений без тестовых заданий и технического собеседования.
Градация на джуны, миддлы и сеньоры меня вообще умиляет. Тот же Билл Гейтс, много лет проработавший и незакончивший университет неоднократно говорил в интервью что самый лучший способ изучить чего-то это не лекции и не учебные задания а обучение в ходе выполнения настоящих реальных задач. Он именно так сам начинал программировать, до того как раскрутил свою корпорацию. Сейчас объявили бы дружом и никуда не взяли.
Плюс страшная вешь что когда возраст старше 50 многие начинают шарахаться - разрыв поколений.
sci_nov
23.01.2025 09:37Почему переусложнен найм? Думаю, потому что сама по себе отрасль сложная.
1755
23.01.2025 09:37Интересно, а при найме условного терапевта в клинику спрашивают у него "с какой стороны у человека сердце", чтобы подловить и сказать "ха, но ведь бывает..." или "опишие алгоритм проведения нейрохирургической операции" и недовольно прокачивать головой, когда не может?
RegularCoder
23.01.2025 09:37Насмешили. Меня не берут, просто потому что мне полтинник. В ваших мемасах не шарю.
BaJIepoH
23.01.2025 09:37У меня все больше вопросов к рекрутерам:
обратной связи нет, вообще никакой
на собесе присутствуют крайне редко(один раз собеседующие начали обсуждать свой проект, как-будто меня нету и это не обес, просто 20 минут слушал рассуждения)
предлагаемый уровень зп, они вроде должны видеть и понимать, что за оклад в 88к на испытательном девопса - найдут в лучшем случае джуна, а не мидл+
почему не смогли удержать предыдущего сотрудника?
1755
23.01.2025 09:37А решение алгоритмических задач, которые нередко дают на собеседованиях, демонстрирует исключительно способность решать алгоритмические задачи. Специалист, который работает с алгоритмом
Полностью согласен! Систем дизайн интервью куда лучше справляется с оценкой реальной работы человека. Интересно услышать аргументы тех, кто считает ровно наоборот?
Сразу оговорюсь, есть области где это действительно нужно, как, например, знания линейной алгебры нужны для разработчика игровых движков и конкретно для таких позиций ноль вопросов.
Чем выше уровень вакансии, тем выше риски при найме нового специалиста, ведь цена ошибки синьора может быть очень высока для бизнеса и его клиентов
А в чем риски? В том что найдут кандидата, с которым не сработаются и через полгода нужно снова открывать? Ну так это может произойти и с максимально хардскиловым кандидатом, который легко закрывает абсолютно все задачи. Но по другим причинам. Или такой человек начнет фигачить напрямую в прод сомнительный код без проверок? Ну тогда вопрос к процессам внутри компании.
Мне кажется, эти риски закрываются испытательным сроком и нормальным онбордингом. Т.е. взяли кандидата, который показался адекватным как по хард скилам так и по софт скилам, а после онбординга уже сто процентов видно подходит человек или нет.
Kealon
23.01.2025 09:37Тут плюс в том хотя бы, что есть понимание что человек 5 лет не пиво пил (если у него ВО). Ну и алгоритмическую сложность по своему коду должен навскидку представлять.
Но опять же, действительно, для составителя формочек такие знания излишни. Но как вариант, человека владеющего такими знаниями можно сразу отсекать. Работать ему в таком месте будет скучно, придумает ещё что ни будь… Как потом это разбирать если никто не рубит?
inzagher
23.01.2025 09:37Цирк с наймом усложняется с каждым годом, зарплаты деградируют. И, самое главное, почти никого это не смущает, многие продолжают играть по этим правилам.
v_malzam
23.01.2025 09:37"Чукча хитрый однако"(с)
Сначала описание проблем соискателей - поставил лайк.
Потом проблемы галер представлены, как универсальные для рынка - лайк уже не отзовешь.
petropavel
именно!
тоже согласен, это маразм какой-то
wait a minute...