Почему классические теоретические собеседования теряют смысл
Техническое интервью держалось на простом допущении: если человек объясняет, как устроена хеш-таблица, значит, он предскажет её поведение в реальном коде. В 2026 году это допущение сломалось. Автор поста «Собеседования на программиста в эпоху AI» формулирует причину прямо: кандидату ничего не стоит посадить рядом нейросеть с live-моделью, которая слушает вопрос и выдаёт ответы даже на сложные вопросы быстрее, чем интервьюер закончит формулировку.
Короткий ответ на главный вопрос: проверять знание терминов бессмысленно, потому что знание теперь достаётся в один клик. Вместо этого работают два формата, которые называет автор поста. Первый - разбор реального опыта: задач, которые кандидат решал, и граблей, на которые наступал. Второй - live code review, разбор специально подготовленного проблемного кода. Оба смотрят на одно и то же: умеет ли человек применить теорию и видит ли он контекст задачи.
Как live-агент обесценивает проверку теории
Сценарий будничный. Кандидат подключается к созвону, рядом лежит телефон или второй ноутбук с запущенной моделью и распознаванием речи. Вопрос «чем Thread отличается от Task» уходит в аудио, ответ появляется текстом на экране, человек читает его вслух. Интервьюер тратит на формулировку и ожидание реакции больше времени, чем модель на генерацию ответа.
Ключевое слово здесь - live. Раньше помощником на собеседовании был чат в соседней вкладке: вопрос приходилось перепечатывать руками, а это заметно по паузам и движению глаз. Теперь модель слушает поток и отвечает в реальном времени, поэтому снаружи всё выглядит как уверенная речь без подготовки. Автор поста считает, что персональные агенты-помощники на интервью вот-вот станут нормой, а не читерством.
Отличить такого кандидата по голосу или темпу речи почти невозможно. Единственное сопротивление - вопросы, ответ на которые нельзя выдать заготовкой, потому что он зависит от конкретного контекста: нагрузки, версии рантайма, приоритетов команды.
Почему заученная теория больше не показатель
Дело не только в агентах. Список классических вопросов давно лежит в открытом доступе десятками подборок: топ-100 вопросов по C#, разборы многопоточности, шпаргалки по коллекциям. Кандидат без реального опыта воспроизводит определение коллизии в хеш-таблице, перечисляет отличия Thread от Task и объясняет async/await. Ровно то же выдаст и модель.
Провал обнаруживается на практике. Человек, который уверенно рассказывает про коллизии, получает код с переопределённым GetHashCode, возвращающим константу, и не находит проблему: определение он видел, а что происходит со словарём на сотнях тысяч ключей - нет. Разрыв между «знаю формулировку» и «понимаю последствия» и есть то, что должно проверять собеседование.
Массовое чтение чужого кода при этом перестало быть редким навыком: команды тратят на ревью всё больше времени, потому что агенты пишут быстрее, чем люди успевают проверять. Подробный разбор этой ловушки - в материале о том, почему скорость генерации кода стала фиктивным KPI.
Формат 1: Обсуждение реального опыта и граблей
Первый формат не требует ни доски, ни IDE. Кандидата просят рассказать о конкретной задаче, которую он решал, и о проблемах, которые вылезли по дороге. Автор поста называет это обсуждением задач и особо запоминающихся граблей и относит такой разговор к своим любимым форматам интервью.
Какие вопросы задавать, чтобы оценить глубину опыта
- Расскажи про самый сложный баг, который ты исправил сам. Как ты понял, где именно ломается?
- Было так, что твоё решение дало неожиданный побочный эффект в продакшне? Что ты делал в первые часы?
- Как ты искал причину дедлока или зависшего запроса? Какие инструменты подключал?
- Какие грабли были при работе с многопоточностью или асинхронностью? Чем всё закончилось?
- Где ты упирался в границы применимости AI-инструментов на своих задачах? Что пришлось делать руками?
Ценность не в сюжете, а в деталях. Реальный опыт обрастает конкретикой: версия рантайма, метрика, за которой следили, шаги диагностики, что показал профайлер, какая гипотеза оказалась ложной. Модель сочинит гладкую историю, но при уточнении «а что показал лог на четырнадцатой минуте» выдумка начинает рассыпаться.
Заодно видно, как человек работает с ограничениями инструментов: где ускоряется ассистентом, а где честно признаёт, что генерация кода не решает задачу. Практический пример такого разбора с чек-листом устойчивости процесса - в статье про магазин за два вечера и границы применимости AI.
Как отличить реальный опыт от выдуманного
Работает серия уточнений. «Почему ты выбрал именно этот подход?», «Что было бы, если бы ты сделал иначе?», «Кто ещё участвовал и что говорил на разборе?». Реальный инженер называет свои промахи и объясняет, что поменял после них. Гладкая история без единого промаха и без альтернатив - сигнал, что её собрали под вопрос.
Полезно спрашивать про решения, которые пришлось откатить, и про то, как команда поняла, что пора откатывать. Live-агент подскажет общий ответ, но не выдержит десяти минут углубления: у него нет деталей проекта, потому что этих деталей нет в открытых источниках. Второй ограничитель - причинно-следственные связи. Слушать стоит не перечисление технологий, а то, как кандидат связывает симптом, гипотезу и проверку.
Формат 2: Live code review проблемного кода
Второй формат устроен так: кандидат получает портянку на 100-200 строк и в реальном времени говорит, что здесь не так и что делать. Пост на Habr приводит конкретные заготовки для такого интервью. Автор отмечает, что раньше такие примеры придумывать было непросто, и на российском рынке он встречал лишь пару компаний с подобной практикой.
Пример задачи: коллизии в хеш-таблице
Первый вариант задачи: дать код с явными проблемами вокруг словаря и попросить разобрать его. Спойлер из поста: в такой портянке не так практически всё.
public sealed class OrderKey
{
public string OrderId { get; init; }
public string Region { get; init; }
public override int GetHashCode()
{
return 0;
}
public override bool Equals(object obj)
{
return obj is OrderKey other
&& other.OrderId == OrderId;
}
}
var index = new Dictionary<OrderKey, decimal>();
foreach (var order in orders)
{
index[new OrderKey { OrderId = order.Id, Region = order.Region }] = order.Total;
}
Что должен заметить кандидат. GetHashCode, возвращающий константу, кладёт все ключи в одну корзину: словарь сравнивает каждый новый ключ с уже лежащими по Equals, и суммарная стоимость вставки N элементов растёт как O(N²) вместо ожидаемого O(N). Плюс Equals игнорирует Region, хотя ключ содержит это поле: два заказа с одинаковым OrderId из разных регионов считаются одним ключом, и второй молча перезаписывает первый.
Сильный ответ идёт дальше синтаксиса: посчитать хеш по тому же набору полей, что участвует в Equals, и держать инвариант «равные объекты дают равные хеши». Слабый ответ - «плохой хеш» без объяснения, к чему это приводит на реальной нагрузке.
Пример задачи: Thread.Start с async void
Второй вариант проверяет ту самую теорию про Thread и Task, только через код, а не через вопрос.
static void Main()
{
var worker = new Thread(async () =>
{
await Task.Delay(500);
throw new InvalidOperationException("background failure");
});
worker.Start();
Console.WriteLine("Main finished");
}
Разбор такой: лямбда подходит под ThreadStart, который возвращает void, поэтому компилятор делает из неё async void. Start() не ждёт завершения работы, Main печатает финальную строку и выходит, а исключение из async void никто не наблюдает, и оно роняет процесс. Правильная реакция - переписать запуск на Task.Run либо на host с корректным ожиданием, и объяснить, что задача - это абстракция над планировщиком и пулом потоков, а Thread - реальный поток операционной системы.
Кандидат, который заучил разницу между Thread и Task, но не читал асинхронный код вживую, обычно проходит мимо async void и говорит про производительность создания потоков. Persona интервьюера здесь видит ровно то, что нужно: понимание модели исключений и времени жизни задачи.
Как генерировать такие задачи с помощью нейросетей
Подготовка заготовок упростилась. Автор поста советует отправить в GPT-6 Pro сам пост, описание вакансии и описание компании с просьбой сгенерировать портянку на часовое интервью. На выходе - связный код с несколькими типичными ошибками, который выглядит как настоящий кусок чужого сервиса, а не как учебная задача.
Ограничение простое: сгенерированный код нужно вычитать самому. Модель легко подсовывает спорную придирку или ошибку, которую нельзя однозначно назвать ошибкой без знания контекста, и тогда интервью превращается в угадайку. Приоритет проблем всё равно расставляет человек: для позиции в высоконагруженном сервисе важнее деградация словаря, для инфраструктурного кода - непойманное исключение. Какие ошибки считать критичными, зависит от команды, и это суждение модель не заменит.
Почему live-агент кандидата не всегда помогает
Логично предположить, что агент справится и с ревью: скормить код, получить список ошибок. На практике это работает хуже. Автор поста отмечает: агент часто хватается за первую найденную проблему и не вдаётся в контекст. В портянке на сотню строк проблем десяток, а интервьюер смотрит не на список как таковой, а на то, какие проблемы кандидат поставил первыми и как объяснил выбор.
Почему контекст важнее первой ошибки
В примере с Thread.Start и async void агент предложит заменить Thread на Task и остановится. Вопрос «почему это важно именно здесь» повисает: чтобы ответить, нужно знать, как приложение завершает работу, где перехватываются исключения и что произойдёт с фоновыми задачами при остановке сервиса. В любом ревью контекст сначала уточняют - рантайм, профиль нагрузки, критичность пути, кто вызывает код. Модель этого не делает, пока её прямо не попросят, а кандидат под давлением редко выстраивает правильную последовательность вопросов сам.
Отсюда практический вывод для интервьюера: задавать три-четыре уточняющих вопроса подряд и смотреть, держит ли кандидат линию. Агент в такой ситуации начинает противоречить себе, советуя сначала одно, потом другое. Человек либо признаёт незнание, либо строит аргумент - и второе как раз то, что стоит проверять. Как агенты ведут себя на реальном цикле разработки, где ускорение заметно, а где возникает иллюзия продуктивности, разобрано в отдельном материале про место агентов в цикле разработки.
Что придёт на смену: испытательный срок и агенты-помощники
Автор поста делает более радикальный вывод: лучшее «собеседование» - испытательный срок, причём не трёхмесячный. С агентами, которые берут на себя рутину, адекватность кандидата видно за одну-две недели. Живая работа даёт то, чего не даст ни один разговор: как человек ставит задачи, проверяет результат, реагирует на замечания в ревью и что делает, когда план разваливается.
Ограничение у этого подхода очевидное, и автор его называет: не каждого кандидата можно взять на платный испытательный срок. Это оставляет разговор и ревью кода как основной фильтр, а испытательный срок - как способ добрать уверенность там, где бюджет позволяет. Общий сдвиг при этом шире одной вакансии: ценность человека смещается к снижению неопределённости, к постановке задачи и проверке результата, о чём подробно говорится в разборе про то, как агенты меняют структуру ролей и управление компанией.
Второй сдвиг: персональный агент-помощник перестаёт считаться читерством. Практичнее проектировать интервью так, чтобы инструмент был встроен в процесс: дать кандидату доступ к модели и смотреть, какие вопросы он задаёт, как проверяет её ответ и где ловит ошибку. Тогда проверяется навык, который реально нужен в работе, а не способность обходиться без инструментов.
Вопрос к читателям: как изменилась механика собеседований в вашей компании за последний год? Спрашивают ли ещё про устройство хеш-таблицы и отличия Thread от Task, или перешли на разбор реальных задач и чужого кода?