Сотни откликов на одну вакансию, идеально вычищенные резюме и ответы, подготовленные языковой моделью, превращают найм разработчиков в проверку на подлинность. Технический рекрутер Stack Overflow Том Харви считает, что знание конкретного языка и привычные тесты всё хуже отделяют сильного инженера от кандидата с хорошо настроенным ИИ-помощником. Для российского IT-рынка вывод тот же: резюме теперь открывает дверь, но почти ничего не говорит о том, как человек будет работать в команде.
О том, как меняется отбор инженеров, сообщает Stack Overflow Blog в разговоре со старшим менеджером по талантам и культуре компании Томом Харви. По его словам, работа начинается ещё до публикации вакансии: рекрутер и нанимающий менеджер обсуждают не только обязательные и желательные навыки, но и то, что трудно уложить в формальное описание. Stack Overflow ищет не просто человека, владеющего языком X, а кандидата, который способен рассказать о сделанном, объяснить компромиссы, взаимодействовать с коллегами и принимать обратную связь.
Это не гуманитарная надстройка над «настоящими» навыками, а смена приоритетов. Роль инженера, по наблюдению Харви, всё меньше сводится к написанию кода по готовому ТЗ. От него ждут участия в обсуждении направления продукта, стратегии и решений команды. Значит, на интервью важны не только ответы на вопрос о фреймворке, но и способность внятно разложить: какую проблему решали, что пошло не так, какие ограничения были у команды и почему был выбран именно этот вариант.
Проблема в том, что генеративный ИИ сделал внешние сигналы почти бесполезными. Харви описывает это как «жестокую иронию»: теперь все кандидаты выглядят безупречно. Раньше рекрутер мог за минуту увидеть в резюме слишком много воды, неуместные детали или явное несоответствие роли. Теперь текст можно привести к образцовому виду за пару запросов к модели. Из-за этого кандидат рискует продать на бумаге опыт, который не сможет подтвердить в разговоре, а компания — потратить время на интервью, где фасад быстро рассыплется.
Вместо списка мест работы и стажа рекрутер предлагает искать то, что он называет опытом с большой буквы. Не «три года в компании N», а конкретная история: продакшен упал, критический баг сломал важный сценарий, решение оказалось неверным, а после инцидента разработчик изменил подход. Такие эпизоды менее удобны для резюме и хуже ложатся в фильтр ATS, зато лучше показывают инженерное мышление. Ошибка здесь не компромат, а доказательство того, что человек умеет замечать последствия своих решений и учиться на них.
Привычные LeetCode-тесты в этой логике тоже теряют вес. Харви прямо говорит, что большие языковые модели сделали получение правильного решения слишком доступным. Компании пробуют другие форматы: например, предлагают разобрать и исправить ошибочный код, который сгенерировал ИИ. Но и это пока не стало понятным рыночным стандартом. Кандидату сложно показать такой навык заранее, а работодателю — быстро и честно оценить его среди сотен заявок.
Автоматизировать первую воронку кажется очевидным решением, но Харви относится к ИИ-скринингу скептически. Современные ATS по-прежнему в основном ищут ключевые слова, локацию и другие формальные совпадения. Системы проверки данных могут помочь с адресами и мошенничеством, однако старт процесса в режиме взаимного недоверия портит его для всех: рекрутера, нанимающего менеджера и кандидата. Если соискатель заранее ждёт робота-цензора, а компания — поддельный профиль, нормальный разговор о работе начинается слишком поздно.
Изменяется и роль самого рекрутера. Ещё недавно на первом созвоне достаточно было поддержать разговор, понять мотивацию и не потеряться в терминах. По словам Харви, за последние шесть месяцев ожидания заметно выросли: техническому рекрутеру нужно лучше понимать работу команды, типичный рабочий день, ближайшие планы бизнеса и содержание будущих задач. Иначе он не сможет ни проверить глубину опыта кандидата, ни честно «продать» ему вакансию — особенно если речь идёт о пассивных специалистах, которых надо заинтересовать, а не просто разобрать входящие отклики.
Парадокс в том, что более технический первый этап уже провоцирует новую гонку вооружений. Кандидаты предполагают вопросы и готовят с ИИ гладкие ответы. Поэтому полезнее становятся открытые вопросы, где требуется подумать вслух, уточнить контекст, признать неопределённость и показать ход рассуждений. Идеальный монолог без пауз в разговоре об аварии в продакшене может сказать о кандидате меньше, чем нормальная попытка вспомнить детали и честно объяснить спорное решение.
Для разработчиков это означает, что найм разработчиков всё сильнее зависит от портфолио историй, а не от перечня технологий. Стоит заранее собрать несколько реальных кейсов: сложный релиз, конфликт требований, неудачный архитектурный выбор, исправленный инцидент, ситуация с наставничеством или обратной связью. Для компаний задача сложнее: придётся проектировать интервью так, чтобы оно проверяло мышление и сотрудничество, но не превращалось в допрос на детекторе ИИ. Главный вопрос рынка теперь не в том, умеет ли кандидат написать правильный код с подсказкой модели, а в том, сумеет ли он заметить, когда этот код создаст следующую проблему.
