Дисклеймер: статья написана лично мной и затем отредактирована с помощью нейросети — для исправления ошибок и улучшения стиля.

Я искренне не понимаю, почему в найме считается нормой тратить время соискателя.
Сначала — 30-минутное собеседование с HR. Потом, дай бог через неделю, техническое интервью на 1,5–2 часа. Ещё через неделю — знакомство с командой на час. В сумме выходит около четырёх часов чистого времени, и это не считая ожиданий между этапами.

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

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

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

Дополнительно ситуацию усугубляют длинные паузы между этапами. Кандидат теряет контекст, забывает детали предыдущих разговоров, и если в начале он был мотивирован и заряжен, то спустя пару недель ему становится попросту всё равно — возьмут его или нет.

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

Первый этап — HR

Принято считать, что 30-минутный разговор с HR нужен для первичного отсева — мол, с помощью вопросов можно понять, есть ли смысл двигаться дальше.

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

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

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

Если на первых N собеседованиях он честно говорил, что его уволили за конкретный косяк, и конверсия была близка к нулю, то на следующих он уже скажет, что «устал», «не совпали ожидания» или «решил двигаться дальше».
И угадайте что — это будет работать лучше.

Параллельно человек становится увереннее. Исчезает зажатость, выравнивается язык тела, и вероятность «вычислить вкатуна» по неуверенной речи или жестам резко снижается.

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

Второй этап — техничка

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

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

  • чем ссылочный тип отличается от значимого;

  • чем Thread отличается от Task;

  • расскажи про сборщик мусора.

Вы правда думаете, что эти вопросы хоть сколько-нибудь уникальны?
Даже человек, который толком не работал с .NET, после N собеседований будет отвечать на них так, будто у него за плечами несколько лет коммерческого опыта.

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

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

Например:

  • как именно располагаются объекты в памяти;

  • почему структуры нельзя использовать как объект синхронизации.

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

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

И вот тут начинается отдельный цирк.

Начну с лайв-кодинга

Я искренне не понимаю, кто и зачем придумал эту практику. Это, пожалуй, один из самых неэффективных способов оценки разработчика.

Человек и так находится в стрессовой ситуации, а от него требуют писать код не в своём темпе, а под постоянным ощущением дыхания интервьюера в затылок. В таких условиях проверяется что угодно — стрессоустойчивость, умение импровизировать, навык «не теряться» — но точно не то, как человек пишет продакшен-код.

При этом задания могут быть абсолютно произвольными:
от «вот тебе тело функции, я хочу такой вывод — сделай через рекурсию, а теперь передумал, пусть вывод будет другим» до «напиши решение задачи на полный квадрат без использования Math.Sqrt».

Хочется задать простой вопрос: как часто вам приходится делать это в реальной работе?

Не спорю, иногда попадаются адекватные задания, но этого катастрофически мало. В большинстве случаев лайв-кодинг — это не про разработку, а про выступление на сцене с таймером.

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

Такой формат гораздо лучше показывает ход мыслей, опыт и инженерное мышление, чем попытка написать «идеальный» код под давлением.

Третий этап — знакомство с командой

Честно говоря, я не понимаю смысла существования этого этапа. Тебя либо знакомят с бизнесом, либо с командой — и нередко при этом снова просят рассказать о предыдущем месте работы, в третий раз подряд.

Что лично мне даёт знакомство с командой?
На мой взгляд, лид — это лицо команды. Если с лидом у нас взаимное понимание, совпадают ожидания и подходы к работе, то зачем отдельный этап, посвящённый знакомству со всей командой?

Что даёт знакомство с бизнесом?
Зачастую это сводится к абстрактным вопросам в духе: «Как бы вы приоритизировали такие-то задачи?» — при том что подобные вещи уже можно и нужно обсуждать на предыдущих этапах.

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

Этот этап редко даёт новую информацию, но стабильно отнимает ещё час времени — и у кандидата, и у команды. А решаемые им проблемы, по большому счёту, либо уже решены раньше, либо не решаются таким форматом вовсе.

Критикуешь — предлагай

Как я уже говорил, весь процесс спокойно можно свернуть в один этап.
Полностью выкидываем бесполезный третий этап и объединяем HR + техничку в один собеседовательный слот продолжительностью 1,5 часа.

И нет, это не означает, что лид будет тратить своё время впустую.

Как это может работать на практике:

Первые 10–15 минут кандидат разговаривает с HR.
Лид при этом присутствует на встрече с выключенной камерой и микрофоном, параллельно занимаясь своими задачами и слушая кандидата в фоне. HR это легко объясняет: мол, если у лида появится возможность, он подключится к обсуждению, а сейчас он занят важными делами.

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

Спойлер: никакого следующего этапа не будет. HR через несколько дней даст стандартную обратную связь — и все сэкономят время.

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

И всё.
За полтора часа кандидат полностью пройден: и по софту, и по технике, и по мышлению.

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

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