Я — сертифицированный технический интервьюер в EPAM. За плечами у меня около 800 проведенных интервью: от общих технических скринингов до финальных проектных этапов. Такая выборка позволяет видеть паттерны, которые скрыты от глаз обычного разработчика или менеджера. И мой главный вывод неутешителен: в текущих реалиях практически невозможно достоверно установить реальный уровень кандидата ни за одно интервью, ни за серию встреч.

Да, я знаю про опыт BigTech компаний. Они экспериментируют, устраивая марафоны из 4–5 секций подряд, пытаясь имитировать «реальный рабочий день». Но давайте будем честны: это имитация, которая не имеет ничего общего с реальностью. И вот почему.

1. Фактор нервозности и искажение реальности Интервью — это не работа, это экзамен под прицелом. У каждого своя степень стрессоустойчивости. Я видел десятки случаев, когда у кандидата буквально отключался мозг от того, что на него смотрят и комментируют каждую строчку кода. В спокойной обстановке этот человек может писать гениальные решения, но в режиме live-coding, когда интервьюер дышит в спину, он забывает синтаксис языка. И наоборот: есть люди с превосходными навыками самопрезентации, которые уверенно пишут плохой код, но делают это с таким видом, что джуниор-интервьюер ставит им «Strong Hire». Мы оцениваем не навык разработки, а навык прохождения интервью.

2. Разрыв между вопросами и реальными задачами Очень часто задания на интервью абсолютно оторваны от того, что человек будет делать на проекте. Классический пример: секция System Design. Это стандарт де-факто в бигтехе и крупных аутсорсерах. Мы просим кандидата спроектировать условный Uber или Instagram, обсуждаем шардирование баз данных и балансировку нагрузки. При этом человека рассматривают на роль Senior-разработчика, который ближайшие два года будет писать бизнес-логику в уже устоявшемся монолите или микросервисах. Ему никто не даст ничего проектировать с нуля. Возникает стойкое ощущение, что отделы найма просто усложняют процесс, чтобы продемонстрировать начальству свою «изобретательность» и важность, создавая искусственные барьеры там, где они не нужны.

3. Глубина против широты: мой подход Из своего опыта я понял, что стандартная «одна большая задача на час» — это тупик. Кандидат тратит кучу времени на обдумывание архитектуры, пытается заложить риски для усложнений, которых не будет. За стандартные 50 минут качественно решить комплексную задачу невозможно. Мне гораздо больше нравится подход охвата через короткие задания. Я даю серию маленьких, изолированных задач из разных областей.

  • Во-первых, у кандидата меньше стресса. Не решил одну — перешли к следующей, нет ощущения провала.

  • Во-вторых, так мы проверя��м реальный кругозор. Вместо того чтобы копать одну узкую тему (которая может не быть сильной стороной кандидата), мы видим весь диапазон знаний. Пусть есть пробелы — они есть у всех. Но такой подход позволяет увидеть, что человек интересуется индустрией, знает нюансы разных технологий, а не просто заучил алгоритм обхода бинарного дерева.

4. Подсчет ошибок vs Процесс мышления Многие интервьюеры считают своей главной задачей найти, где кандидат ошибся. Это в корне неверно и контрпродуктивно. Кандидат понимает, что идет «подсчет штрафных баллов», и начинает ошибаться еще больше. В реальном проекте мы так не работаем. Разработка — процесс непрерывный и итеративный. Мы думаем, пробуем решение, пишем тесты, рефакторим, обсуждаем с коллегами. Никто не пишет идеальный код с первой попытки начисто. Но на интервью от нас почему-то ждут именно этого.

5. Игнорирование реальности 2026 года (AI) На дворе 2026 год, а кандидатов все еще заставляют стыдиться использования ИИ, или вовсе запрещают его на интервью. Это абсурд. Последние три года ИИ — это неизбежный и необходимый инструмент. Более того, для меня, как для техлида, если разработчик не использует ИИ — это редфлаг. Это значит, что он менее эффективен. Но интервьюеры продолжают работать по методичкам пятилетней давности, потому что просто не понимают, как валидировать знания, если кандидат использует Copilot или LLM. (Это тема для отдельной статьи, но проблема острая).

Что с этим делать? Я считаю, что индустрии пора пересмотреть подход к найму. Многоэтапные интервью часто дают ложноположительные результаты: кандидат пускает пыль в глаза, блестяще проходит теорию, а на реальном проекте оказывается бесполезен. И наоборот — человек, «заваливший» лайв-кодинг из-за стресса, мог бы стать звездой команды.

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

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