ИИ — это линза, которая усиливает сильных и ослабляет слабых

ИИ уже вошёл в нашу будничную рутину. Кто-то использует его как быстрый справочник, кто-то как помощника в IDE, а кто-то уже собирает вокруг него весь рабочий процесс. Рынок меняется слишком быстро, чтобы игнорировать это на собеседованиях. Какой смысл проверять кандидата в искусственных условиях, если в реальной работе он всё равно использует ИИ каждый день? Логичнее сразу посмотреть, как он работает на самом деле. Мы не стали с этим бороться, а встроили в процесс.

Сейчас это небольшой блок, в котором мы проверяем навык работы с ИИ-инструментами. Мы сразу снимаем опасения, что на собеседовании нужно изображать «разработчика из прошлого», который принципиально использует только редактор кода и собственную память ^[1]. При этом отсутствие опыта ^[2] с ИИ не станет поводом для отказа: если к нам придет сильный инженер, мы с радостью наймём его и поможем освоить эти инструменты уже в процессе работы.

Где ИИ уже появился в найме

Сам по себе факт использования ИИ мало говорит о кандидате. Важнее, как он с ним работает. Сейчас в X5 Tech взаимодействие с ИИ уже в пилоте для сеньоров Python-разработчиков и сеньоров QA-инженеров. На этапе скрининга рекрутер предупреждает кандидата, что на техническом интервью будет ИИ-блок. Мы сами предоставляем инструмент, так что кандидату не нужно ничего приносить с собой. Он шарит экран и решает задачу с помощью ИИ.

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

Мы начали чаще спрашивать:

• какие ИИ-инструменты кандидат использует и как часто;

• что такое контекстное окно, токен и температура модели;

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

• что такое MCP;

• как кандидат обеспечивает безопасность при работе с ИИ.

На интервью мы можем дать кандидату файл с инструкциями для ИИ-агента, например CLAUDE.md или .cursorrules, и попросить его сделать ревью. Нужно понять, поможет ли такой файл агенту лучше работать, где у него слабые места, может ли такой промпт спровоцировать галлюцинации у модели и что в нём стоит переписать, чтобы он потреблял меньше контекста. Если кандидат понимает, как ИИ работает с контекстом, он сразу замечает размытые формулировки, отсутствие примеров и потенциальные источники ошибок.

У нас уже есть среда обмена практиками: корпоративный инструмент, видеоинструкции, скринкасты, статьи и туториалы. Но параллельно с внедрением ИИ-блока в найм мы ещё готовим внутренние курсы для сотрудников. Если кандидат прошёл отбор, но получил пометку «требует обучения ^[3] по ИИ», после выхода он попадёт на эти курсы.

Что это значит для джуна

Сейчас у многих неопытных разработчиков возникает зависимость от ИИ-инструментов, которая приводит к слабому пониманию кода и деградации навыков. Это заметно по разным источникам, например по исследованию Anthropic 2026 года: «How AI assistance impacts the formation of coding skills» ^[4] и отзывам менторов. С помощью таких инструментов неопытные разработчики быстро генерируют код, но не могут его отдебажить или объяснить. Часто вставляют сгенерированный код без проверки, что приводит к новым ошибкам, устаревшим практикам или неоптимальным решениям даже в продакшене.

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

• знать базовые принципы промпт-инжиниринга: роль, контекст, формат вывода;

• понимать, что такое галлюцинации модели и как с ними справляться;

• знать, что такое контекстное окно, как это влияет на качество и почему нельзя бесконечно добавлять информацию;

• не отправлять в публичные инструменты токены, пароли и чувствительные данные.

Эти знания и опыт видны на этапе отбора резюме.

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

Плохо смотрятся и клоны туториалов без README, роли автора, контекста и связи с вакансией.

Сильным сигналом становятся несколько аккуратно собранных проектов, по которым видны вклад и системное мышление ^[5] кандидата. Например, в них описано, как устроено решение. Это не обязательно должна быть сложная архитектура, но сама структура, понятные границы и объяснение, почему всё собрано именно так, уже показывают, что кандидат не просто сгенерировал код, а понимает, как он устроен. Например, где автор не согласился с предложением ИИ, а переписал решение под реальные ограничения.

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

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

