Технический найм в эпоху ИИ: суждение важнее шаблонного кода

Что изменилось в техническом найме

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

Сейчас это соответствие стало слабее. Инструменты ИИ могут за минуты сгенерировать каркас, тесты, рефакторинг и типовые паттерны. Два кандидата могут прислать работу, которая выглядит одинаково отполированной, хотя уровень у них совсем разный.

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

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

Именно поэтому при найме теперь больше внимания уделяют суждению, а не шаблонному коду. Хорошие инженеры всё так же используют ИИ. Разница в том, что они не останавливаются на первом рабочем ответе. Они его проверяют, упрощают и подгоняют под реальную задачу.

Простой пример хорошо показывает этот сдвиг. Два кандидата присылают небольшой сервис с похожими эндпоинтами, тестами и структурой. На бумаге оба выглядят сильно. Потом вы спрашиваете, как каждый из них справится с rate limits, плохим вводом или частичным сбоем. Один отвечает расплывчато. Другой объясняет компромиссы, замечает точки отказа и предлагает разумный план. Этот разрыв важнее, чем то, кто быстрее написал первый controller.

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

Почему шаблонный код потерял ценность

Аккуратное CRUD-приложение раньше было полезным сигналом. Оно показывало, что кандидат умеет структурировать код, подключать базу данных и завершать базовую задачу. Теперь многие кандидаты могут с помощью ИИ получить почти такой же результат, хотя понимают происходящее совершенно по-разному.

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

Разница становится заметна, как только вы выходите за пределы happy path. Шаблонный код не покрывает грязные случаи, с которыми команды сталкиваются каждую неделю: частичные сбои, плохие данные, неясные требования, неприятные миграции, шумные логи и откаты, которые нужны сейчас, а не завтра. Красивое демо может скрыть слабое понимание, потому что демо живёт в чистых условиях. Продакшен — нет.

Дайте двум кандидатам одну задачу: сделать небольшой API с авторизацией, валидацией и записью в базу. Оба присылают рабочий код. Один в основном говорит о сгенерированных файлах и о том, как быстро он справился. Другой спрашивает, кто владеет данными, что будет, если клиент повторит тот же запрос, как команда будет отслеживать ошибки и как откатить неудачную миграцию. Второй кандидат может написать меньше кода во время интервью, но обычно мыслит больше как человек, которому можно доверять в продакшене.

Лучшие интервью ищут сигналы, которые сложно подделать шаблонным кодом. Может ли кандидат объяснять компромиссы простым языком? Замечает ли он отсутствующие ограничения до начала программирования? Видит ли риски в слишком гладком ответе? Записывает ли он допущения вместо того, чтобы их прятать?

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

Что по-другому делают сильные кандидаты

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

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

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

Это не попытка тянуть время. Это и есть суждение. Кандидат решает, какие компромиссы он готов принять, а не делает вид, что все цели можно совместить без потерь.

Разницу слышно по ответам. Сильный кандидат может сказать: «Если сотрудники поддержки проверяют каждую сводку, я бы сначала выпустил более простую версию. Если сводки сразу уходят клиентам, я бы замедлился и добавил проверки». Это лучше, чем отполированный дизайн без понимания риска.

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

Ещё один ясный сигнал даёт письмо. Попросите после интервью короткую заметку с их подходом, допущениями, открытыми вопросами и первым действием, которое они бы протестировали. Хорошие кандидаты пишут просто. Они отделяют факты от догадок, объясняют, почему выбрали именно этот путь, и делают своё мышление понятным для других.

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

Как проверять суждение

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

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

Сильный ответ начинается с вопросов, а не с мгновенных решений. Хорошие кандидаты отделяют факты от предположений, называют главные риски и объясняют, что им нужно перед действием.

Хорошо работает такой формат интервью:

1. Дайте кандидату запутанный сценарий с несколькими пробелами и небольшим шумом.
2. Попросите не один идеальный ответ, а два-три разумных варианта.
3. В середине добавьте новое ограничение.
4. Спросите, что бы он измерял после запуска.
5. Сначала оценивайте ход мысли, а код смотрите потом.

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

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

