Проектирование теста по программированию для фронтенд-разработчика, который отражает реальную работу
Что действительно требуют фронтенд-позиции
Большинство фронтенд-работы — это не алгоритмы. Это:
- Чтение незнакомого дерева компонентов и поиск того, где находится состояние
- Подключение API ответа в UI без нарушения граничных случаев (загрузка, ошибка, пусто)
- Написание CSS, который работает при длинном контенте, не предусмотренном дизайнером
- Определение причины проблем с производительностью (если виновата re-render)
- Знание, когда добавить зависимость в deps, а когда это не нужно
Вопрос о разворачивании двоичного дерева в стиле LeetCode не тестирует ничего из этого. Более того, он отсеивает отличных кандидатов, которые хороши в реальной работе, но не интересуются алгоритмическими головоломками.
90-минутный тест, который измеряет настоящее
Дайте кандидату маленькое сломанное React приложение с тремя ошибками:
- Тонкая ошибка. Список пересчитывает все строки при одном изменении, потому что key — это индекс массива. Список лагает при >100 элементов, но не выглядит явно сломанным.
- Незавершённая функция. Форма отправляется, но не обрабатывает состояния загрузки и ошибки.
- Проблема со стилями. Макет карточки ломается, когда заголовок длиннее 40 символов.
Попросите исправить все три. Предоставьте работающее приложение, кодовую базу и свободу добавлять библиотеки (или нет).
Это измеряет реальный навык: чтение незнакомого кода, распознавание паттернов, суждение о том, когда добавлять зависимости, вкус в CSS, полнота обработки граничных случаев.
Рубрика
Оценьте четыре измерения, 1–4 каждый, с якорями:
- Диагностика ошибок. Выявили ли они причину до исправления? Или залатали симптом?
- Полнота граничных случаев. Загрузка, ошибка, пусто — покрыли ли все без подсказок?
- Качество кода. Именование, структура, выбор зависимостей.
- Коммуникация. Оставили ли комментарии или заметку о компромиссах?
Старшие кандидаты регулярно получают 3–4 по всем четырём измерениям. Тест не должен быть сложным, чтобы хорошо различать — он должен быть реальным.
Как провести тест без утечек
- Ротируйте между 3–4 вариантами сломанного приложения.
- Назначьте кандидату случайно выбранный вариант.
- Используйте сигналы кодовой согласованности и целостности ClarityHire, чтобы кандидат, который вставил исправление откуда-то ещё, был помечен для проверки на последующем звонке.
- Всегда сочетайте тест с 30-минутным последующим звонком, где кандидат проходит через свои изменения. Если они не могут объяснить собственный diff, оценка снижается.
Что никогда не делать
- 4-часовые take-home работы. Вы потеряете лучших кандидатов компаниям, которые уважают их время.
- Открытые «постройте клон X». Дисперсия слишком высока; рубрики ломаются.
- Тесты, требующие установки локального окружения с нуля. Используйте хостированную IDE, чтобы время установки было нулевым.
Правильный фронтенд-тест занимает 90 минут, отражает задачу вторника утром и дает оценку рубрики, которую можно защитить на разборе.