Что на самом деле проверяют на собеседованиях фронтенд-разработчиков?

С кем вы на самом деле будете говорить

Собеседование фронтенд-разработчика обычно включает три-четыре раунда, и каждый проверяет что-то своё. Сначала скрининг с рекрутером — логистика и вилка зарплаты. Потом разговор с нанимающим менеджером, который на самом деле проверяет, умеете ли вы внятно описать собственную работу — что сделали, за что отвечали, что изменили бы. Затем один-два технических раунда, обычно с действующим инженером из команды, в которую вы попадёте, иногда с двумя сразу, чтобы один наблюдал, пока другой ведёт беседу. Для senior-позиций часто проводят отдельную беседу по архитектуре или проектированию систем, иногда со staff-инженером или тех-лидом, который не будет вашим руководителем. Если есть тестовое задание, его разбор — отдельный раунд: кто-то читает ваш код до разговора, а обсуждение целиком строится вокруг ваших решений, а не того факта, что код работает.

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

Технический скрининг: что он проверяет

Большинство технических скринингов для этой роли проходят в общих редакторах — CoderPad, CodeSandbox, VS Code Live Share — и охватывают смесь чистого JavaScript и работы с фреймворками. Типичный сценарий: сначала небольшая задача на чистом JS (написать debounce, развернуть вложенный массив, реализовать простой event emitter), затем задача на компонент в том, что команда реально использует — React, Vue, Svelte. Чистый JS нужен именно потому, что фреймворки скрывают основы. Интервьюер, который просит написать debounce руками, не проверяет, помните ли вы его наизусть; он проверяет, понимаете ли вы замыкания и event loop настолько хорошо, чтобы объяснить, почему debounce их требует, что вскрывается, когда он спрашивает: «что произойдёт, если пользователь размонтирует компонент, пока таймер всё ещё висит?»

Со стороны фреймворка типичная задача: собрать небольшой кусок UI со стейтом, вызовом API, состояниями загрузки и ошибки, и, может быть, списком с ключами. Оценивают редко то, отрендерилось ли оно. Оценивают то, обрабатываете ли вы скучные части — race conditions, если API-вызов завершается не по порядку, что происходит с пустым списком, почему вы поставили key на элемент списка, а не на индекс. Кандидат, который получил рабочий компонент, но не может объяснить, почему использовал key={item.id} вместо key={index}, выдал результат без понимания, и эта брешь — именно то, для чего существует этот раунд.

CSS и вёрстка: часть, к которой готовятся хуже всего

Собеседования фронтенд-разработчиков всё ещё проверяют CSS напрямую, часто отдельно от JavaScript, потому что это та часть, где кандидаты чаще всего блефуют, используя утилитарные классы фреймворка. Ожидайте, что вас попросят сверстать что-то на Flexbox или Grid вживую, на доске или в общем редакторе, иногда без фреймворка и без препроцессора. Настоящий вопрос за «как бы вы это отцентровали» никогда не про центрирование — это про то, понимаете ли вы box model, stacking contexts и специфичность достаточно хорошо, чтобы исправить баг вёрстки, который вы никогда не видели, на странице, которую вы не писали, под небольшим давлением времени. «Почему вы выбрали бы здесь Grid, а не Flexbox» — вопрос на суждение. У него есть настоящее, обоснованное объяснение — Grid для двумерной вёрстки, Flexbox для одной оси с размерами, зависящими от контента — и интервьюер, который работает с этим ежедневно, мгновенно заметит, если вы повторяете правило, которое прочитали, а не то, которое реально применяли.

Вопросы, которые звучат как беседа, но ими не являются

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