Вопрос про метрики часто ломает поверхностные ответы. Спросите, за чем они следили бы в ближайшие 24 часа и в следующие две недели. Хорошие кандидаты называют несколько конкретных сигналов: конверсию, количество неудачных оплат, объём обращений в поддержку, долю возвратов, задержку страницы или всплески ошибок. Более сильные добавляют защитные метрики, чтобы одно исправление не создало новую проблему где-то ещё.

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

Аккуратное решение приятно. А разумное мышление — это то, что вы оставляете.

Как проверять системное мышление

Дайте кандидату небольшой сервис, который выглядит как реальный продукт. Хороший пример — SaaS-приложение, где пользователи загружают счета, файлы хранятся, OCR распознаёт текст, а результаты показываются в панели. Скажите, что у сервиса 20 000 пользователей, несколько крупных аккаунтов и support-команда, которая каждое утро по понедельникам жалуется на медленные загрузки.

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

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

Потом слушайте, какие связи они строят. Медленная OCR-задача — это не только вопрос очереди. Она превращается в тикеты в поддержку, повторные загрузки и запросы на возврат денег. Хранить каждый промежуточный файл может помочь с отладкой, но это быстро увеличит облачные расходы. Правило повторной попытки может сгладить краткие сбои, а может создать шторм, который замедлит весь сервис. Один крупный клиент с огромными файлами может мешать всем остальным, если система не отделяет тяжёлые задачи.

Сильные ответы свободно переходят между пользовательским взглядом, взглядом на код и операционным взглядом, не теряя нить. Кандидат может предложить понятное сообщение о прогрессе в продукте, idempotent jobs в worker и отдельные очереди или rate limits в продакшене. В этом нет эффектности. Зато именно такое мышление помогает сервису оставаться удобным.

Хорошие кандидаты также трезво смотрят на компромиссы. Они не бросаются подключать пять новых сервисов только потому, что в задаче упомянут рост. Часто первое решение намного меньше: ограничить размер загрузки, закэшировать один дорогой шаг, улучшить логи, разделить срочную работу и массовую или убрать цикл повторных попыток, который сжигает деньги.

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

Используйте письмо на интервью

Короткая дизайн-заметка может рассказать о кандидате больше, чем ещё один раунд live coding. Когда ИИ-инструменты быстро заполняют стандартный код, ясное письмо часто показывает более ясное мышление.

Промпт не обязан быть сложным. Дайте кандидатам небольшую реальную задачу: добавить audit logs во внутренний инструмент, решить, где хранить пользовательские события, или выкатить AI-ассистента так, чтобы не раскрыть приватные данные. Потом попросите написать заметку на одну страницу.

Не оценивайте её как сочинение. Вы не нанимаете романиста. Смотрите на структуру, которая помогает другому инженеру или менеджеру принять решение.

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

Допущения важнее, чем красивый стиль. Сильные кандидаты пишут фразы вроде «Я предполагаю, что объём событий не превысит 1 миллион в день» или «Я бы уточнил, нужен ли сотрудникам поддержки доступ на чтение, прежде чем выбирать модель прав доступа». Это хорошо, потому что показывает: человек видит границы задачи.

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

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

Если вам нужны инженеры, которые хорошо работают с AI-ассистентами, проверьте, умеют ли они давать понятный brief и машине, и команде. Сейчас это важно.

Простой сценарий найма

Представьте, что стартапу нужен внутренний инструмент для службы поддержки. Цель звучит просто: один экран для поиска клиента, второй — для просмотра недавней активности, и несколько кнопок для типовых действий. Агентам приходится прыгать между админ-панелями, логами чатов и платёжными записями, поэтому давление на скорость релиза реально.

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

Разница становится заметна, когда черновик сталкивается с реальным использованием. Сотрудники поддержки работают под давлением. Они могут нажать не на того клиента, общаются с раздражёнными пользователями и нуждаются в ответе за секунды. Сильный кандидат начинает задавать вопросы, которые защищают бизнес, ещё до того, как писать следующий код.

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

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

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

Ошибки, которые ослабляют процесс

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

