Использовать ли лайфкодинг на собеседовании?

Что проверяют

Вопрос задают в двух вариантах: как вы относитесь к лайвкодингу в роли кандидата и стали бы вы его использовать, собеседуя других. В обоих случаях проверяют, понимаете ли вы, что должен измерять формат, и не отвечаете ли обидой на прошлые собеседования. Следом могут дать короткую задачу прямо сейчас.

Как отвечать

Сформулируйте позицию с условием, а не голое «да» или «нет»:

• когда лайвкодинг полезен: задача близка к работе фронтендера. Написать debounce или свой Promise.all, собрать список с поиском и загрузкой, найти в React-компоненте лишние ререндеры или гонку запросов в useEffect. Так видно, как человек думает, уточняет требования, пишет читаемо и проверяет крайние случаи;
• когда вреден: алгоритмические головоломки, не связанные с продуктом, запрет на документацию, молчащий интервьюер. Это проверяет натренированность и стрессоустойчивость, а не работу;
• чем дополнить: разбор заранее подготовленного пулл-реквеста, обсуждение архитектуры фронтенда (состояние, кэш серверных данных, деление на компоненты), небольшое тестовое с защитой.

Если вы в роли интервьюера, опишите формат: от 30 до 40 минут, задача с постепенным усложнением, документацию открывать можно, оценивается ход решения, а не только итог.

Если вы кандидат, покажите, как держитесь на лайвкодинге: проговариваете план вслух, уточняете требования, сначала пишете простое рабочее решение и только потом улучшаете. Если в каком-то формате раскрываетесь хуже, скажите об этом спокойно и предложите альтернативу, например разбор своего кода на GitHub.

Где спотыкаются

Отвечают категорично: «лайвкодинг бесполезен, в работе есть Google». Звучит как отказ от проверки, лучше предложить формат, который вы считаете честным.

Жалуются на прошлые собеседования. Интервьюер слышит претензию, а не мнение о методе.

В роли интервьюера предлагают задачи на графы и динамическое программирование для разработчика интерфейсов. Это показывает, что вы не связываете проверку с реальными задачами роли.