Я — сертифицированный технический интервьюер в 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 месяц). Только реальная работа в команде, с реальным легаси, багами и дедлайнами может показать истинную квалификацию инженера. Всё остальное — гадание на кофейной гуще.
В последующих статьях я постараюсь порассуждать более детально на тему решения проблемы технических интервью и подходов к оценке в эпоху ИИ.
Комментарии (13)
cololoster
13.01.2026 22:39верю, что главное в IT HR это абсолютная доминация софт скилов над хардами.
софт скилов в максимально широком понимании, не какой-то там коммуникабельности, а того как человек относится к жизни :) зачем вообще он что-то делает на самом деле, чего он ищет, стыдно ли ему ошибиться, насколько он готов быть разным в разных ситуациях, допустимо ли ему махнуть рукой и "забить", что он делает когда ничего не понятно и т.п.
и это кажется измеряется разговорами о прошлом опыте, не обязательно рабочем.
aamonster
13.01.2026 22:39Возможно, нам стоит вернуться к практике оплачиваемых испытательных сроков
А что, от неё успели отказаться? Помнится, обычно было 3 месяца, но могли досрочно объявить, что ты прошёл испытательный срок.
Verona90210
13.01.2026 22:39Подход с серией коротких задач выглядит разумнее как по мне. Так хоть реально видно, как человек ориентируется в разных областях, а не как он умеет оптимально решать одну конкретную задачу под таймер
opusmode
13.01.2026 22:39Статья толковая и разумная, однако не про IT рынок. Не забываем, что сейчас тут во множестве своём не профессионалы, а те, кто вкатились 5 лет назад, плюс пачка староверов, которым бы самим подтянуть знания и компетенции.
Меня собеседовали по инфраструктуре и я почти не видел на собеседовании реально заинтересованных людей, понимающих, кого и зачем они ищут, с чем человеку работать, какой результат нужен.
Более того, сами собеседующие завалили бы аналогичный собес у меня. Когда человек распрашивает о решении задачи, получает ответ и говорит, что так задачу не решить и такого функционала нет, а ты сидишь и понимаешь, что он документацию уже лет 5 не открывал и просто не знает, о чём говорит.
Мне реально пару раз отказывали из-за того, что я предлагал решение, которое казалось сомнительно чудесным, хотя я пересказывал свой опыт, а человек застрял году так в 2018.
Допом, кстати, в инфраструктуре реально любят спрашивать об адово устаревшем и не любят, когда им говорят, что они делают дорогие и не осень надёжные решения и что бы пройти собес надо буквально пересказывать устаревшие подходы, ведь актуальные оценить не смогут.
Не говорю уж о любви решать несуществующие проблемы, которые на той стороне кажутся важными, просто из-за низкого профессионализма
pg_expecto
13.01.2026 22:392. Разрыв между вопросами и реальными задачами
Не далее как вчера , вопрос "какие базы данных создаются после инсталляции кластера PostgreSQL?" :-) вы серьёзно считаете , что ответ на этот вопрос полезен и имеет смысл ?
Или "что произойдёт при выполнении команды Explain analyze drop database...".
Я честно ответил, что за 20 лет работы с СУБД мне в голову не приходила мысль о принципиальной возможности и необходимости запустить такой explain. И прямо ответил - не знаю, может стоит защита от дурака , а может грохнете базу с такими экспериментами.
Смысл тратить время на такие вопросы ? Хотя с другой стороны , что делать с собеседованиями , я, не знаю. По личному опыту во времена тимлидерства - я вообще не смотрел хард скилы, старался оценить софт скилы, но для этого нужно иметь большой жизненный опыт и хоть какой то психологический бекграунд.
kimisa
13.01.2026 22:39Я честно ответил, что за 20 лет работы с СУБД мне в голову не приходила мысль о принципиальной возможности и необходимости запустить такой explain.
Да, бывают дают такие тонкости и говорят, что вы должны понимать. А зачем понимать, если я так не пишу код? И никогда не напишу, зная об особенностях.
panzerfaust
13.01.2026 22:39Игнорирование реальности 2026 года (AI)
Игнорирование неподходящее слово. Когда корпы в 4:19 заявляют "кто не вайбкодит - тот лох", а в 4:20 заставляют людей вращать деревья на листочке, то это глумление, а не игнорирование.
dmitrijtest24
13.01.2026 22:39Я — сертифицированный технический интервьюер в EPAM
А можно тут по подробнее? Сертифицированный где и кем?
в текущих реалиях практически невозможно достоверно установить реальный уровень кандидата ни за одно интервью
А оно таки вам нужно? Где то это используется во внутренней кухне?
Насколько я слышал в Епаме завышают уровень что бы подороже продать.
P.S. в целом по статье вы правы, но есть нюансы...
kenomimi
13.01.2026 22:39А можно тут по подробнее? Сертифицированный где и кем?
У них неплохая внуренняя сертификация, плюс они гоняют ключевых сотрудников на всякие крутые курсы повышения квалификации. Вопрос только в том, что даже крутые курсы не учитывают специфику работы вашей компании, и чтобы знания оттуда начинали эффективно работать, надо мощно шевелить мозгами самому. С чем у большинства проблемы, средний человек привык принимать все знания на веру, и относиться к ним как к высеченным в граните догмам - "это сказал великий авторитет, кто ты такой, чтобы делать иначе". Вот и получаем собесы по бумажке с идиотичными вопросами и оторванной от реальности тематикой...
apevzner
13.01.2026 22:39Мне кажется, в режиме live coding-а достаточно дать одну-две простые задачи на массивы (скажем, подсчёт количества элементов в массиве целых чисел, которые равны среднему арифметическому своих соседей), чтобы просто убедиться в том, что кандидат учитывает corner cases и, тем самым, пишет надёжный код, который не ломается, если массив оказался нулевой длины или состоит из одного элемента. Ну и задаёт правильные вопросы, типа того, учитывать ли крайние элементы, у которых, естественным образом, не полный набор соседей.
Что до оценки квалификации, можно сколько угодно гонять по теории, но в результате вы наймёте теоретиков. Задайте вопрос, который редко освящают в учебниках, и на который можно наткнуться на практике, и уровень кандидата станет сразу понятным.
Но тут надо соотноситься с вашими реальными требованиями. Вам точно нужны люди, разбирающиеся в сетях на уровне разработчика TCP/IP стека, или вам достаточно, чтобы кандидат не путал TCP с UDP и понимал, что то, какими порциями данные отправляются в TCP-сокет не обязательно совпадает с тем, какими порциями они оттуда вычитываются с другой стороны? Вам точно нужны люди, способные руками реализовать HTTP на голых сокетах, или достаточно понимания, что нет такого понятия, как HTTP-соединение и знают, в каких corner cases оно таки может вылезти, вопреки стандартной семантики?
MonkAlex
Вопрос по ИИ. Я сейчас в ситуации, когда в рабочем контуре нет доступа к ИИ. Реального опыта разработки с ИИ продуктового качества - нет. Пару лет назад я пробовал бесплатные инструменты и они были очень плохи, но ИИ развивается и сейчас ситуация, понятно, лучше.
Насколько я понимаю, у кого-то ИИ разрешён и даже рекомендуется. Насколько он действительно важен с точки зрения "скила"? Сколько времени у опытного разработчика займет обучение использованию конкретного ИИ инструмента на конкретном проекте? Есть ли в этом отличие от уже существующих вопросов обучения новых сотрудников - погружение в предметную область, погружение в кодовую базу, в рабочие процессы команды\отдела?
И отдельный вопрос к тем, у кого ИИ недоступен. Пробуете ли вы его где-то вне работы? Есть ли хорошие бесплатные инструменты? Есть ли недорогие и качественные инструменты? Потому что для меня сейчас это звучит примерно как "купи лицензию на крутой инструмент", но мой опыт говорит что знания всё равно должны быть мои, а ИИ разве что рутину уберёт, усложнив в реальности оставшуюся работу для меня (уплотнив её, убрав легкие части).
Verona90210
ИИ реально убирает рутину, но за счет этого повышается плотность сложных задач. Легкая часть исчезает, а думать приходится больше, а не меньш
BlackScreenn
Искусственный интеллект лишь делает нашу работу удобнее, но на практике нам всё равно нужно быть внимательными и разбираться глубже. Он лишь помогает легче получить доступ к информации.