Ещё одна ловушка — trivia. Если интервью забиты вопросами по синтаксису, фактам о framework или trick questions, вы в основном проверяете память. Реальная работа выглядит иначе. Инженеры читают неясные требования, задают вопросы, находят компромиссы и чинят проблемы, не ломая всё вокруг.

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

Команды также пропускают письмо, потому что код кажется проще для оценки. Это ошибка. Инженеры пишут дизайн-заметки, комментарии к pull request, incident updates и handoff docs. Если человек не может объяснить выбор простым языком, потом он обычно создаёт путаницу.

Короткий письменный промпт часто раскрывает больше, чем ещё один кодовый раунд. Вы видите, называет ли человек допущения, отделяет ли факты от догадок и замечает ли недостающую информацию. Ясное письмо и ясное мышление обычно идут вместе.

Одна отшлифованная демо-версия не должна перекрывать слабое суждение. Кандидат может показать блестящий side project и всё равно упустить очевидные вещи вроде отката, мониторинга, стоимости, приватности или нагрузки на поддержку. Красивый результат может скрыть поверхностное мышление.

Следите за простыми ошибками в оценке: давать лишние баллы только потому, что человек закончил первым; воспринимать trivia как доказательство seniority; игнорировать слабое письмо, если код заработал; позволять харизме перевешивать плохие компромиссы; пропускать дополнительные вопросы после сильного первого ответа.

Лучший процесс замедляется в нужные моменты. Попросите кандидата объяснить компромиссы, написать короткий план и отреагировать на одно изменение в требованиях. Именно там и проявляется суждение.

Короткий чек-лист перед решением

Финальные оценки на интервью могут скрывать самое важное: как человек думает, когда ответ не очевиден. Перед решением посмотрите на последнюю задачу кандидата, письменную заметку или домашнее задание и задайте четыре простых вопроса.

• Может ли он объяснить компромиссы простым языком?
• Оставляет ли он после себя текст, которым может пользоваться другой человек?
• Спрашивает ли он про сценарии отказа и стоимость без подсказок?
• Может ли он пересмотреть план, когда появляются новые факты?

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

Небольшой пример это хорошо показывает. Кандидат A выдаёт аккуратный дизайн и держится за него. Кандидат B начинает просто, а потом меняет курс, когда вы добавляете жёсткий бюджет и строгую цель по uptime. Кандидат B обычно безопаснее.

Это тот человек, с которым другие инженеры смогут работать в реальной команде, под реальным давлением, когда факты меняются посреди недели.

Что менять дальше

Не нужно перестраивать весь процесс найма. Нужны более качественные сигналы.

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

Ближе к концу процесса добавьте короткую письменную справку. Попросите полстраницы после обсуждения системы или разбора инцидента. Сильные инженеры обычно объясняют допущения, риски и следующие шаги простым языком. Это важно, потому что теперь большая часть работы — делать решения понятными для коллег, основателей и клиентов.

Интервьюерам тоже нужен более хороший rubric. Гладкая речь, аккуратные схемы и быстрые ответы легко переоценить. Более сильная scorecard проверяет, задавал ли кандидат полезные вопросы до ответа, называл ли компромиссы вместо притворства, что есть один идеальный вариант, ясно ли он объяснял ход мыслей и менял ли курс при новых фактах.

Для этого не нужен большой внутренний проект. Один общий rubric и calibration-сессия могут сильно помочь. Полезно также пересматривать процесс каждые несколько наймов. Смотрите, нет ли раундов, где все дают одинаковую обратную связь, или где комментарии сводятся к уверенности и полировке, а не к решениям. Такие раунды обычно добавляют шум.

Для команд, которые перестраивают найм на фоне того, как ИИ берёт на себя больше рутинной инженерной работы, Oleg Sotnikov на oleg.is предлагает поддержку Fractional CTO и startup advisory. Практичный взгляд со стороны может помочь, когда hiring loop всё ещё поощряет стиль, а не мышление.

Хороший процесс должен показывать, как человек думает, когда путь неочевиден. Именно это ИИ пока не решает за вас.