ИИ уже вошёл в нашу будничную рутину. Кто-то использует его как быстрый справочник, кто-то как помощника в IDE, а кто-то уже собирает вокруг него весь рабочий процесс. Рынок меняется слишком быстро, чтобы игнорировать это на собеседованиях. Какой смысл проверять кандидата в искусственных условиях, если в реальной работе он всё равно использует ИИ каждый день? Логичнее сразу посмотреть, как он работает на самом деле. Мы не стали с этим бороться, а встроили в процесс.
Сейчас это небольшой блок, в котором мы проверяем навык работы с ИИ-инструментами. Мы сразу снимаем опасения, что на собеседовании нужно изображать «разработчика из прошлого», который принципиально использует только редактор кода и собственную память. При этом отсутствие опыта с ИИ не станет поводом для отказа: если к нам придет сильный инженер, мы с радостью наймём его и поможем освоить эти инструменты уже в процессе работы.
Где ИИ уже появился в найме
Сам по себе факт использования ИИ мало говорит о кандидате. Важнее, как он с ним работает. Сейчас в X5 Tech взаимодействие с ИИ уже в пилоте для сеньоров Python-разработчиков и сеньоров QA-инженеров. На этапе скрининга рекрутер предупреждает кандидата, что на техническом интервью будет ИИ-блок. Мы сами предоставляем инструмент, так что кандидату не нужно ничего приносить с собой. Он шарит экран и решает задачу с помощью ИИ.
В этом случае процесс интереснее результата. Даже если в итоге модель не решила задачу, всё равно видно, как действовал кандидат. Как сформулировал промпт, как итерировал, насколько критически оценил результат и понял, что делать дальше, если модель дала странный или противоречивый ответ.
Мы начали чаще спрашивать:
-
какие ИИ-инструменты кандидат использует и как часто;
-
что такое контекстное окно, токен и температура модели;
-
что такое агентный подход и чем он отличается от чата;
-
что такое MCP;
-
как кандидат обеспечивает безопасность при работе с ИИ.
На интервью мы можем дать кандидату файл с инструкциями для ИИ-агента, например CLAUDE.md или .cursorrules, и попросить его сделать ревью. Нужно понять, поможет ли такой файл агенту лучше работать, где у него слабые места, может ли такой промпт спровоцировать галлюцинации у модели и что в нём стоит переписать, чтобы он потреблял меньше контекста. Если кандидат понимает, как ИИ работает с контекстом, он сразу замечает размытые формулировки, отсутствие примеров и потенциальные источники ошибок.
У нас уже есть среда обмена практиками: корпоративный инструмент, видеоинструкции, скринкасты, статьи и туториалы. Но параллельно с внедрением ИИ-блока в найм мы ещё готовим внутренние курсы для сотрудников. Если кандидат прошёл отбор, но получил пометку «требует обучения по ИИ», после выхода он попадёт на эти курсы.
Что это значит для джуна
Сейчас у многих неопытных разработчиков возникает зависимость от ИИ-инструментов, которая приводит к слабому пониманию кода и деградации навыков. Это заметно по разным источникам, например по исследованию Anthropic 2026 года: «How AI assistance impacts the formation of coding skills» и отзывам менторов. С помощью таких инструментов неопытные разработчики быстро генерируют код, но не могут его отдебажить или объяснить. Часто вставляют сгенерированный код без проверки, что приводит к новым ошибкам, устаревшим практикам или неоптимальным решениям даже в продакшене.
При этом на собеседовании от джуна не ждут сложных архитектурных решений или глубокого понимания всех нюансов работы моделей. Но есть базовый уровень, без которого трудно двигаться дальше. Сейчас мы ожидаем:
-
знать базовые принципы промпт-инжиниринга: роль, контекст, формат вывода;
-
понимать, что такое галлюцинации модели и как с ними справляться;
-
знать, что такое контекстное окно, как это влияет на качество и почему нельзя бесконечно добавлять информацию;
-
не отправлять в публичные инструменты токены, пароли и чувствительные данные.
Эти знания и опыт видны на этапе отбора резюме.
Слабым сигналом будет набор разрозненных проектов, из которых непонятно, что именно делал кандидат, зачем выбрал этот стек и какие решения принимал.
Плохо смотрятся и клоны туториалов без README, роли автора, контекста и связи с вакансией.
Сильным сигналом становятся несколько аккуратно собранных проектов, по которым видны вклад и системное мышление кандидата. Например, в них описано, как устроено решение. Это не обязательно должна быть сложная архитектура, но сама структура, понятные границы и объяснение, почему всё собрано именно так, уже показывают, что кандидат не просто сгенерировал код, а понимает, как он устроен. Например, где автор не согласился с предложением ИИ, а переписал решение под реальные ограничения.
По проекту должно быть видно, зачем он вообще нужен и какую проблему решает. И, наконец, в нём должна быть базовая инженерная гигиена: 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, утечки памяти, нестабильное поведение;
-
безопасность — уязвимости, которые выглядят как нормальный код;
-
архитектурные решения — модель предлагает стандартные варианты, не учитывая ограничения проекта.
Здесь и начинается зона ответственности мидла. Важно, может ли кандидат объяснить, почему решение устроено именно так, видит ли риски и ограничения, умеет ли проверить правдоподобный ответ и понять, где ИИ ошибся. Ревью ИИ-кода становится всё более важным навыком.
Это хорошо считывается по резюме. Сам список технологий уже мало что даёт. Гораздо важнее расшифровка опыта: что изменилось после его решений, в чём были причины проблем и какие выводы он сделал.
Если джуну достаточно уверенно держаться на 1-2 ступени лестницы зрелости, то мидл должен подниматься выше.
Что это значит для сеньоров
Для сеньора ИИ уже не просто инструмент. Если мидл должен уметь объяснить решение, увидеть риски и ограничения и понять, где модель ошибается, то сеньор отвечает за следующий слой. Как встроить такие инструменты в командную работу так, чтобы они ускоряли разработку, а не плодили новый техдолг. Для этого нужно уметь задавать правила использования инструментов в команде, настраивать контекст для агентов под проект, встраивать ревью сгенерированного кода в общий процесс, объяснять, где модель чаще всего ошибается, и понимать, какой инструмент подходит под конкретную задачу.
Но меняется не только набор инструментов. Исследования и отраслевые отчёты показывают, что массовое использование ИИ требует от команд новых правил проверки, более быстрых циклов обратной связи и ещё более явного распределения ответственности за код. Приходится перестраивать ревью-процессы, обучение и метрики, потому что вместе с ускорением появляются такие скрытые издержки, как дополнительные проверки и проблемы интеграции. Так что ИИ меняет не только процесс разработки, но и правила инженерной культуры.
Если в команде нет культуры проверки, начинает копиться техдолг нового типа, когда внешне всё выглядит правдоподобно, а внутри остаются слабые решения, неучтённые ограничения и уязвимости. Отсюда же потеря ответственности и соблазн списать всё на модель. Но фраза «это написал ИИ» в продакшене не работает.
Кто смержил код, тот за него и отвечает.
Поэтому и планка для сеньора выше.
Если смотреть через лестницу зрелости, то сеньор должен быть на верхних ступенях.
Что делать, если вы не на идеальном уровне
Скорее всего, вы и не должны на нём быть. Лестница зрелости — это не чек-лист, который нужно закрыть перед собеседованием. Это способ понять, где вы сейчас и что у вас уже получается, а что ещё можно подтянуть. Важно не «дойти до последней ступени», а двигаться к ней осознанно.
Если вы джун, нормально быть на уровне чата и базового использования ИИ в IDE.
Если вы мидл, нормально только начинать работать с контекстом и инструкциями.
Если вы сеньор, никто не ожидает, что у вас уже собрана идеальная мультиагентная система.
Мы не ждём, что кандидат будет полностью соответствовать своей ступени. Гораздо полезнее объяснить, как именно вы работаете с ИИ: где он вам помогает, где мешает и что вы перепроверяете руками.
Хотите ещё больше узнать о том, как подготовиться к новым вопросам на собеседовании, о каких ИИ-агентах чаще всего спрашивают и что нужно знать о найме в 2026 году, приходите на Публичное собеседование 14 апреля в 17:00.
Так же можете прочитать статьи о вайб-кодинге и AI-идеях для работающих продуктов:
– Выжимаем максимум из опенсорсных моделей и готовим Text2SQL
– От vibe coding к Spec-Driven Development: как приручить скорость ИИ и довести проект до продакшена
ссылка на оригинал статьи https://habr.com/ru/articles/1022832/