
Действительно ли лайвкодинг показывает уровень разработчика?
Представьте: вы провели с кандидатом три собеседования, он убедительно рассуждал об архитектуре и имел сильное резюме. Но в работе над проектом выяснилось, что он не может решить даже элементарную задачу. Страх этой ошибки и делает live coding таким привлекательным — здесь человек пишет код прямо перед вами, почти без шансов подменить себя кем-то другим.
Но чем ближе к практике, тем больше проблем: live coding часто не только не раскрывает целый пласт навыков, на которых держится реальная работа, но еще и вызывает стресс даже у сильных инженеров. Поэтому формат, который должен был снизить риск ошибки, сам становится ее источником.
Далее мы разберем, что такое лайвкодинг на самом деле, в чем его риски и как организовать такое собеседование с минимальным стрессом для всех сторон.
Что такое live coding и зачем компании его используют
Live coding interview — это формат, при котором кандидат решает задачу с кодом прямо во время разговора с интервьюером, а не самостоятельно дома. Он шерит экран, пишет решение в реальном времени, пока представители работодателя следят за ходом его рассуждений. После этого все вместе обсуждают результат. Лайвкодинг может быть как отдельным этапом, так и частью технического интервью, которая объединяется с Q&A.
За полчаса лайвкодинга заметно то, чего нет в резюме:
- Как кандидат разбивает задачу на части — сразу ли берется писать код или сначала задает уточняющие вопросы и проговаривает план работы.
- Что он делает, когда застревает — как ищет ошибку, способен ли вернуться к предыдущему шагу и попробовать другой подход, принимает ли подсказки.
- Может ли объяснять свои решения вслух — поймет ли коллега ход его мыслей, когда они будут работать вместе.
- Как кандидат реагирует на изменение требований, если интервьюер на ходу добавляет новое условие — быстро адаптируется или теряется.
При этом live coding — не унифицированный формат. То, как он проходит, зависит от политики конкретной компании, а подходы могут существенно отличаться.
Проще всего систематизировать различия по двум осям:
- Что разрешено кандидату. Спектр от строгого «только пустой редактор» до полной свободы. На одном полюсе запрещено все: ни гугла, ни документации. Посередине — можно гуглить и заглядывать в документацию, как в привычной работе. На другом полюсе разрешено почти все, в том числе использовать ИИ-ассистент, ведь здесь оценивают уже то, как кандидат пользуется инструментами.
- Насколько вмешивается интервьюер. Это может быть коллаборация — интервьюер рядом как напарник: подсказывает, направляет, вместе с кандидатом ищет решение. Но может быть и молчаливый надзор — интервьюер наблюдает, а кандидат самостоятельно преодолевает все трудности.
Эти оси не связаны между собой, поэтому на практике встречаются любые комбинации — от дружеской парной сессии с Google под рукой до экзамена с пустым редактором под пристальным взглядом интервьюера.
Зачем компаниям вообще нужен этот формат? Начнем с рациональных причин:
- Проверить реальный скилл. Ни резюме, ни портфолио не показывают практических навыков напрямую: в резюме — только перечень опыта без доказательства, что человек действительно владеет указанными навыками, а по работам в портфолио часто не понять, какую часть проекта сделал кандидат, а какую — команда. Тестовое задание в IT тоже нередко генерируется или отдается на выполнение более опытному специалисту. А вот «живой» код сразу показывает, подтверждается ли реальными умениями то, о чем кандидат рассказывал на собеседовании.
- Быстро оценить навыки. Вместо недели ожидания тестового и отдельных часов на его проверку — одна сессия, во время которой вы видите результат и обсуждаете его сразу.
- Пообщаться вживую. Здесь виден не только код, но и человек: как он задает вопросы, реагирует на критику и объясняет свою логику.

«В последние годы компании все чаще выбирают лайвкодинг, а не тестовые. Сейчас ТЗ можно просто отдать ChatGPT или другим агентам, поэтому оно перестает показывать результат. Лайвкодинг ценен именно тем, что ты видишь, как человек пишет самостоятельно.
Обычно когда кандидат просит отменить тестовое или лайвкодинг, сразу включаются сомнения — почему не хочет, почему ставит условия? Под вопрос попадают уже и его soft skills. Аргумент “у меня большой репозиторий” срабатывает, только если там есть проект, похожий на то, что делает компания. Но были кейсы, когда hiring-менеджер сам мог сказать “человек крутой, обойдемся без тестового, пообщаемся об опыте”».

