Привет! На связи Дима — Senior Frontend разработчик в Doubletapp. В этой статье я расскажу, как эффективно собесить фронтендеров. Мой стек — Vue, Nuxt, поэтому примеры будут на основе моего опыта, но текст подойдет для всех разработчиков и нанимающих менеджеров.
В этой статье
Много лет я работаю с разными форматами команд, включая аутстаф. Я провел и прошел более 80 технических собеседований. Эта практика показала, как сильно эволюционировали задачи разработчиков — и как медленно меняются подходы к их найму.
К 2026 году индустрия сильно изменилась. Инструменты стали мощнее, ИИ взял на себя рутину и написание шаблонного кода, а сложность систем выросла. Однако методы найма во многих компаниях остались прежними. Мы всё еще заставляем кандидатов проходить экзамен по билетам, проверяя их память, а не инженерные навыки и способность приносить пользу бизнесу.
Что я понял спустя 80+ собеседований?
Итог прост: нынешний формат технических интервью плохо предсказывает реальную эффективность сотрудника.
Мои выводы основаны на опыте участия в процессе с обеих сторон:
С позиции нанимающего (30+ интервью): я встречал кандидатов, которые безупречно отвечали на вопросы про контекст исполнения и прототипы, но не могли спроектировать архитектуру простого виджета. На выходе получались перегруженные God-компоненты, мутации props и непонимание реальных практических кейсов жизненного цикла компонентов Vue. Инженерная база у таких специалистов часто оказывалась близка к нулю при отличной теоретической подготовке, хотя списывать с GPT тогда еще не было особо популярно.
С позиции кандидата (50+ интервью): часто интервью напоминает экзамен по билетам в институте. Разработчику не только достаются рандомные билеты, так еще и приходится решать задачи, которых не существует в его рабочей реальности. Например, написание своей реализации eventListener-ов при найме на разработку интерфейсов для e-commerce, когда мы уже с Dom-ом напрямую особо не работаем. Это превращается в проверку на стрессоустойчивость, а не в оценку профессионализма.
Как собесят на рынке?
Сегодня рынок четко разделился на три сегмента, и во всех есть системные проблемы с оценкой кадров.
BigTech: крупные компании продолжают использовать формат MAANG с упором на алгоритмы и Live Coding на пустом листе. Безусловно, алгоритмы — это база, но часто после сложнейшего отбора разработчик попадает на проект, где его задачи сводятся к верстке стандартных форм. В итоге специфические знания, которые проверялись на входе, никак не используются в работе.
Средние компании: такие компании часто копируют эти практики без понимания контекста. Собеседование превращается либо в попытку решить оторванную от реальности задачу, либо в теоретический допрос по спецификации языка, которую кроме Мурыча (As For JS на YouTube) особо никто не читал.
Маленькие студии: собеседования вообще для галочки, и зачастую вопросы с первой страницы гугла.
Почему это все не работает
Я выделяю три основные проблемы текущих интервью:
Теоретические викторины: вопросы в духе «что вернет [] + {}» или детальный разбор Event Loop на уровне спецификации проверяют только память. В 2026 году большинство пограничных случаев закрываются фреймворками, линтерами и строгой типизацией. Мы проверяем эрудицию, хотя бизнесу нужен навык разработки.
Задачи на «велосипеды»: требование написать с нуля DeepClone или полифил для Promise.all не имеет смысла, когда под рукой есть оптимизированные нативные методы и библиотеки. Умение воспроизвести по памяти стандартный метод никак не гарантирует, что человек сможет спроектировать архитектуру приложения или грамотно декомпозировать сложную фичу.
Читерство: из-за таких рандомных и оторванных от реальности собеседований кандидатам ничего не остается, как использовать ИИ для прохождения собеседований.
Об этом поговорим поподробнее.
Фактор ИИ и «подготовленных» кандидатов
Сегодня прохождение стандартных интервью стало отдельным навыком, который действующим разработчикам просто некогда качать. Существует множество списков «Топ-100 вопросов», а использование GPT позволяет кандидатам давать правильные ответы, не обладая реальным опытом. Проблема таких списков в том, что они общедоступны и предсказуемы.
Если мы хотим нанять того, кто умеет работать, а не просто проходить интервью, задачи должны быть объемными, подготовленными и проверять мышление инженера. Только в живом обсуждении можно понять, насколько глубоко человек понимает процессы, а не просто воспроизводит заученный или сгенеренный текст.
Как проводить инженерное интервью: 4 принципа
Я считаю, что фокус должен сместиться на проверку мышления.
Быстрый фильтр на кругозор: вместо пытки теорией — короткий блиц. Понимает ли человек разницу между SSR и SPA? Знает ли о существовании Web Workers? Детали можно загуглить, важно понимание концепций и умение выбрать правильный инструмент.
Рефакторинг вместо написания с нуля: дайте кандидату работающий, но некачественный код (например, на старом Options API или с ошибками в реактивности). То, как человек читает и исправляет чужой код, говорит о его уровне гораздо больше, чем написание функции с чистого листа.
Реальная среда разработки: оценивайте кандидата в IDE или CodeSandbox. Не нужно тратить время на проверку того, помнит ли он синтаксис без подсказок. Важна логика, работа с асинхронностью и структура данных.
Проектирование систем (System Design UI): обсудите архитектуру реальной фичи. Например, реализацию бесконечной ленты с кешированием. Здесь важно услышать аргументацию: почему выбирается тот или иной стейт-менеджмент, как обрабатываются ошибки и как решение масштабируется.
Заключение
В эпоху развития ИИ ценность разработчика смещается от знания синтаксиса к умению проектировать решения. Для компаний это повод пересмотреть свои стандарты и начать искать инженеров, способных мыслить структурно. Такой подход (рефакторинг + проектирование + живое обсуждение) дает гораздо более точную оценку того, как человек будет работать с вашим кодом завтра.
Какие тестовые задания давать, чтобы проверить инженерное мышление, а не память и умение пользоваться ChatGPT, я расскажу в следующей статье.
Подписывайтесь на блог Doubletapp на Хабр!
