Почему лайв-кодинг — плохой способ проверки знаний
Лайв-кодинг на собеседовании — это кот в мешке.
Проблема в том, что это во многом случайная проверка: кандидат, как правило, не готов к нему в момент интервью. Он может не выспаться, хотеть есть или в туалет, быть в стрессе от обстановки. Эти базовые физиологические и психологические состояния напрямую влияют на результат.
Сама синхронность формата — один час, наблюдатель, таймер — создаёт искусственно высокий стресс по сравнению с другими способами проверки знаний: тестовым заданием, code review, разбором прошлого опыта. Это стресс-тест, а не проверка компетенций.
Лайв-кодинг не отражает реальную работу инженера
Типичное лайв-кодинг задание — это низкоуровневая обработка данных: написать фильтр, агрегацию, сортировку вручную. Но на практике инженер этого не делает. Такая работа CPU-intensive и выполняется на уровне базы данных — через SQL, индексы, агрегации на стороне БД. Писать это руками в продакшне — антипаттерн.
Кандидат может просто не знать конкретный алгоритм или структуру данных, которую случайно выбрал интервьюер. Это не значит, что он плохой инженер — это значит, что задача выпала не из его зоны.
Провал лайв-кодинга закрывает все остальные двери
Лайв-кодинг, как правило, стоит в начале воронки. Если ты не прошёл — до system design, архитектурных вопросов, разбора опыта ты просто не доходишь.
Это особенно несправедливо для T-shaped инженеров, которые работают широко: базы данных, observability, API endpoints, рефакторинг, code review. Такой инженер может быть ценным специалистом, но его выкидывают за дверь после одного алгоритмического теста, который не имеет отношения к его реальной работе.
Узкий фильтр отсеивает широких специалистов.
Интервью как конвейер без единой картины
Интервью в большинстве компаний — это конвейер фильтрации, а не оценки. Каждый интервьюер отвечает за свой этап и смотрит только на свой кусок. HR видит только начало процесса. Тот, кто проводит лайв-кодинг, оценивает пятерых кандидатов относительно друг друга — не в абсолюте. Тот, кто делает system design, получает уже отфильтрованных двоих и сравнивает их между собой. Никто из них не видит процесс целиком и не может его улучшить.
В результате нет ни одного человека, который смотрит на найм как на единый процесс. Это как микросервисы с жёсткими границами контекста: каждый сервис обрабатывает свой запрос оптимально, но сквозная транзакция через всю систему — неэффективна и непрозрачна.
Следствие — никто не перенаправляет кандидата. Предположим, на позицию джуниора пришёл сильный миддл. Формально он проходит через все этапы найма на эту конкретную вакансию. Но поскольку никто не смотрит на картину целиком, никто не скажет: "Стоп, у нас открыта другая позиция — он подходит туда лучше." Процесс бюрократически продолжается по рельсам, даже если оптимальное решение лежит рядом.
Многоэтапный процесс — не когерентная оценка человека, а набор независимых срезов. Каждый этап специализирован, но вместе они не складываются в понимание того, кто этот инженер и как он работает в реальности.
Проблема окружения и ограниченного времени
Лайв-кодинг предполагает, что у тебя настроена среда: IDE, тестовый фреймворк, возможность запустить код и сразу увидеть результат. Если этого нет — ты в ловушке.
Без запущенных тестов ты не можешь показать, что код работает на всех кейсах. Запускать вручную через CLI — неудобно и не покрывает все ожидания. Значит, чтобы пройти лайв-кодинг, нужно заранее подготовить sandbox: настроить проект, подключить тест-фреймворк, знать как запустить всё в один клик.
Это дополнительная работа до интервью, которая не имеет отношения к инженерным компетенциям. Это подготовка к ритуалу, а не к работе.
Запрет на AI — это тест в вакууме
Большинство компаний запрещают использовать AI на лайв-кодинге. Логика понятна: если AI напишет весь код, интервьюер не увидит, как ты думаешь. Но эта логика игнорирует реальность профессии.
AI-ассистенты сейчас настолько вошли в рабочий процесс, что работать без них — это как пересесть с трактора на плуг и доказывать, что ты умеешь пахать поле руками. Умение работать с AI, делегировать задачи агентам, проверять и направлять генерируемый код — это и есть современная инженерная компетенция. Но её не проверяют.
Хуже того — запрет распространяется не только на генерацию решения целиком, но и на любую помощь: нельзя написать маленький кусок с подсказкой AI, нельзя уточнить синтаксис. Некоторые компании запрещают даже Google, хотя Google сам отвечает с AI-помощью. Это означает, что нельзя даже проверить документацию — например, какие методы есть у Array в JavaScript или как работает конкретная функция Map.
В итоге инженер оказывается в изоляции: нет документации, нет AI, нет коллег. Только задача и таймер.
Знание наизусть — не критерий профессионализма
Если Google и AI запрещены, возникает абсурдный вопрос: а можно ли распечатать RFC или спецификацию языка и положить рядом? Это не шутка — это логичное следствие формата, который требует знания синтаксиса наизусть.
Реальность такова: многие опытные инженеры работают на нескольких языках одновременно и используют их взаимозаменяемо. Но знать весь API наизусть — синтаксис switch, мьютексы, quicksort, бинарное дерево — не нужно, потому что в реальной работе это гуглится или генерируется AI за секунду. Редко используемые конструкции просто не держатся в голове, и это нормально.
Лайв-кодинг этого не учитывает. Итог: инженер, знающий пять языков, вынужден выбирать тот единственный, который знает лучше всего наизусть, — не потому что он на нём лучше решает задачи, а потому что только на нём он сможет написать что-то без документации. Широта экспертизы становится уязвимостью вместо преимущества.
Психологическая нечестность формата
Человек месяцами работает в нормальных условиях: с AI, с поиском, с коллегами, с возможностью подумать. И вдруг его ставят на олимпиаду и требуют показать результат чемпиона.
Это психологически нечестно. Ты не готовился к соревнованию — ты просто делал работу. А теперь от тебя требуют не показать, как ты работаешь, а доказать, что ты можешь выступить в совершенно другом формате, к которому нужно отдельно готовиться. Лайв-кодинг — это отдельный навык, который не коррелирует с качеством инженера.
Задачи оторваны от реального домена кандидата
Выбор задачи на лайв-кодинге никак не связан с тем, чем кандидат занимался последние годы. Backend-инженер из fintech получает задачу на графы. Специалист по distributed systems — сортировку массива. Человек, который строил высоконагруженные pipeline'ы — задачу на binary tree.
Никакой корреляции с реальным опытом. Задача случайна относительно кандидата, и это делает результат ещё более случайным.
Нет второй попытки
В реальной работе ты можешь отложить задачу, вернуться к ней завтра с fresh eyes, поспать и внезапно увидеть решение. Это нормальная часть инженерного процесса.
На лайв-кодинге этого нет. Один момент, один шанс. Если мозг не выдал решение именно сейчас — ты провалился, хотя завтра утром ты бы написал его за 10 минут.
Асимметрия: интервьюер уже знает ответ
Интервьюер смотрит на задачу, которую уже решил или знает наизусть. Это принципиально разные когнитивные состояния. Очень легко думать «ну это же очевидно» про решение, которое ты уже видел. Это создаёт ложное ощущение, что задача проста, и занижает эмпатию к кандидату, который решает её впервые под давлением.
Soft skills не проверяются вообще
Лайв-кодинг не проверяет то, что на практике важнее алгоритмов для большинства ролей:
- умение объяснить решение коллегам
- качество code review
- написание понятных PR-описаний
- работа в команде под неопределённостью
- принятие архитектурных решений с компромиссами
Всё это остаётся за кадром, если кандидат не прошёл через сортировку за 45 минут.
Домашние задания: хорошая идея, убитая AI
Раньше альтернативой лайв-кодингу были домашние задания. Это был честный формат: кандидату давали реалистичную задачу — поднять микросервис с базой данных, реализовать стриминг данных, сделать что-то асинхронным, обработать огромный файл при ограниченной памяти. Задача проверяла не синтаксис наизусть, а то, как человек думает, исследует, принимает решения.
Минус был один — время. Я помню, как потратил пять дней на домашнее задание для Pipedrive: нужно было разобраться с multiprocessing в PHP, чего я раньше не делал. Это реальные инвестиции, и многие инженеры (особенно уже работающие) не готовы тратить столько времени на каждую компанию.
Теперь эту проблему убил AI с другой стороны: домашнее задание любой сложности решается агентом за час. Компания не может понять, что написал кандидат сам, а что сгенерировано. Поэтому домашние задания почти исчезли из процесса найма.
Это тупик: лайв-кодинг — стрессовый и нечестный, домашние задания — дорогие по времени и уязвимые к AI. Индустрия пока не придумала, что делать вместо этого.
Survivor bias и иллюзия работающего процесса
Компании, использующие лайв-кодинг, уверены, что он работает — потому что нанятые через него люди справляются с работой. Но это классический survivor bias: они не видят тех сильных инженеров, которых отсеяли.
На самом деле лайв-кодинг — это игра звёзд. Кандидат проходит, когда одновременно совпадает всё:
- он выспался и поел
- у него не было стрессов в этот день
- задача попала в его домен — или он случайно решал похожую на прошлом интервью
- синтаксис нужных функций оказался в голове именно сейчас
Когда всё это совпадает, интервьюер думает: «Wow, как быстро, какой умный». Но это не сигнал компетентности — это удача. Вместо системной оценки компания делает выборку и принимает её за фильтрацию.
Что делать вместо этого
Нет одного идеального метода. Лучше думать о комбинации, где каждый этап дешёвый по времени и проверяет конкретную компетенцию — ту, которую человек будет применять на работе.
Code review чужого кода
Дать кандидату реальный PR с намеренными проблемами: баг, неудачная абстракция, проблема с производительностью, отсутствие обработки ошибок. Попросить прокомментировать письменно или вслух.
Это проверяет сразу много: как человек читает незнакомый код, что замечает первым, как формулирует фидбек. Видно, обращает ли он внимание на именование, на организацию кода, на количество слоёв абстракции. Знает ли паттерны — и не злоупотребляет ли ими. Это то, что инженер делает каждый день. И AI здесь почти не помогает: нужно понять чужой код, а не написать свой.
Разбор реального опыта с погружением
Не "расскажи о себе", а "возьми любой проект, который ты делал — объясни архитектуру, какие компромиссы принял и почему". Если кандидат ведёт open source — ещё лучше: можно открыть его реальный код и спросить про конкретные решения.
Ограничение времени здесь реально есть, но даже 15 минут хорошего погружения в чужой проект дают больше, чем час алгоритмов. Подделать сложно: если человек сам не писал — это видно через 2-3 уточняющих вопроса.
System design — как выбор инструмента, а не проектирование хайлоада
Классический system design ("спроектируй Twitter") — это отдельный жанр, который тоже зубрят. Интереснее другое: прагматичный выбор инструмента под конкретную задачу.
"Тебе нужен форум для пользователей продукта — как ты будешь выбирать движок? Напишешь сам или возьмёшь готовое? Почему?" Или: "Нужно логировать события — какую библиотеку возьмёшь, какой сервер, почему именно это?" Это проверяет архитектурное мышление в реальном масштабе, а не умение нарисовать диаграмму распределённой системы на миллион пользователей.
Теория как карта знаний, а не экзамен
Теоретические вопросы полезны — но не как проверка энциклопедии, а как способ понять распределение знаний человека. Что он знает глубже, что поверхностно, где у него слепые пятна.
Стоит прямо спрашивать: какие языки предпочитаешь и почему? Какие базы данных использовал — и чем они отличались на практике? Что тебе нравится в текущем стеке, а что раздражает? Компании часто молча предполагают, что кандидат выбирает их за стек — но на самом деле человек мог работать с более эффективным языком или более специализированной БД, и вы просто не знаете, насколько он хорош.
Парное программирование с разделённым незнанием
Самый честный формат из всех: кандидат и интервьюер берут задачу, которую оба не знают заранее. Это может быть задача из open source проекта, небольшой баг, или даже leetcode-задача — но с условием, что интервьюер её тоже видит впервые.
Тогда исчезает асимметрия знания. Это уже не экзамен, а совместная работа. Можно использовать Google, AI, документацию. Наблюдать интересно именно за процессом: как человек декомпозирует задачу, как общается, как реагирует на тупик, как использует инструменты. Это и есть реальная инженерная работа.