Для кого статья: для тех, кто набирает разработчиков в свою команду и понимает в технологиях.
О чём статья: о проблемах найма в IT, о нарисованных резюме и зазубренных уроках.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью.

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

В поисках

За год проведения технических собеседований я, как лид стрима компьют, пообщался с сотнями кандидатов на позиции бэкенд‑разработчиков в облачную платформу. Наша цель — закрыть около десятка вакансий в трёх смежных стримах.
Интервью проводились с сентября 2024-го по сентябрь 2025-го: сначала по 4 двухчасовые встречи в день, иногда больше, иногда меньше. Сначала весь поток резюме шёл через кадровые агентства и HR, позже поток уменьшился, но встреч всё равно было много. Оценивали кандидатов я и мой руководитель, архитектор решений; иногда подключались лиды других команд или приходилось собеседовать одному. Мы вдвоем просеяли тонны резюме в поисках тех самых 10-15 человек, которые действительно могли бы усилить наши команды. Мы оценивали технические навыки в первую очередь, софт-скиллы — второстепенно, но тоже пытались оценивать, в основном на предмет совпадения культурного контекста (это важно для компании в целом) и темперамента, умении принимать взвешенные решения и отстаивать их.

Как мы быстро поняли, по резюме и первым минутам разговора с человеком невозможно оценить реальность его опыта. Есть определенная категория "типажей", которые умеют подстраиваться под воронки отбора эйчаров и проникать на технические интервью. К сожалению, в большинстве случаев HR в IT не имеют навыков и инструментов, чтобы отделить таких осознанных мошенников от честных людей. Получается, что последней "линией обороны" бизнеса от немотивированных трат становится техническое интервью, которое не может быть формальностью и должно специально подготавливаться и разрабатываться.

Ожидания vs реальность по кандидатам

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

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

Почему стандартные собеседования не работают

Почему не Leetcode и не «топ-300 вопросов по Java»

За свою карьеру я прошёл много собеседований, в том числе в корпорации, в том числе многоэтапные. Бизнес разный, продукты разные, люди разные. В крупных компаниях интервьюверы обычно обладают экспертизой и задают авторские задачи для live coding. В небольших фирмах часто используют шаблонные вопросы из статей вроде «Топ‑300 вопросов по Java». (вроде этой и этой).

Перед первым собеседованием я задумался: что было бы интересно решать мне самому как кандидату? Начал с того, что знаю лучше всего — баз данных и SQL. Начал с предметной области. Быстро придумал модель склада. Нужно нарисовать модель данных. Я человек ленивый, мне лень открывать графический редактор и рисовать схемы. Напишу текстом, тем более СУБД имеют такой язык как DDL. Получилось что-то вроде этого:

-- Сотрудники склада
CREATE TABLE sotrudnik (
    id uuid NOT NULL,
    name varchar(255) NOT NULL,
    surname varchar(255) NOT NULL, 
    position_id uuid NOT NULL, 
    created_at timestamp NOT NULL,
    CONSTRAINT sotrudnik_pk PRIMARY KEY (id),
    CONSTRAINT sotrudnik_un UNIQUE (name, surname)
);
-- Товары
CREATE TABLE nomenklatura (
    id uuid NOT NULL,
    name varchar(255) NOT NULL,
    supplier varchar(255) NOT NULL, 
    receipt_date timestamp NOT NULL, 
    created_at timestamp NOT NULL,
    CONSTRAINT nomenklatura_pk PRIMARY KEY (id),
    CONSTRAINT nomenklatura_un UNIQUE (name, supplier, receipt_date)
);

(Код носит иллюстративный характер, все совпадения с существующими бизнес-моделями случайны)

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

Точно так же придумал максимально не связанную с бизнесом задачу на live coding на java. Собеседник не обязан быть погружён в нашу предметную область, и его некогда погружать, формат интервью не подразумевает этого. И так же такую задачу я могу быстро модифицировать.