• «Опишите, что происходит от ввода URL до появления страницы на экране.» Это проверяет, понимаете ли вы DNS, цикл запрос-ответ, парсинг, критический путь рендеринга и где вписываются такие вещи, как render-blocking скрипты или defer/async. Поверхностный ответ заканчивается на «браузер получает HTML и рендерит его». Настоящий ответ упоминает разницу между парсингом и рендерингом, почему CSS блокирует рендеринг, а JS может блокировать парсинг, и где вписывается гидратация, если приложение отрендерено на сервере.
• «Расскажите про утечку памяти, которую вы отлаживали.» Этот вопрос фильтрует быстро. Те, кто реально это делал, называют инструмент — вкладка Memory в Chrome DevTools, heap snapshot, отвязанные DOM-узлы, обработчик событий, не удалённый при размонтировании — и описывают конкретное исправление. Те, кто не делал, говорят «я бы проверил код на утечки памяти» и не идут дальше.
• «Почему вы выбрали [Redux / Context / Zustand / что вы там использовали] для стейта здесь?» Интервьюер уже знает ответ на «что делает Redux». Он спрашивает, взвешивали ли вы его против альтернатив для этой конкретной задачи — был ли стейт разделён между множеством далёких компонентов, нужна ли была отладка с time-travel, или вы потянулись к нему по привычке. «Redux хорош для глобального стейта» пересказывает факт, который все в комнате уже знают.
• «Как бы вы сделали этот список навигируемым с клавиатуры / как screen reader прочитает этот компонент?» Вопросы про доступность — сильный сигнал, потому что мало кандидатов реально использовали screen reader или читали WCAG дальше краткой выжимки в блоге. Перечисление ARIA-ролей, которые вы выучили, без объяснения, какой нативный HTML-элемент сделал бы их ненужными, воспринимается как поверхностное знание, а не практика.

Как звучит поверхностный ответ изнутри

Тот, кто регулярно проводит собеседования фронтендеров, слышит заученный ответ в первом-втором предложении. У него обычно три черты: он называет инструмент без описания механизма («React использует виртуальный DOM для производительности» без упоминания reconciliation или когда диффинг реально помогает, а когда нет), он трактует вопрос о компромиссе как фактический («CSS-in-JS лучше, потому что он изолирован», без признания runtime-цены или build-time альтернатив вроде vanilla-extract), и он не выдерживает одного уточняющего вопроса. Если вы говорите «я улучшил время загрузки», и честный следующий вопрос — «насколько, и чем вы измеряли, Lighthouse или чем-то ещё?» — делает вас расплывчатым, это та брешь, для обнаружения которой и было устроено собеседование. То же применимо к основам безопасности: назвать XSS и CSRF — не то же самое, что объяснить, почему React экранирует значения по умолчанию и где эта защита заканчивается (сырой dangerouslySetInnerHTML, сторонние скрипты, innerHTML из ответа API).

Спорный момент: алгоритмы и тестовые задания

В индустрии есть настоящие разногласия по поводу того, должны ли фронтенд-разработчики вообще сталкиваться с алгоритмическими раундами в стиле LeetCode, учитывая, что работа — это в основном UI, стейт и поведение браузера, а не проектирование структур данных. Некоторые компании сохраняют их, потому что их легко оценивать одинаково для всех кандидатов; другие отказались от них в пользу парного программирования на реалистичных UI-задачах, утверждая, что алгоритмический раунд измеряет практику собеседований больше, чем навык работы. Ни одна точка зрения не выиграла спор, и вы встретите оба типа интервьюеров, так что стоит напрямую спросить рекрутера, что на самом деле содержит технический раунд, а не гадать. Тестовые задания вызывают похожий раскол: одни команды используют их, чтобы уважать время кандидатов относительно живого кодирования, другие отказались от них, потому что неоплачиваемые многочасовые упражнения отфильтровывают людей с меньшим количеством свободного времени, а не с меньшим навыком. Если вам дали одно, последующий разговор о нём обычно важнее самого упражнения — ожидайте вопросов о том, почему вы структурировали компоненты именно так, а не просто работает ли оно.

Что делать дальше

Перечитайте саму вакансию и отметьте каждый фреймворк, инструмент и паттерн, который там назван — React против Vue, TypeScript, конкретная библиотека для стейта, SSR против CSR, дизайн-система. Интервьюеры спрашивают о том, что указано на странице перед ними. Возьмите два-три своих прошлых проекта и отрепетируйте вслух конкретные компромиссы, которые вы сделали в каждом — не что делал проект, а почему вы выбрали один подход вместо альтернативы, которую не взяли. Попractикуйтесь объяснять одну реальную сессию отладки в деталях, называя инструмент, который использовали. Если вопросы по CSS-вёрстке вас нервируют, потратьте час на построение вёрстки с Grid и Flexbox с нуля, без фреймворка, пока не сможете объяснить выбор, не подглядывая никуда.

jobmarket.pro читает вакансию за вас, сопоставляет её с вашей реальной историей проектов и готовит заявку на основе этого — так что то, что попадает к интервьюеру, уже соответствует тому, что вы сможете защитить, когда он на это надавит.