«Live coding начал набирать обороты еще года три назад — прежде всего чтобы не тратить время кандидата, ускорить hiring-процесс и не обижать сеньоров тестовыми заданиями. Я лично поддерживаю лайвкодинг, особенно во времена AI, потому что, на мой взгляд, это не только про “напиши нам код, а мы оценим”, а часто способ проверить взаимодействие и то, как человек будет работать с реальными задачами. До оффера важно узнать, как человек держится под давлением и в сжатые дедлайны, как общается, воспринимает ли фидбек. Из-за AI-ассистентов домашние тестовые задания теряют актуальность, поэтому, по моему опыту, лайвкодинг выбирают все чаще.
Большое преимущество лайвкодинга — скорость для обеих сторон: кандидат сразу видит, комфортно ли ему с hiring-менеджером, выполнение не занимает много времени, а менеджер в процессе дает подсказки и комментарии. Именно о таком формате я получала много положительных отзывов».
Но точно так же за этим могут стоять менее объективные причины:
- «Так сложнее обмануть». Тестовое можно списать, а на live coding online человек сам перед камерой — формат кажется надежнее. Спойлер: уже не совсем так из-за AI-ассистентов и фейковых кандидатов, которые используют технологии замены лица.
- «Потому что так делают в Google». Часть практик внедряется в компаниях просто по инерции, ведь у топов это работает. Но то, что подходит корпорации с тысячами откликов на вакансию, не всегда имеет смысл для команды из пяти человек.
- «Мы так привыкли». Иногда формат живет просто потому, что так заведено. Его никто не пересматривал годами, а зачем он и что именно проверяет — объяснить уже никто не может.
Главные риски лайвкодинга
Несмотря на удобство формата, плохо организованный лайвкодинг создает риски, где одна часть портит качество самой оценки, а другая — вредит впечатлению кандидата о компании.
Стресс вместо демонстрации навыков
Писать код под наблюдением — отдельный скилл, поэтому лайвкодинг часто фильтрует кандидатов по стрессоустойчивости, а не по компетентности. Это подтверждает и опрос interviewing.io: часть инженеров легко выполняет тестовые, но проваливает живые собеседования именно из-за волнения.
Алгоритмические задачи не соответствуют реальным
Разработчики годами жалуются, что задачи на лайвкодинге с LeetCode далеки от практической работы. Одна из главных причин — условие в задании четкое и исчерпывающее. В настоящей таске половина дела — понять, что вообще надо сделать из размытой формулировки в тикете.
К тому же в реальной работе редко нужен новый алгоритм — чаще всего он уже есть в библиотеке, а время уходит на чтение чужого кода, интеграцию новых компонентов и баги. Отсюда обратная зависимость с уровнем: такие задачи часто лучше отрабатывают джуны, которые недавно их практиковали, а опытный инженер может провалиться.
Потеря сильных кандидатов из-за долгого отбора
Длительный процесс рекрутинга с лайвкодингом не отпугивает, если компания смогла замотивировать кандидата: узнаваемый бренд, прозрачные этапы, качественная коммуникация, конкурентное предложение. Но решающим может стать сравнение с другими работодателями: если две компании со схожей репутацией процессят одного кандидата, одна дает офер за неделю, а вторая за три — чаще всего выигрывает более быстрая.
Поэтому еще до того, как нанять Senior-специалиста, стоит честно оценить свои шансы: когда к долгому процессу добавляется слабый бренд, поиск специалиста может затянуться.
«Для сеньоров решающая прежде всего репутация компании: если это продуктовый бигтех, кандидат спокойно пройдет и несколько этапов, включая лайвкодинг — потому что ему важно, в какой компании работать, и престижно добавить ее в резюме. А офер от неизвестного работодателя с посредственным предложением для сильного специалиста обычно не приоритет, даже если его сделали быстрее».
Виктория Иванова, Venture Talent Acquisition SpecialistСкрытое использование AI
Ассистенты вроде Cluely и Interview Coder работают как невидимый слой поверх экрана и не попадают в демонстрацию, поэтому стандартный live coding их не обнаружит. Исследования показывают, что 48% кандидатов на технических ролях несанкционированно используют AI.
Также лайвкодинг почти не показывает ряд компетенций, необходимых для работы в коммерческой разработке:
- Доменные знания. Одна и та же задача имеет разные «правильные» решения в зависимости от сферы: например, в кибербезопасности проверку пароля надо защитить от атаки по времени ответа, а в ритейле — решить, как считать остаток под флеш распродажи, где есть только бизнес-компромисс. Формат проверяет, умеет ли кандидат писать код, тогда как настоящая ценность в том, понимает ли разработчик, что именно и зачем нужно реализовать для этого бизнеса.
- Чтение чужого кода и дебаг легаси. Формат не показывает, насколько хорошо человек разберется в чужом коде пятилетней давности без тестов.
- Долгосрочное командное взаимодействие. Во время лайвкодинга вы не сможете оценить скиллы код-ревью, менторства, командной работы и сотрудничества с несколькими стейкхолдерами.
Чек-лист: когда live coding уместен
Ситуации, когда лайвкодинг — это мэтч с вашими потребностями или необходимое дополнение к техническому интервью:
- У кандидата нет релевантных проектов в портфолио. Специалист вырос до Senior на предыдущей позиции, но работал в другом домене — например, переходит из Retail в FinTech.
- Нужна быстрая адаптация к незнакомому коду или стеку. Если роль предполагает работу с несколькими проектами, где постоянно придется погружаться в чужую документацию, кодовую базу и легаси, лайвкодинг может показать эти навыки лучше, чем тестовое задание, которое кандидат выполняет несколько дней.
- Роли, где есть кодинг под давлением в реальном времени — например, SRE/DevOps, инженеры на ночном дежурстве.
- Когда это удобно самому кандидату. Объем тестового задания даже при соблюдении «хорошего тона» может достигать 3–4 часов, которые есть не у всех. Live coding экономит вечера неоплаченной работы над большим тестовым и предполагает быстрый фидбек вместо недели ожидания.
«Лайвкодинг можно проводить на любом уровне, но его наполнение должно быть разным в соответствии с грейдами. Джунам часто дают алгоритмические задачки, ведь им нужно показать базовые навыки программирования. Мидлам и сеньорам — рефакторинг: задания на исправление некачественного кода, где кандидат видит места для улучшения. А для лида или архитектора лучше проводить архитектурную сессию: спроектировать систему или построить диаграмму модулей. Давать архитектору алгоритмическую задачку — нонсенс.
Тренд в лайвкодинг-практиках сейчас — рефакторинг и code review вместо задач на алгоритмы. Задания формата переписать готовое или поискать ошибки позволяют сконцентрироваться на самом интересном и вместить как можно больше кейсов в одну сессию. В эпоху агентного программирования умение просмотреть сгенерированный код и увидеть слабые места — более актуальный навык, чем написание с нуля».
Николай Клестов, CTO в ITExpertКогда же от лайвкодинга лучше отказаться?
- Дефицитные кандидаты, которых отпугивает этот формат. Если у человека несколько оферов, лишний этап просто подтолкнет его выйти из процесса.
- Сильный репозиторий или open-source. Когда можно посмотреть готовые проекты, искусственная задача под наблюдением ничего не добавляет. В открытом коммерческом коде или опенсорсе видны архитектурные решения, стиль и культура код-ревью. Главное — убедиться, что код действительно принадлежит кандидату: пройтись по истории коммитов и задать несколько вопросов о принятых решениях.
- Роль касается архитектуры и/или легаси. Лайвкодинг почти не измеряет эти компетенции, поэтому здесь может дать false positive результат: кандидат отлично справится с алгоритмическими задачами, но будет теряться в работе.
- Слабый бренд работодателя. От Big Tech естественно ожидают лайвкодинга, поэтому кандидаты любого грейда готовы пройти несколько дополнительных этапов. Стартапу тот же формат стоит дороже: разработчик с несколькими офферами скорее откажется, чем потратит час на стресс-тест ради малоизвестной компании.
«Мой главный критерий в пользу того, рекомендовать лайвкодинг в процесс или нет — техническая экспертиза hiring-менеджера. Здесь важны две вещи:
- В команде этот специалист должен быть доступен фултайм, чтобы не затягивать найм.
- Его грейд должен быть не ниже грейда кандидата.
Сеньор еще может проводить лайвкодинг сеньору, но лучше, когда это лид, хед или CTO — тогда у кандидата есть доверие к экспертизе.
А вот когда сеньора оценивает мидл, это не работает: у меня были кейсы, когда из-за этого кандидаты отказывались от дальнейших этапов и даже от оффера. Потому что “как компания может доверить оценивать меня человеку ниже по грейду?” Поэтому если в команде нет кого-то технически сильного и доступного, чтобы качественно провести лайвкодинг, для hiring-процесса я скорее предлагаю тестовое».
Виктория Иванова, Venture Talent Acquisition SpecialistКакие методы оценки кандидатов можно выбрать вместо лайвкодинга?
- Оценка портфолио или опенсорса. Код должен быть доступен для просмотра, а его авторство — подтверждено. Короткий разговор быстро показывает, действительно ли кандидат написал этот код самостоятельно.
- Разбор кейса или системный дизайн. Диалог вроде «расскажите, как бы вы спроектировали архитектуру под такой продукт» позволяет оценить зрелость суждений и бизнес-мышление — то, чего live coding не показывает.
- Парное программирование. Тот же код в реальном времени, но интервьюер — напарник, а не судья, что ближе к настоящему сотрудничеству и менее стрессово.
- Тестовое задание. Реалистичное, с адекватным лимитом времени и оплаченное, если занимает больше четырех часов.
- «Обратное» задание. Предложите кандидату проанализировать ваш код, провести его ревью или найти и исправить ошибки. Такой формат оценивает как раз те навыки, которые обычный лайвкодинг почти не охватывает, и лучше воспроизводит повседневные рабочие задачи.
Как провести лайвкодинг комфортно для всех сторон?
Если вы выбрали формат лайвкодинга, проверьте, насколько он приближен к честной проверке, а не к лишнему стрессу.
Давайте реальную задачу, а не головоломку
Задание должно быть похоже на то, чем человек будет заниматься на работе, а не на головоломку с подвохом, где надо вспомнить один конкретный трюк. Реалистичная задача показывает реальные навыки, а трюковая — только то, решал ли кандидат что-то подобное раньше.
Не пытайтесь «подловить» кандидата
Лайвкодинг — это попытка увидеть, как кандидат работает, поэтому и относиться к нему стоит как к будущему коллеге, а не как к экзаменуемому. Каверзные вопросы «на засыпку», молчаливое ожидание, пока человек сам попадет в ловушку, демонстративное исправление каждой мелочи — все это добавляет стресса и ничего не говорит о hard skills. Коллаборативный формат, где интервьюер направляет и подсказывает, обеспечивает более объективный результат, чем пассивное наблюдение.
Дайте доступ к инструментам — и определитесь насчет AI
Документация, поисковая система, привычная IDE — это не «подсказки», а нормальные условия работы. Запрещать их означает тестировать искусственную ситуацию. Заранее определите политику относительно AI и проговорите ее с кандидатом — неопределенность здесь вредит обеим сторонам. Например, вы можете разрешить AI для рутинной задачи — в частности, сгенерировать форму, чтобы быстрее перейти к сложной части, — но запретить LLM для написания кода от начала и до конца.
Обозначьте правила
Формат, язык, примерный тип задачи и то, что именно вы оцениваете, стоит сообщить до собеседования. Это выровняет условия для всех, ведь вы проверяете навык, а не умение импровизировать.
Так же стандартизируйте оценивание заранее: четкие критерии и признаки качественного результата. Иначе фидбек превращается в «понравился / не понравился».
Оценивайте процесс, а не только финальный ответ
Часто ход рассуждений важнее того, дошел ли кандидат до финальной версии кода за отведенное время. Давайте баллы за рассуждения, декомпозицию и подход к дебагу — именно это помогает спрогнозировать, как специалист будет действовать на проекте.
Найдите баланс между глубиной и количеством этапов
С одной стороны, не пытайтесь за одну сессию оценить и практические навыки, и знание архитектуры, и коммуникацию, и стрессоустойчивость. Разделите критерии на разные этапы рекрутинга, а здесь сосредоточьтесь на чем-то одном. С другой — так же не растягивайте процесс найма искусственно.
«И еще: лайвкодинг должен дополнять этапы, а не множить их. Если у вас уже есть объемное тестовое на старте, после него — длительный лайвкодинг, а потом еще три собеседования, процесс превращается в хаос и изматывает и кандидата, и менеджера».
Виктория Иванова, Venture Talent Acquisition SpecialistИ все же: live coding — это проверка хард скиллов или стрессоустойчивости? Честный ответ: и то, и другое, в зависимости от того, кого и как вы им оцениваете. Поэтому главный вопрос — не «использовать или нет», а «что именно вы хотите измерить и поможет ли этот формат». Лайвкодинг работает только при определенных условиях: под конкретные роли и задачи, а не как универсальный фильтр. Поэтому не стоит держаться за метод, который не работает для вашего кейса — лучше адаптировать его под конкретную роль или команду либо заменить другим.
Насколько полезной была эта статья?
Click on a star to rate it!
Средняя оценка 5 / 5. Количество голосов: 1
Оценок пока нет! Будьте первым, кто оценит этот пост.