Мы не даём задачи, оторванные от реальности. Мы не задаём олимпиадные вопросы, вопросы на самом деле формирует бизнес: предыдущие ошибки, фиксы, запросы пользователей.

Почему разные

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

Что касается разговора о технологиях –  у меня нет какого-то гайда или списка, откуда я читаю, поэтому формулирую вопросы всегда по-разному, а сами вопросы чаще подстраиваю под то, что рассказал человек о своем опыте.

Я понимаю, что есть инфоцыгане, которые ходят по собеседованиям, собирают задачи, делятся друг с другом, готовят говорящих попугайчиков, заучивают вопросы и ответы, поэтому все мои задачи на лайфкодинг могут модифицироваться, обычно перед интервью вношу мелкие правки в одну или две задачи. Или не вношу. Так у меня образовался небольшой набор задачек, которые стали использовать мои коллеги-лиды. Бывает, перед интервью вношу мелкие правки в код, который даю для проверки. Или удаляю часть ошибок. Бывает, что кандидат подозрительно быстро и идеально решает задачу. Я в таком случае могу скопировать из нашего confluence другую (что обычно лень) или модифицировать эту, чтобы проверить, говорящий попугайчик это или человек разумный.

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

• LeetCode и топ-300 вопросов не отражают реальную практику и, что важнее, потребности бизнеса.

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

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

• Live-coding и код-ревью выявляют реальные навыки. Видеосвязь позволяет наблюдать за процессом принятия решений, реакцию кандидата на вопросы и изменения в постановке.

Как вкатиться и не выкатиться: определяем «волчат»

«Волчатами» я называю выпускников курсов, где учат не разрабатывать, а «вкатываться» в IT за пару месяцев. Их резюме выглядят гладко, но при детальном изучении:

• большие периоды работы в сверхкрупных компаниях, где огромная текучка кадров и сотни проектов. Либо мелкая нарезка опыта в no-name компаниях. Ни тот, ни тот вариант резюме проверить никто не сможет, СБ не поможет. 

• в резюме опыт работы подчёркивается какими-то корпоративными и экономическими показателями. Разработчик повысил довольство клиентов всей компании на 2% - не верю! Это показатель подразделения или направления бизнеса. Разработчики зачастую таких показателей не видят.

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

• повторяют заученные фразы. А если прервать, скорее всего запутается, уже так складно не будет;

• уходят от конкретики («это делали архитекторы», «это было до меня»). Весь рассказ плоский, буквально так:

— Что именно разрабатывали?

— Корпоративная платформа, её начали писать до меня, я сильно её развивал.

— А что она делала?

— Там была микросервисная архитектура, гейтвей, всё в кубе, сообщения отправляли по кафке.

— А что конкретно делала?

— Микросервисы были в кубернетисе, балансировались балансировщиком, была авторизация на гейтвее.

— Хорошо, а какая была интеграция на платформе?

(Ремарка автора: развернутый вопрос для обсуждений, имелось в виду, какие части синхронные, какие асинхронные, какие протоколы, связь с базой/кешем, монолитным или кластерным, какая балансировка у них)

— Кафка была.

— А были ли партиции, реплики?

— Да были, под каждый микросервис топик.

(Ремарка автора: вообще термин не подходящий под ответ никак)

• были более прокаченные волчата, которые на уточняющие вопросы отвечали облаком тегов англоязычных терминов с русскоязычными предлогами (помните же некогда хайповую штуку на основе ActionScript и Flash? Люди реально могут отвечать таким облаком тегов). Попытка поговорить на упомянутые темы как правило бесполезна. 

Выявлять таких особей помогает:

• адаптация вопросов под собеседника, импровизация на основе его рассказа и поведения;

• если рассказ слишком гладкий, но без конкретики – прерывание, смотрим, сможет ли "попасть в колею";

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

• много терминов – много вопросов по ним., смешиваю в одном вопросе несколько несовместимых терминов, например. Могут быть заданы заведомо некорректные вопросы (технические и по заданной теме. разумеется).

• много англицизмов – вопрос с упоминанием русскоязычного термина или аббревиатуры.

