Привет, я Дима, senior frontend разработчик в компании Doubletapp. 

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

В тексте: 

• Почему стандартные тестовые задания не работают

• Как должен выглядеть адекватный технический этап

• Почему этот подход даёт лучший результат

Обо мне: я прошёл более 50 собеседований и провёл больше 30 интервью со стороны нанимающего. В Doubletapp работал в продуктовых командах и как аутстаффер над крупными проектами (как минимум один вы знаете, в их магазины за продуктами вы ходите:D). Этот опыт позволил мне посмотреть на найм с двух сторон и прийти к довольно неприятному выводу.

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

Я буду рассуждать со своей колокольни фронтенд-разработчика. Разработчик, уверенно отвечающий на любой из сотни вопросов по JavaScript, Vue, TS (cюда любую технологию можете подставить) — это всего лишь человек с хорошей памятью. Сегодня, когда ИИ закрывает большую часть шаблонных задач, ценность такого навыка стремительно падает. Именно поэтому я считаю, что тестовые задания и технические этапы нужно пересматривать.

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

Почему стандартные тестовые задания не работают

Большинство тестовых заданий страдают одними и теми же проблемами.

Во-первых, они проверяют выносливость, а не инженерные навыки. Формат «сделать мини-приложение за выходные» отсекает сильных специалистов, которые ценят своё время, но отлично справляются с реальной работой.

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

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

Как должен выглядеть адекватный технический этап

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

Этап 1. Короткое тестовое задание до технического собеседования

Перед техническим собеседованием кандидату предлагается выполнить небольшое тестовое задание, рассчитанное на 1,5–2 часа.

Пример задания:

• простой компонент, например список товаров;

• поиск по данным;

• одна страница;

• стор для хранения данных.

Важно! Ключевое требование формулируется жёстко и явно: сделать строго по ТЗ, без дополнительных улучшений и «идей от себя». Это обязательно указывается в условиях.

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

А что если кандидат все напишет через AI-agent-ы?  Не беда, нам важнее, что человек сделал тестовое адекватно, понимает, что он сделал, а не какими инструментами он пользовался. Для этого как раз есть следующий этап.

Этап 2. Совместное ревью на техническом собеседовании

На техническом собеседовании мы вместе с кандидатом разбираем выполненное тестовое задание.

Кандидат:

• объясняет архитектурные решения;

• аргументирует выбор инструментов;

• отвечает на вопросы по своему же коду.

После этого мы просим дописать небольшое расширение поверх существующей реализации — например, сортировку или пагинацию.

Важно, что мы не просим переписывать всё с нуля. Нас интересует, как человек работает с уже существующим кодом, как аккуратно встраивает новую логику и не ломает текущую функциональность. Опять же, какими инструментами — это неважно, смотрим на то, как рассуждает, как проектирует или пишет промпт AI-агенту. (Разве это как раз не проектирование? Давайте похоливарим в комментах).

Этап 3. Рефакторинг реального легаси-кода

После обсуждения тестового должно оставаться минут 20-30, и кандидату даётся реальный компонент с плохим кодом:

• перегруженный god-component;

• дубли логики;

• ошибки в реактивности;

• неочевидные баги.

Задача — в реальном времени посмотреть код, найти проблемы и начать их исправлять. Мы не требуем идеального рефакторинга. Кандидат исправляет только то, что успевает, а мы смотрим на ход его мыслей.

Здесь я считаю важным не количество строк кода, а:

• какие проблемы человек видит в первую очередь;

• как расставляет приоритеты;

• умеет ли объяснить, почему это проблема;

• задаёт ли уточняющие вопросы.

Почему этот подход даёт лучший результат

Даже если кандидат:

• использовал нейросеть при выполнении тестового;

• не работал в известных компаниях;

• не идеально выглядит по резюме,

но при этом:

• хорошо ориентируется в коде;

• уверенно проходит совместное ревью;

• адекватно мыслит при работе с реальным легаси…

Такой человек реально готов к работе!

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

Выводы

В эпоху ИИ ценность фронтенд-разработчика смещается от знания синтаксиса к умению проектировать решения, читать и улучшать код, работать с ограничениями и требованиями бизнеса.

Компании, которые хотят нанимать сильных инженеров, обязаны пересмотреть свои тестовые задания и технические этапы с 2015 года. Формат «короткое тестовое + совместное ревью + реальный рефакторинг» даёт намного более точный прогноз того, как человек будет работать с вашим кодом завтра! 

Чтобы понять, почему именно такой формат работает лучше, загляните в предыдущую статью — там я разобрал ключевые принципы методологии.
Приглашаю к обсуждению в комментариях.