Рекрутеры пишут тексты вакансий и отбирают резюме с помощью нейросетей, кандидаты готовят ответы и даже решают задачи с подсказками ИИ, а многие ИТ-компании в 2025 году снова стали проводить интервью офлайн. В этой новой реальности старые подходы к собеседованиям теряют эффективность: проверка теории «по учебнику» или стандартный список вопросов не дают объективной картины. Сегодня важно уметь видеть за готовыми ответами реальные навыки, ход мысли и то, насколько человек подходит под конкретный проект.

Привет, Хабр! Меня зовут Никита Королев, я ведущий разработчик мобильных приложений в IBS. Я регулярно провожу собеседования и сегодня хочу поделиться своим видением того, как делать это эффективно для компании и без нервотрепки для обеих сторон.

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

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

Техническая часть собеседования на Flutter-разработчика длилась час и включала в себя такие этапы:

1. Знакомство и рассказ кандидата о себе.

2. Общие теоретические вопросы по архитектуре и разработке (ООП, принципы SOLID, чистая архитектура).

3. Вопросы по теории языка Dart и фреймворка Flutter.

4. Практические задачи с кодом.

5. Рассказ о компании и ответы на вопросы соискателя.

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

Что не работает в плане

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

• Упор на базовую теорию. Последние пару лет любой подкованный джун может настроить распознавание речи интервьюера и на ходу получать ответы от генеративной модели. А значит, пользы от проверки «учебника» все меньше. Куда важнее — увидеть, как кандидат рассуждает, как решает практические задачи и какие примеры из опыта приводит.

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

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

Обращаем внимание на офлайн-интервью

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

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

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

Как стоит подходит к собеседованиям?

Я выделил шесть шагов:

1. Проанализировать требования проекта.

2. Зафиксировать их в тексте вакансии.

3. Адаптировать список вопросов и ожидаемые ответы.

4. Задавать открытые вопросы и не стесняться отходить от сценария.

5. Сформулировать фидбэк по чек-листу.

6. Выбрать кандидата по совокупности факторов.

Теперь пройдемся по каждому пункту подробнее.

Анализ требований

Чтобы понять, кто нужен проекту, важно общаться с заказчиком, читать ТЗ, выяснять все подробности и прикидывать реальные задачи. Иногда релевантный опыт в узкой области важнее, чем «идеальная» теоретическая подготовка. Например, человек может быть не силен в архитектуре, но при этом он отлично знает работу с магазинами приложений — и именно это критично для конкретной вакансии.

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

Составление текста вакансии

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

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

Подготовка вопросов

Пожалуй, самый сложный и неоднозначный этап. Я бы разделил его на три части:

1. Список базовых знаний и хард-скилов

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

Если в компании есть готовая Карта карьеры, где прописаны обязательные навыки, знания предметной области, софт-скилы и права по каждому грейду, то можно взять матрицу из нее.

При этом напрямую задавать вопросы по матрице компетенций не стоит — открытые вопросы работают гораздо эффективнее.

2. Открытые вопросы

На собеседованиях все реже работают «вопросы с одним ответом»: человек может выдать зазубренный или, что еще хуже, подсмотренный у ИИ ответ. Гораздо важнее, чтобы кандидат рассуждал и приводил примеры.

Приведу несколько примеров открытых вопросов:

• Как ты применяешь принцип инверсии зависимостей при написании кода?

• Если ты будешь начинать написание нового проекта, на какие аспекты ты обратишь внимание при выборе архитектуры? Какие действия для старта нового проекта будешь выполнять?

• Во время работы над новой фичей ты замечаешь, что приложение под некоторыми учетками стало загружаться очень долго. Что будешь делать?

Еще один хороший способ понять, насколько глубоко человек понимает предметную область — стать «почемучкой». Например, задаем вопрос: «Зачем в разработке нужен полиморфизм?» Собеседник отвечает: «Чтобы использовать один и тот же интерфейс для разных реализаций». И тут напрашивается: «А зачем нам использовать один и тот же интерфейс для разных реализаций?» Важно не выбесить человека, но докопаться до истины: действительно ли он понимает тему или просто заучил формулировку. Другими словами, этот метод можно описать как «объясни бабушке свою работу». Если человек способен объяснить сложную ИТ-теорию своими словами, это одновременно признак глубоких знаний и показатель хороших коммуникативных навыков.

3. Практические задачи

Для разработчика это будут задачи, связанные с конкретным языком программирования или фреймворка, для аналитика или продакта — разбор какого-нибудь кейса. Главное, чтобы задачи были подготовлены индивидуально под вакансию и показывали ход мысли. Правильного ответа тут может и не быть (и даже лучше, если его не будет).

Во время интервью

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

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

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

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

При этом полезно сразу отмечать «красные флаги»:

? грубость или панибратство;

? обесценивание процессов (код-ревью, документация);

? обесценивание работы коллег по команде или желание работать в одиночку;

? пробелы в базовых знаниях;

? отсутствие вопросов к интервьюеру.

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

Фидбэк

После собеседования важно как можно быстрее, пока воспоминания свежи, составить на основе своих заметок полноценный фидбэк.

• для рекрутера — разбор конкретных ответов и вывод о релевантности;

• для кандидата — спокойная и обучающая обратная связь.

Фидбэк стоит отправлять всем кандидатам, даже тем, кто явно не подошел. Если вы видите, что кандидат серьезно проседает в определенной теме, не лишним будет дать рекомендации курса, статьи или направление развития. Вам несложно, а человеку полезно. А заметки лучше хранить: через год тот же кандидат может прийти снова, и вы увидите прогресс.

Приведу несколько цитат из своих старых фидбэков и то, как бы я их сегодня исправил:

Выбор между кандидатами

Когда соискателей много, решать приходится по чек-листу и… интуиции. При первой встрече сложно сразу сформировать устойчивое мнение о человеке. Он не имел возможности показать себя в разных рабочих ситуациях, поэтому опираться приходится на один — максимум два разговора. Задайте себе вопрос: «Хотел бы я работать рядом с этим человеком каждый день?» Это важнее, чем количество «галочек».

Несколько наблюдений о собеседованиях напоследок

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

• Тестовые задания уже не актуальны. Их слишком легко решить с помощью ИИ.

• Нельзя превращать интервью в собственный бенефис. Нужно говорить меньше, а слушать больше.

• Волнение — это нормально, причем с обеих сторон. Даже если человек забыл какую-то базовую теорию, это не обязательно «красный флаг». Возможно, кандидат просто очень хочет попасть именно на эту работу.

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

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

• Полезно тренироваться — проводить тестовые интервью с коллегами. Особенно если вы новичок в проведении собеседований или хотите поменять процесс.

А главное — идеального кандидата не существует, но всегда есть максимально подходящий для проекта. Осталось только его найти.