Если человек действительно работал с технологией, он сможет поддержать разговор на эту тему. Если же перед нами «волчонок» — начинается театр одного актера. Как правило, до ревью кода или live coding дело не доходит.

Спасти Сару Коннор

Отдельно встречаются эпические истории с ИИ, которые умнее кандидатов.

Как уже писал, есть проблема использования ИИ на собеседованиях. Но проблема не в их наличии, а в том, что на курсах "как вкатиться в Software Architecture за два часа" не учат общению с нейронками (LLM). Ведь если б они умели писать промпты и настраивать ассистентов, то вкатывались бы куда-то в ML, верно? Мошенники-волчата сами себя выдают.

Вот как против них работает мой подход:

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

• набор вопросов основывается на рассказе об опыте (да, я всё слышу, даже если в это время делаю заметки, просматриваю резюме или готовлю блок кода для ревью). Если человек работал с технологией, то он сможет поддержать разговор на эту тему, так? Если нет – у него нет времени корректно сформулировать вопрос нейросети.

• набор вопросов корректируется и изменяется в зависимости от ответов. Если человек отказывается писать SQL-запрос, мотивируя тем, что работает с NoSQL или ORM, он же с удовольствием поговорит о словарях, снапшотах и кешах 1-2 уровня, так ведь? Да, человек не знает всего, но если использует какие-то абстракции для работы с базой данных. то знает эти абстракции. Но при ответе с помощью ИИ я буду вопросы задавать не более адекватные, чем услышанные мною ответы. С ИИ можно уйти в область сказок на 3-4 вопросе.

• вопросы формулирую по-разному, не всегда полно, не всегда корректно. Отчасти чтобы проверить софт-скиллы. Изредка кандидаты задают уточняющие вопросы, почти никогда не говорят, что вопрос некорректный. Нейросети как правило не подсказывают ошибку в вопросе и не задают уточняющие вопросы сами по себе. Уверенные в себе кандидаты заметят нестыковки и могут поспорить.

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

• если кандидат не отвечает по существу, ушёл в себя, отвечает не про то, я меняю формулировку вопроса, иногда совсем по иначе вопрос выглядит. Тогда роботы вообще переключаются в другую канву повествования, зачастую – сказочную, формулировка вопроса может сильно влиять на ответ. 

Я ни в коем случае не порицаю использование "ИИ" для ускорения и автоматизации работы. Обычно технические интервью подразумевают проверку хард-скиллов и знаний кандидатов, а не скорость реакции и умение писать промпты. Для работы с нейронками всё ж надо уметь валидировать их ответы и уметь критически относиться ко всем предложенным решениям.

Есть конечно и другие сигналы от порабощённых роботами, но их не буду раскрывать в статье.

Как проводили интервью

Стандартное интервью длилось 2 часа и включало:

1. Рассказ о себе — показывает софт-скиллы и задает канву. Хороший рассказ сразу перетекает в техническую дискуссию.

2. Технологические вопросы — импровизация на основе резюме и рассказа. Здесь особенно видно разницу между знанием и заучиванием. У самых сильных кандидатов может незаметно перетечь в 6 секцию (дизайн-ревью).

3. Live-coding на Java — даю простые задачи на пару строк кода. Удивительно, но многие с 10-летним опытом не могут написать работающий код в реальном времени.

4. Live-coding на SQL и разговор о теории БД — иногда пропускаю секцию, иногда провожу частично. Говорим о принципах работы РСУБД, нагрузке, разделению данных, принципах хранения. Может быть несложная задача на написание или правку написанного с ошибкой SQL-запроса.

5. Code review — наш главный фильтр. Подготовил специальный файл с сотнями ошибок — от синтаксических до архитектурных. Для ревью даю произвольное количество методов из него, иногда чуть корректирую. Большинство «волчат» и джунов находят только неправильное наименование и кривые отступы.

