Рекрутеры пишут тексты вакансий и отбирают резюме с помощью нейросетей, кандидаты готовят ответы и даже решают задачи с подсказками ИИ, а многие ИТ-компании в 2025 году снова стали проводить интервью офлайн. В этой новой реальности старые подходы к собеседованиям теряют эффективность: проверка теории «по учебнику» или стандартный список вопросов не дают объективной картины. Сегодня важно уметь видеть за готовыми ответами реальные навыки, ход мысли и то, насколько человек подходит под конкретный проект.
Привет, Хабр! Меня зовут Никита Королев, я ведущий разработчик мобильных приложений в IBS. Я регулярно провожу собеседования и сегодня хочу поделиться своим видением того, как делать это эффективно для компании и без нервотрепки для обеих сторон.
Как мы проводили интервью раньше и что не нравится теперь?
Когда я устроился в IBS, в нашем отделе мобильной разработки уже был план собеседований, составленный другим тимлидом. Я добавил в него пару деталей, но в целом структура оставалась неизменной до середины 2024 года.
Техническая часть собеседования на Flutter-разработчика длилась час и включала в себя такие этапы:
Знакомство и рассказ кандидата о себе.
Общие теоретические вопросы по архитектуре и разработке (ООП, принципы SOLID, чистая архитектура).
Вопросы по теории языка Dart и фреймворка Flutter.
Практические задачи с кодом.
Рассказ о компании и ответы на вопросы соискателя.
Сложность вопросов повышалась от одного грейда к другому, но общая схема собеседования почти всегда сохранялась. Недавно я пересмотрел этот план и понял, что он заметно устарел, а многие вопросы теперь кажутся пустой тратой времени.
Что не работает в плане
Единый сценарий для всех вакансий. Мы проверяли только общие знания, почти не учитывая специфику проекта. В итоге кандидата можно было взять на проект, где его навыки не так полезны.
Упор на базовую теорию. Последние пару лет любой подкованный джун может настроить распознавание речи интервьюера и на ходу получать ответы от генеративной модели. А значит, пользы от проверки «учебника» все меньше. Куда важнее — увидеть, как кандидат рассуждает, как решает практические задачи и какие примеры из опыта приводит.
Нет единого подхода к оценке. Каждый интервьюер пишет фидбэк рекрутеру в свободной форме: кто-то подробно разбирает ответы, кто-то передает общее впечатление от общения, а кто-то просто не заморачивается. Из-за этого команда может по-разному интерпретировать результат.
Фокус только на онлайн-формат. План изначально писался под удаленные собеседования. Но после возвращения в офис мы снова проводим офлайн-встречи, и они работают иначе.
Обращаем внимание на офлайн-интервью
В первую очередь на очных встречах сложнее подглядеть ответ. Кандидаты чаще ошибаются даже в знакомых вещах — и это нормально. К ошибкам стоит относиться лояльнее.
С кодом ситуация интереснее. Раньше на собеседованиях давали задание написать код на бумаге, и многие разработчики, включая меня, побаивались этого этапа. Сегодня я бы рекомендовал комбинировать два этапа: сначала решение на бумаге, потом в IDE с любыми помощниками. И показательна тут будет не только разница в качестве решения, но и в затраченном времени. Не стоит ставить крест на человеке, не решившем задачу на бумажке, в конце концов, в работе он будет пользоваться помощниками. Здесь гораздо важнее верный ход мысли.
И еще один совет: если кандидат приходит в офис, не нужно ограничиваться только интервью в переговорке. Проведите в начале экскурсию, покажите рабочие места и зоны отдыха, чтобы собеседник расслабился и представил, где ему предстоит работать.
Как стоит подходит к собеседованиям?
Я выделил шесть шагов:
Проанализировать требования проекта.
Зафиксировать их в тексте вакансии.
Адаптировать список вопросов и ожидаемые ответы.
Задавать открытые вопросы и не стесняться отходить от сценария.
Сформулировать фидбэк по чек-листу.
Выбрать кандидата по совокупности факторов.
Теперь пройдемся по каждому пункту подробнее.
Анализ требований
Чтобы понять, кто нужен проекту, важно общаться с заказчиком, читать ТЗ, выяснять все подробности и прикидывать реальные задачи. Иногда релевантный опыт в узкой области важнее, чем «идеальная» теоретическая подготовка. Например, человек может быть не силен в архитектуре, но при этом он отлично знает работу с магазинами приложений — и именно это критично для конкретной вакансии.
Не стоит забывать и про софт-скилы. В одних проектах ценится умение самостоятельно «копать» задачу, в других достаточно работать по готовому описанию из Jira. Главный принцип: ищем не «лучшего вообще», а подходящего для конкретного проекта.
Составление текста вакансии
Уже не раз сталкивался с ситуацией, когда описание вакансии полностью пишет рекрутер без участия технических специалистов. На мой взгляд, HR-отделу можно доверить только «продающую часть» и бонусы, а вот за требования должен отвечать технарь. Для каждого отдела можно создать базовое описание вакансии с помощью ИИ, а далее адаптировать требования вручную под проект и заверять у руководителя или заказчика.
С рекрутерами вообще нужно выстроить максимально партнерские отношения, ведь ваша работа зависит во многом от них. Посвящать рекрутеров в особенности своей работы, рассказывать про основные обязанности своего отдела — это правильный подход, который позволит людям, не очень многое понимающим в ИТ, быть более продуктивными. В идеале, конечно, самому приходить на скрининги и отбирать резюме, если на это есть время.
Подготовка вопросов
Пожалуй, самый сложный и неоднозначный этап. Я бы разделил его на три части:
1. Список базовых знаний и хард-скилов
Удобно заранее составить матрицу компетенций по грейдам — и периодически ее обновлять. Можно представить в виде таблицы, например, так:
Junior | Middle | Senior | Team Lead | |
Принципы SOLID | + | + | + | + |
Виды join в SQL | – | ? | + | + |
Способы связи с нативным кодом во Flutter | – | – | + | + |
Если в компании есть готовая Карта карьеры, где прописаны обязательные навыки, знания предметной области, софт-скилы и права по каждому грейду, то можно взять матрицу из нее.
При этом напрямую задавать вопросы по матрице компетенций не стоит — открытые вопросы работают гораздо эффективнее.
2. Открытые вопросы
На собеседованиях все реже работают «вопросы с одним ответом»: человек может выдать зазубренный или, что еще хуже, подсмотренный у ИИ ответ. Гораздо важнее, чтобы кандидат рассуждал и приводил примеры.
Приведу несколько примеров открытых вопросов:
Как ты применяешь принцип инверсии зависимостей при написании кода?
Если ты будешь начинать написание нового проекта, на какие аспекты ты обратишь внимание при выборе архитектуры? Какие действия для старта нового проекта будешь выполнять?
Во время работы над новой фичей ты замечаешь, что приложение под некоторыми учетками стало загружаться очень долго. Что будешь делать?
Еще один хороший способ понять, насколько глубоко человек понимает предметную область — стать «почемучкой». Например, задаем вопрос: «Зачем в разработке нужен полиморфизм?» Собеседник отвечает: «Чтобы использовать один и тот же интерфейс для разных реализаций». И тут напрашивается: «А зачем нам использовать один и тот же интерфейс для разных реализаций?» Важно не выбесить человека, но докопаться до истины: действительно ли он понимает тему или просто заучил формулировку. Другими словами, этот метод можно описать как «объясни бабушке свою работу». Если человек способен объяснить сложную ИТ-теорию своими словами, это одновременно признак глубоких знаний и показатель хороших коммуникативных навыков.
3. Практические задачи
Для разработчика это будут задачи, связанные с конкретным языком программирования или фреймворка, для аналитика или продакта — разбор какого-нибудь кейса. Главное, чтобы задачи были подготовлены индивидуально под вакансию и показывали ход мысли. Прави��ьного ответа тут может и не быть (и даже лучше, если его не будет).
Во время интервью
Итак, у вас есть список вопросов и собеседник перед глазами. Вы начинаете идти по подготовленному сценарию, но это уже ошибка. Цель собеседования — не столько получить правильные ответы, столько понять, подходите ли вы друг другу и подходит ли человек под вакансию и проект. В этом плане интервью гораздо ближе к свиданию, чем к допросу.
Если собеседник отвечает подробно, интересно и даже уходит в посторонние темы, поддержите его. Задавайте уточняющие вопросы, переходите по нити интервью туда, куда она завела, а не обрывайте человека на полуслове фразой «Спасибо, этого достаточно». Такое можно себе позволить, только если человека действительно сложно остановить или он пытается максимально абстрактно ответить на конкретный вопрос и нарочно тянет время.
Во время или сразу после интервью стоит применять матрицу компетенций. Имеет смысл ставить оценки с текстовым комментарием. Вполне может получиться, что с разными соискателями вы затрагиваете темы в разных пропорциях, а некоторые не затрагиваете совсем, и это нормально. Здесь важно выбрать ключевые слова или критерии для каждой темы, которые дадут понять, что человек разбирается в вопросе. Причем при накоплении опыта в интервью могут появляться новые критерии, и важно их фиксировать и запоминать на будущее.
Заметки по ходу интервью важно делать еще тогда, когда собеседования идут потоком, по несколько в день. В такие моменты высок шанс запутаться в кандидатах, поэтому нужно заранее выработать систему фиксации данных о каждом кандидате. Лично я пользуюсь простыми заметками в текстовом редакторе Obsidian.
При этом полезно сразу отмечать «красные флаги»:
🚩 грубость или панибратство;
🚩 обесценивание процессов (код-ревью, документация);
🚩 обесценивание работы коллег по команде или желание работать в одиночку;
🚩 пробелы в базовых знаниях;
🚩 отсутствие вопросов к интервьюеру.
В крайнем случае такие сигналы позволяют завершить собеседование раньше времени.
Фидбэк
После собеседования важно как можно быстрее, пока воспоминания свежи, составить на основе своих заметок полноценный фидбэк.
для рекрутера — разбор конкретных ответов и вывод о релевантности;
для кандидата — спокойная и обучающая обратная связь.
Фидбэк стоит отправлять всем кандидатам, даже тем, кто явно не подошел. Если вы видите, что кандидат серьезно проседает в определенной теме, не лишним будет дать рекомендации курса, статьи или направление развития. Вам несложно, а человеку полезно. А заметки лучше хранить: через год тот же кандидат может прийти снова, и вы увидите прогресс.
Приведу несколько цитат из своих старых фидбэков и то, как бы я их сегодня исправил:
Выбор между кандидатами
Когда соискателей много, решать приходится по чек-листу и… интуиции. При первой встрече сложно сразу сформировать устойчивое мнение о человеке. Он не имел возможности показать себя в разных рабочих ситуациях, поэтому опираться приходится на один — максимум два разговора. Задайте себе вопрос: «Хотел бы я работать рядом с этим человеком каждый день?» Это важнее, чем количество «галочек».
Несколько наблюдений о собеседованиях напоследок
Чем выше грейд, тем больше должно быть этапов интервью. На стажера/джуна можно выделить меньше часа, чтобы понять, что он в чем-то разбирается и не соврал в резюме. Лида нужно проверять гораздо тщательнее, возможно, в несколько этапов, но максимум в трех до заказчика: знакомство с рекрутером, технический скрининг до получаса и большое техническое интервью на час-полтора.
Тестовые задания уже не актуальны. Их слишком легко решить с помощью ИИ.
Нельзя превращать интервью в собственный бенефис. Нужно говорить меньше, а слушать больше.
Волнение — это нормально, причем с обеих сторон. Даже если человек забыл какую-то базовую теорию, это не обязательно «красный флаг». Возможно, кандидат просто очень хочет попасть именно на эту работу.
Соискатели не менее требовательны, чем компании. Нужно быть готовым к тому, что не только вы выбираете, но и вас выбирают, и даже после предоставленного оффера все потраченное время может быть впустую из-за отказа по совершенно любой причине.
Опытные соискатели могут нести ахинею очень уверенным тоном. Распознать это способны не все, но этот навык приходит с опытом.
Полезно тренироваться — проводить тестовые интервью с коллегами. Особенно если вы новичок в проведении собеседований или хотите поменять процесс.
А главное — идеального кандидата не существует, но всегда есть максимально подходящий для проекта. Осталось только его найти.
