Что спрашивают на фронтенд-собеседовании, как отвечать про React, CSS и производительность и как отрепетировать разговор с ИИ-тренером.
Фронтенд-собеседование отличается от других технических интервью: здесь проверяют не только знание API, но и то, как вы думаете о пользователе. Один и тот же компонент можно написать тремя способами — и вопрос «почему именно так» весит больше, чем сама реализация.
Обычно четыре этапа, и к каждому нужна своя подготовка:
| Этап | Что проверяют | Как готовиться |
|---|---|---|
| Скрининг с рекрутером | опыт, мотивация, ожидания по деньгам | три предложения о себе + вилка |
| Техническое интервью | JavaScript, CSS, браузер, фреймворк | разбор вопросов ниже |
| Live coding | как вы пишете код и рассуждаете | проговаривать вслух ход решения |
| Системный дизайн / архитектура | как проектируете интерфейс и состояние | структурировать ответ: контекст → варианты → выбор |
Здесь проверяют не масштаб, а вашу роль. Плохо: «мы переписали фронт на React». Хорошо: «я отвечал за переход на новый API — пришлось держать совместимость, вот как я это сделал и что это дало по метрикам».
Типовой набор: event loop, промисы против async/await, всплытие событий, делегирование, `this`, замыкания, отличия `var`/`let`/`const`, разница между копированием по ссылке и по значению. Ждут не определения, а пример использования.
Flexbox против Grid, специфичность селекторов, как работает `position: sticky`, что такое margin collapse, как сделан адаптив без медиазапросов. Проверяют способность объяснить, а не помнить синтаксис.
Разница между состоянием и пропсами, зачем ключи в списках, что такое ререндер и как его избежать, `useEffect` и его зависимости, мемоизация, контекст против стейт-менеджера. Часто просят найти ошибку в фрагменте кода.
Что такое Core Web Vitals, как измерять LCP и CLS, что делать с лишним JS в бандле, зачем code splitting и lazy loading, как работает кэширование. Здесь важно назвать конкретные инструменты: Lighthouse, Performance API, Chrome DevTools.
Семантические теги, ARIA, фокус и клавиатурная навигация, контраст. Отсеивающий вопрос для многих кандидатов.
Проверяют, умеете ли видеть состояния (например, hover, disabled, отсутствие данных), а не только идеальный макет.
На технических вопросах работает та же структура, что и на поведенческих: тезис → обоснование → пример → ограничение. Последний шаг чаще всего забывают, а именно он отличает senior от middle.
«Для этого кейса я бы использовал виртуализацию списка. Причина — DOM не тянет десять тысяч узлов: при скролле начинаются просадки. В прошлом проекте мы так сократили время до интерактивности примерно втрое. Ограничение: виртуализация плохо работает с переменной высотой строк — тогда нужен замер».
Обратите внимание: есть решение, причина, конкретный результат и честная граница применимости. Такой ответ нельзя «выучить» — но можно отрепетировать.
| День | Что делать | Время |
|---|---|---|
| 1 | Выписать свои 5 проектов: роль, задача, результат в цифрах | 40 мин |
| 2 | Пройти по 7 темам выше и отметить, где ответ не складывается | 40 мин |
| 3 | Ответить вслух на 10 вопросов, записать себя на диктофон | 30 мин |
| 4 | Разобрать запись: где паузы, где потеря структуры | 20 мин |
| 5 | Прогнать полный диалог с ИИ-тренером по своей вакансии | 30 мин |
| 6–7 | Повторить проблемные ответы, повторить прогон | 20 мин |
Что меняется: скорость сборки ответа, способность не терять структуру на неожиданном вопросе, умение назвать ограничение своего решения. Это замечают уже после трёх-четырёх прогонов.
Чего не будет: подготовка не заменяет знание технологии. Если вы не понимаете event loop, красивая структура ответа не поможет. Сначала — знание, потом — умение его подать.
Если техническая база есть — неделя по 30–40 минут: структура ответов, проговаривание вслух, один полный прогон диалога. Если база проседает по конкретной теме (например, event loop или CSS-каскад), сначала закройте её, иначе структура ответа не поможет.
Зависит от компании: в продуктовых командах чаще дают практические задачи (написать компонент, разобрать баг), в крупных tech-компаниях — классические алгоритмы. Уточните формат у рекрутера заранее — это нормальный вопрос.
Скажите прямо и покажите, как будете искать: «Не работал с этим напрямую, но логика похожа на X — я бы проверил в документации и на прототипе». Это оценивается выше, чем выдуманный ответ: интервьюер почти всегда видит, когда кандидат плывёт.
Да, это отдельный навык. Тренируйтесь проговаривать решение вслух, писать код в редакторе без автодополнения и начинать с уточняющих вопросов. Даже уверенный разработчик без этой практики теряется на первой сессии.
Называйте диапазон, а не одно число, и опирайтесь на рынок. Как это сделать без неловкости — разобрано в статье переговоры о зарплате.
Опишите ситуацию одной фразой — «собеседование на frontend-разработчика, React, три года опыта» — и пройдите диалог в тренажёре. Тренер задаст вопросы по вашей роли и разберёт ответы после разговора.
Начните с пяти проектов: роль, задача, результат в цифрах. Затем прогоните полный диалог — откройте HintMeTalk AI, режим «Тренер», опишите ситуацию. После разбора станет видно, какие ответы провисают: обычно это два-три из десяти, и именно они решают исход.
Общие принципы подготовки к любому собеседованию — в статье подготовка к собеседованию. А если предстоит разговор о деньгах — переговоры о зарплате.
Потренируйте этот навык в HintMeTalk AI
Открыть в приложении
HintMeTalk