6. Design review — этап для самых сильных духом. У меня есть заранее подготовленные картинки, формулировки заданий немного варьирую, могу "забыть" рассказать нюанс. Общаемся, задаём друг другу вопросы. Путаем друг друга. Разумеется, у каждой такой картинки есть несколько решений.  Разумеется, в статье не раскрою, как оцениваю. Иногда конкретную задачу заменяю более философскими вопросами в духе критики и защиты какой-то технологии или решения. К сожалению, редко выпадала возможность провести эту секцию (примерно 5% кандидатов).

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

Почему код-ревью

В моём стриме сейчас 3 продукта, 7 микросервисов, плюс готовятся еще 2 продукта, это минимум 5 микросервисов, разрабатываем общие библиотеки. Есть необходимость переключать людей между продуктами даже внутри стрима, значит надо уметь работать с чужим кодом, это важное требование. Кроме того, у нас в компании практикуется кросс-ревью, это когда разработчики ревьювят MR друг друга, и деплой на DEV-стенд возможен только при наличии минимум двух (в некоторых командах- минимум трёх) подтверждений от команды. Это повышает и вовлечённость разработчиков, возможность "держать руку на пульсе", понимать хотя бы поверхностно доработки в том сервисе, в котором в данный момент не работаешь, и повышает инженерную культуру, разработчики непрерывно обучают друг друга и особенностям синтаксиса, и "чистым" подходам к разработке и проектированию микросервисов.

Проверка софт-скиллов

Человек, имеющий за плечами опыт разработки, будет в адекватных границах защищать своё вИдение, своё решение, свой опыт – это естественно. Сильный специалист будет видеть попытки запутать, некорректные и перефразированные вопросы. Если он при этом уверен в себе, то укажет на мою ошибку или повтор. Это ценно для команды. Мы вкладываемся в развитие, нам не интересно "здесь и сейчас" написать лишь бы что. Могут быть недочёты в проектировании, опечатки в аналитике, мы ожидаем от разработчика внимания к деталям и не только желание, но и умении искать ошибки в работе коллеги и помогать их исправлять.

Кандидаты, которые опытом получили свою "сеньорность", а не просто отсидели на стуле 15 лет, могут рассказывать о своем опыте достаточно абстрактно и поверхностно, но при уточняющих вопросах могут не только рассказать нюансы технологии/подхода/решения, но и аргументированно защитить или раскритиковать. Тогда рассказ о своём опыте становится дизайн-интервью. Если есть понимание решений, технологий, чувствуется ответственность кандидата за сделанные ранее решения, то секции live coding могут сильно упрощаться. Важно, конечно, чтобы он умел писать код, но оценка будет уже более лояльной. Как правило зря, код хороший получается, не всегда идеальный, но вполне годный вариант, написанный за пару минут.

Также секция ревью кода показывает навыки и командной работы, и умение выцепить главное и второстепенное, акцентрировать внимание на ошибках "по своему статусу". Секция даёт большой простор для обсуждений, подсказок, наводящих теоретических вопросов. Могу вопросами запутать или не согласиться с аргументацией. Смотрим, как человек себя ведёт при адекватных и не очень адекватных спорах. Сильных кандидатов (по оценкам в других секциях) этим нисколько не смутить.

Примеры живых кейсов

Воссозданы примерные диалоги.
Все live-кодинги проходят в онлайн текстовом редакторе, мы с собеседником видим кто что пишет или выделяет.

Кейз 1. Космические корабли бороздят просторы банка.

Live-coding SQL. Теоретическая секция по базам выполнена не очень хорошо.

(Показываю модель данных в виде DDL скрипта и задание на написание запроса)

— Я последнее время не очень много работал с реляционными базами

— А с какими тогда?

— С графовыми. На последнем проекте я реализовывал отображение графов для окулус

— А что именно отрисовывали?

— Графы. Я работал на паре с лидом, он придумал этот движок, я реализовывал некоторые задачи

— А что рисовали?

— Графы рисовали, были разные сущности, движок позволял видеть их в трёхметрном виде, масштабировать части.

— А что было в узлах, что в ребрах?

