После волны сокращений в ИТ-индустрии в эпоху ИИ казалось, что нанимать станет проще: рынок переполнен кандидатами. Произошло обратное. Резюме стало больше, но найти инженера, которому можно доверить систему, стало сложнее. Генеративный ИИ сделал код дешёвым и одновременно обесценил классические инструменты отбора: отполированное резюме, тестовое задание и pet-проект больше ничего не доказывают.
"Проблема не в том, чтобы найти человека, который напишет ещё тысячу строк кода. Проблема - найти инженера, который за 20 минут поймёт, нужны ли эти строки вообще", - говорит Евгений Пиотровский, senior software engineer Thronelabs, IEEE Senior Member.
За десять лет в разработке Евгений стал архитектором систем для американских стартапов в сфере финтеха и городской IoT-инфраструктуры. Компании, в которых он был ключевым инженером, в совокупности привлекли более $40 млн инвестиций, а продукт его нынешней команды вошёл в список TIME Best Inventions. Сегодня он работает в компании, где на более чем 90 сотрудников приходится всего несколько software-инженеров, поэтому цена каждого найма измеряется месяцами разработки. Он также является судьей хакатона NASA Space Apps Challenge в США и Украине, автором open-source системы мониторинга Peekaping с более чем тысячей звезд на GitHub, а другие компании приглашают его для проведения независимых аудитов кода и оценки инженеров.
Почему в маленькой команде цена найма другая
"Стартап не может нанимать "просто хороших программистов". У нас меньше людей, времени и денег на ошибки. Один неудачный архитектурный выбор может через полгода замедлить работу всей компании", - объясняет инженер.
ИИ, по его словам, ещё и выровнял внешний вид кандидатов: код в портфолио выглядит профессионально независимо от того, понимает ли человек его поведение в production. Рынок отреагировал повышением формальных требований: по данным Indeed, доля американских вакансий в сфере технологий с требованием от пяти лет опыта выросла с 37% в 2022 году до 42% в 2025-м. Но стаж, считает Пиотровский, измеряет не то.
"Компании ищут инженерное суждение и пытаются измерить его годами опыта. В моей практике самый опытный кандидат показывал худший результат, а самым сильным оказывался инженер с меньшим стажем, но с правильным образом мышления", - отметил он.
ЧИТАЙТЕ ТАКЖЕ: Госслужба занятости обнародовала самые популярные вакансии этого года
"Этот вывод я сделал не только в своей команде. В 2024 году консалтинговая компания пригласила меня отобрать инженеров для международного IoT-стартапа: из шести кандидатов я рекомендовал нанять троих, а двоих отклонил, хотя внутренние рекрутеры оценивали их положительно. Честная оценка риска дороже комфортной", - вспоминает Пиотровский.
Что проверять, когда код обесценился
Вместо алгоритмических задач на доске Евгений Пиотровский дает кандидатам открытое архитектурное задание с намеренно неполными требованиями и оценивает вопросы наравне с ответами.
"Сильные кандидаты начинают с уточнений: какие объемы данных, как обстоит дело с офлайн-режимом, как быстро меняются требования. Слабые сразу рисуют готовые решения. То, как человек справляется с неоднозначностью, лучше предсказывает его успех в реальном проекте, чем любая алгоритмическая задача", - объясняет он.
Второй инструмент - ревью. Согласно опросу Stack Overflow, 84% разработчиков используют или планируют использовать ИИ-инструменты, при этом 46% не доверяют точности их ответов. Узкое место сместилось с написания кода на его проверку, поэтому запрещать ИИ на собеседовании бессмысленно. Наоборот: кандидату стоит дать большой правдоподобный сгенерированный патч и попросить провести ревью.
"Что он проверит в первую очередь? Какие проблемы назовет критическими, а какие - косметическими? Нам важно не то, найдет ли он все десять заложенных ошибок. Важно, правильно ли определит две, которые могут остановить бизнес", - говорит инженер.
Опасность сгенерированного кода в том, что он выглядит неплохо: аккуратный, логичный, убедительный. Ошибка скрывается не в синтаксисе, а в транзакционной модели, лишнем запросе к базе данных или допущении, которое работает только при небольшой нагрузке.
"Я вижу этот тренд в собственном open-source-проекте: pull-реквесты в Peekaping поступают от людей, которых я никогда не видел, и всё чаще они написаны с помощью ИИ. Каждый раз нужно быстро решить, безопасно ли это изменение и не сломает ли оно систему тем, кто уже ею пользуется", - добавляет он.
Как понять, что найм сработал
Меняются, по словам Пиотровского, и метрики после найма. Количество строк кода или pull-реквестов больше ничего не измеряет: когда код стало дешево генерировать, его объем почти ничего не говорит о ценности человека для команды.
"Я смотрю на время до проверенного релиза, количество дефектов, частоту откатов, скорость ревью и стоимость последующих изменений. Еще один важный показатель - сколько сложности инженер не создал. Иногда лучший вклад senior-разработчика - не написать новый модуль, а объяснить, почему он не нужен", - объясняет он.
Чек-лист для тех, кто нанимает
● Убрать из процесса всё, что кандидат может подготовить заранее.
● Разрешить использование ИИ на собеседовании и посмотреть, как кандидат проверяет его работу.
● Давать открытое задание без правильного ответа и оценивать вопросы, а не только решения.
● Ценить архитектурное суждение выше знания фреймворков и стажа.
● После найма измерять время до проверенного релиза и стоимость изменений, а не объем кода.
ИИ не упростил наем, он изменил предмет оценки. Компании, которые отбирают людей по способности писать код, нанимают навык, который с каждым месяцем дешевеет. Те, кто научился оценивать инженерное суждение, получают инженеров, способных превратить сгенерированный прототип в систему, которая будет развиваться годами.
"Сказать "я умею пользоваться ИИ" уже недостаточно - это базовое требование. Ценность заключается в другом: быстро проверить результат, полученный системой, выявить системные риски, упростить решение и взять за него ответственность. Рынок не стал меньше. Он поднял планку", - подытожил Евгений Пиотровский.
1 
4069
Комментарии