Что я сделалСервис, который обрабатывает события доставки и обновляет статус заказа в реальном времени через WebSocket.

Моя роль

• разработал бэкенд-сервис на Node.js

• спроектировал event flow между сервисами

• реализовал обработку событий и обновление статуса

• настроил логирование и базовые алерты

Tech stackNode.js, WebSocket, Redis, PostgreSQL

Ключевые решения

• отказался от polling в пользу событийной модели, чтобы снизить нагрузку

• добавил Redis как промежуточный слой для буферизации событий

• ограничил количество соединений через rate limiting

Что я изменил после использования ИИИИ предложил использовать polling с частыми запросами. Я отказался от этого решения из-за нагрузки и переписал на event-driven подход.

С какими сложностями столкнулся

• рассинхронизация событий

• дублирование сообщений

• необходимость гарантировать порядок обработки

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

Как запуститьСсылки на инструкции из 5–6 шагов, Docker Compose и тестовые данные.

Для наглядности свой уровень работы с ИИ можно описать через лестницу зрелости.

Для джуна нормальная точка входа — первые две ступени.

Что это значит для мидла

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

Теперь сильный сигнал — это свой рабочий процесс: инструмент в IDE, понятные сценарии использования, шаблоны промптов. Нужно уметь работать с результатом, а не только получать его.

Это хорошо видно на задачах, где модель начинает ошибаться:

• сложная бизнес-логика с неявными правилами — модель не знает контекста продукта;

• большие и запутанные кодовые базы — не помещаются в контекстное окно;

• продакшен-проблемы — race conditions, утечки памяти, нестабильное поведение ^[6];

• безопасность — уязвимости, которые выглядят как нормальный код;

• архитектурные решения — модель предлагает стандартные варианты, не учитывая ограничения проекта.

Здесь и начинается зона ответственности мидла. Важно, может ли кандидат объяснить, почему решение устроено именно так, видит ли риски и ограничения, умеет ли проверить правдоподобный ответ и понять, где ИИ ошибся. Ревью ИИ-кода становится всё более важным навыком.

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

Если джуну достаточно уверенно держаться на 1-2 ступени лестницы зрелости, то мидл должен подниматься выше.

Что это значит для сеньоров

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

Но меняется не только набор инструментов. Исследования и отраслевые отчёты ^[7] показывают, что массовое использование ИИ требует от команд новых правил проверки, более быстрых циклов обратной связи и ещё более явного распределения ответственности за код. Приходится перестраивать ревью-процессы, обучение и метрики, потому что вместе с ускорением появляются такие скрытые издержки, как дополнительные проверки и проблемы интеграции. Так что ИИ меняет не только процесс разработки, но и правила инженерной культуры.

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

Кто смержил код, тот за него и отвечает.

Поэтому и планка для сеньора выше.

Если смотреть через лестницу зрелости, то сеньор должен быть на верхних ступенях.

Что делать, если вы не на идеальном уровне

Скорее всего, вы и не должны на нём быть. Лестница зрелости — это не чек-лист, который нужно закрыть перед собеседованием. Это способ понять, где вы сейчас и что у вас уже получается, а что ещё можно подтянуть. Важно не «дойти до последней ступени», а двигаться к ней осознанно.

Если вы джун, нормально быть на уровне чата и базового использования ИИ в IDE.

Если вы мидл, нормально только начинать работать с контекстом и инструкциями.

Если вы сеньор, никто не ожидает, что у вас уже собрана идеальная мультиагентная система.

Мы не ждём, что кандидат будет полностью соответствовать своей ступени. Гораздо полезнее объяснить, как именно вы работаете с ИИ: где он вам помогает, где мешает и что вы перепроверяете руками.

Хотите ещё больше узнать о том, как подготовиться к новым вопросам на собеседовании, о каких ИИ-агентах чаще всего спрашивают и что нужно знать о найме в 2026 году, приходите на Публичное собеседование ^[8] 14 апреля в 17:00.

Так же можете прочитать статьи о вайб-кодинге и AI-идеях для работающих продуктов:
– Выжимаем максимум из опенсорсных моделей и готовим Text2SQL ^[9]
– От vibe coding к Spec-Driven Development: как приручить скорость ИИ и довести проект до продакшена ^[10]