— Разные сущности на нашей платформе, связи?

(Читаю резюме: последнее место работы банк. До этого тоже)

— То есть простой SQL-запрос написать не получится?

— Нет

— Но модель сама понятна? 

— Да, вполне.

— Представим, что подобная модель в графовой базе, напишите такой же запрос для графовой БД

(На экране появляется случайный набор латинских букв и скобочек)

К сожалению, у нас в команде шло обсуждение использования Neo4j, и я примерно представляю внешний вид запросов к ней.

Кейз 2. Я уже забыл этот язык.

Пришел кандидат с 4 годами опыта, с указанием, что у него какие-то еще пет-проекты. Начали с live-coding на джаве.

(Показываю код на джаве и задание в 3 строки, требуется написать небольшие функции. Рассказываю голосом, что нужно сделать)

— Итак, надо придумать, какие методы сюда подойдут, чтобы соответствовать интерфейсам, и реализовать это.

(Пишет среднее между джавой, джава скриптом и питоном)

— Это точно скомпилируется?

— Наверно. Знаете, я последнее время пишу на котлине, джаву уже забыл.

(Бинго! Котлинист мне нужен. Очень рад! Стираю его поэзию на псевдокоде. )

— Хорошо. Представим, что все это на котлине, пишите функции на котлине.

(Звуки пыхтения и паники)

— Ну вообще я сейчас в основном пишу на Golang

Да, за 4 года поработал с тремя языками, звезда пришла. Жаль, не прошёл интервью.

Кейз 3. Да кому нужны эти реляционки? Я эксперт по полнотекстовому поиску.

Кандидат рассказывает об опыте, путанно, общими словами. Пытаюсь выяснить хоть какие-то нюансы.

— А какая интеграция была у вас между микросервисами? Где данные хранили?

— У нас реактивные микросервисы на grpc, всё было асинхронно.

— Хорошо, а хранили данные где? FTP, кеш, реляционки или что?

— Нет,  у нас же реактивный стек, реляционные базы не используем, все на полнотекстовом поиске.

— А что за СУБД? Oracle? MySQL? Postgres?

(пауза)

— Postgres

— Postgres для полнотекствого поиска?

(пауза)

— А нет, там база noSQL была.

— Эластик?

(Ремарка от автора: устаревшее название, сейчас Elastic Search потеряло популярность, более популярный форк называется иначе)

— Да, он, на нем был движок для поиска на платформе.

— И как вы там создавали таблицы?

(Ремарка от автора: таблиц там нет, другой термин)

(Звуки пыхтения и паники)

— Хорошо, а как данные хранятся в эластике, за счет чего происходит поиск?

(Кандидат отключается)

Визуализация: поток кандидатов и отсева

Не учитывался отсев резюме кадровыми агентствами и моими коллегами из HR. С учётом их фильтрации, думаю, воронка была бы ещё уже.

Что же в сухом остатке? А в сухом остатке у нас:

• укомплектованный стрим, 5 новых разработчиков: первый уже отработал год, последний недавно прошёл испытательный срок.

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

• ещё помог найти сильных разработчиков в дружественный стрим.

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

Вообще рассказ, о моей команде заслуживает отдельной статьи. И она будет.

Выводы

• В 2023–2024 рынок IT раздувался: вакансии, курсы быстрого обучения, инфоцыгане.

• Кандидаты с красивыми резюме, но без практики, доходят до финальных этапов.

• Проблема не в HR, а в новой реальности, где мошенники адаптируются быстрее бизнеса.

• Всё больше людей используют ИИ, но те, кто умеют, идут в другую область.

• Списки вопросов из интернета бесполезны — только кастомные задачи.

• Импровизация и адаптация — лучшая защита от заученных ответов.

• Live-coding и код-ревью — надёжный фильтр практических навыков.

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

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

За год мы нашли важный баланс: не усложнять процесс отбора до абсурда в 10 этапов, но и не пропускать "волчат". У нас люди работают с людьми. Мы предпочитаем быть, а не казаться.