← Блог
5 августа 2026 г.8 minhiring

Вчера я отсобеседовал десять разработчиков. Не взял ни одного

Шестеро решили live-coding идеально. Четверо из шестерых через десять минут не смогли объяснить свой же код. Как я теперь провожу собеседования - и почему старый фильтр больше не фильтрует.


На этой неделе я отсобеседовал десять разработчиков. Не взял ни одного.

Это был один из тех проектов, когда клиент просит «помочь с наймом», а ты в итоге сидишь шесть часов подряд в Zoom и смотришь, как мимо тебя проходят senior backend'ы, один другого идеальнее. Чтобы всё не встало совсем, я запустил формат «три встречи в день с перерывом на кофе, и на обед - ещё три». К вечеру четверга у меня было десять встреч, десять заполненных форм в Airtable и стойкое ощущение, что я делаю что-то не так.

Шесть из десяти решили live-coding идеально. Четверо из этих шести через десять минут не смогли объяснить свой же код. «Ну… потому что так принято» - прямая цитата. В качестве обоснования, почему человек выбрал именно такую структуру данных.

Я закрыл последний звонок. Записал в табличку «нет». Написал HR, что ищем дальше. И стал смотреть на свой кофе, который, как я только сейчас заметил, остыл часа два назад.

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


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

Фильтр работал на механическое знание. Помнит ли человек, как устроен B-tree. Может ли за десять минут собрать приоритетную очередь. Может ли объяснить двухфазный коммит, не сказав при этом обиженно «ну это очень глубокий вопрос».

В 2026 этот фильтр сломался, и дело не в том, что разработчики стали хуже: просто у всех на второй вкладке открыт claude.ai. Любой второкурсник в две кнопки решает средний алгоритм за восемь минут - не потому что знает, а потому что умеет спросить. И модель выдаёт ему код вместе с готовыми комментариями по ходу: «Я использую хэш-таблицу, потому что нам важна скорость доступа по ключу...» - аккуратные, уверенные, как будто он три года с этими коллекциями работал.

Это не мошенничество. По крайней мере, не в том смысле, в каком было мошенничеством списанное домашнее задание в 1998 году. Скорее всего, этот же человек завтра придёт на работу и будет использовать модель точно так же. И это, честно говоря, нормально - я сам работаю точно так же.

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


Вторая и третья встречи в тот день прошли у меня в режиме «я не понимаю, что происходит». Кандидат решил задачу за двенадцать минут, и решение было… хорошим. Прямо честно хорошим. Правильная структура данных, аккуратная обработка крайних случаев, читаемые названия переменных. Я в своей практике писал хуже.

На четвёртой встрече я сменил подход. Кандидат написал решение. Я закрыл IDE. Поговорил с ним минут пять о чём-то постороннем - помню, мы обсуждали, правда ли Лиссабон сейчас дешевле Барселоны (спойлер: уже нет). Вернулся к коду. Спросил:

  • Почему ты выбрал именно этот тип коллекции?

  • Эм… потому что… стандартно так.

  • А если у нас N будет десять миллионов?

  • Ну, так же работает.

  • А что изменится, если ты поменяешь вот эту строку на вот эту?

Пауза. Долгая.

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

Модель может написать код. Не может объяснить его как твой собственный код, если твоего собственного кода нет.


С этого момента я перестроил весь формат. Теперь он выглядит примерно так.

Задачу я, конечно, даю. Но не с leetcode. Я теперь выбираю что-то из реальной проблемы, с которой сам месяц назад возился, - с контекстом, с ограничениями, с намёком на компромисс. Что-то вроде: «есть три варианта архитектуры. Выбери и объясни». Не «реализуй очередь с приоритетом». Потому что реальная работа состоит из компромиссов, а не из leetcode.

Модель тоже умеет рассуждать о компромиссах. Но она усредняет. Выбирает «как в индустрии принято», «как у фаанга». Сильный кандидат выбирает иначе, потому что видит нюанс. Слабый вместе с моделью выбирает по книге. И когда я посреди разговора кидаю в воду камень - «а если у нас критична не скорость записи, а скорость чтения в час икс, когда все синхронизируются?» - слабый зависает, сильный перестраивает.

Это сложнее подделать через чат, потому что я ломаю темп. Добавляю ограничение, уточняю контекст, меняю вопрос. Каждое уточнение должно отразиться в ответе. Кандидат с моделью во второй вкладке за этим темпом не успевает.

Ещё я добавил вопрос про ошибку. Не про абстрактную «расскажи о своём слабом месте» - а про конкретную. «Расскажи о техническом решении, которое ты сделал и о котором жалеешь. Что понял?» Сильный помнит всё в деталях: тот проект, ту базу, ту историю, как они три дня искали утечку памяти, которая, как выяснилось, сидела в одной несчастной библиотеке, о которой никто не подозревал. Слабый - отвечает обобщениями. Или пересказывает статью с Medium'а, которую я уже успел прочитать.

И, наконец, я перестал делать live-кодинг в чистом виде. Формат «напиши с нуля» я теперь практически не использую. Вместо него - «вот существующий кусок кода, давай улучшим вместе». Это намного сложнее подделать через AI, потому что темп задаю я, фокус задаю я, и уточнения сыплются в реальном времени. Кандидату приходится думать, а не генерировать.


Что перестало иметь значение.

Скорость написания кода не фильтрует. Она теперь у всех одинаковая, потому что это функция модели, а не человека. Сертификаты - «посмотрел двадцать минут видео и нажал кнопку», сейчас 2026-й. Портфолио на GitHub - уже не гарантия, потому что половина коммитов сгенерирована, а оставшаяся, если честно, - тоже.

Что подорожало, я тоже для себя сформулировал.

Умение формулировать задачу. Половина работы - это перевод «хочу, чтобы работало» в спецификацию. В эпоху AI этот навык стал важнее кода. Без него человек с моделью выдаёт тонну красивого нерабочего кода.

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

Понимание бизнес-контекста. «Почему мы делаем X, а не Y». Это та часть, которую модель не подхватит даже с RAG-ом, потому что её нет в публичных источниках. Она в голове у людей, которые шесть раз лично видели, как рушится конкретная продажа на одной и той же точке.


В пятницу я отдал клиенту отчёт. Не взял никого. Рекомендовал переделать формат - не искать сеньора, который идеально решает алгоритм, а искать человека, который может пошагово объяснить чужой код. Это, как ни странно, в 2026 редкий и заметно более дорогой навык.

Клиент согласился. Мы переписали вакансию. Первая же встреча после перестройки - женщина, которая не торопилась, задавала встречные вопросы, один раз открыто сказала «не знаю», а потом пошла разбираться с Google в режиме «покажите мне ваш бардак, я распутаю». Взяли её. Она работает там уже три месяца, и проекту от этого стало заметно лучше.

Хороший кандидат в 2026 - тот, кто думает системно и умеет работать с инструментом, а не тот, кто помнит API наизусть. Фильтровать по «может ли он написать код» - это теперь то же самое, что собеседовать плотника на «может ли он поднять молоток». Конечно может. Все могут. Молоток теперь продают в каждом супермаркете.

Спрашивай, что он собирается им построить.

Mike Fluff← Блог