Какие челленджи в фронтенд проектах ты можешь выделить?
Что проверяют
Какие проблемы вы видели своими глазами и насколько глубоко их решали. Список «производительность, состояние, кроссбраузерность» знают все, интервьюеру интересен ваш конкретный случай. Следом почти всегда просят: «Расскажите подробнее про один. Как вы это измеряли?»
Как отвечать
Выберите два или три челленджа, с которыми работали сами, и по каждому дайте короткую историю: что болело, как нашли причину, что сделали, чем измерили результат. Темы, которые реально встречаются сейчас:
- производительность: Core Web Vitals, то есть LCP, INP (он заменил FID) и CLS. Смотрят через Lighthouse, вкладку Performance и данные реальных пользователей с библиотекой
web-vitals. Лечат разбиением бандла,React.lazy, оптимизацией картинок, устранением лишних ререндеров; - серверное состояние: кеширование и инвалидация данных с API. Часто задачу решает не глобальный стор, а TanStack Query или RTK Query;
- SSR и гидратация: расхождение серверной и клиентской разметки, тяжёлый JS на старте;
- доступность: навигация с клавиатуры, фокус в модалках, скринридеры, требования WCAG;
- масштаб кодовой базы: дизайн-система, миграция легаси с классовых компонентов или с webpack на Vite, общие типы с бэкендом;
- кроссбраузерность: сейчас это в основном особенности Safari, закрываются через Browserslist, Autoprefixer и проверку поддержки фич.
Цифры нужны свои: «LCP на мобильных снизился с 4,1 до 2,3 секунды по данным реальных пользователей». Если метрик не собирали, скажите об этом и объясните, как проверяли эффект. Если коммерческого опыта мало, берите пет-проект, но рассказывайте так же предметно.
Где спотыкаются
Перечисляют темы из статьи без единого примера. Без истории ответ ничего не говорит о вас.
Называют круглые проценты вроде «ускорили на 40%», но не могут сказать, какую метрику и чем мерили.
Предлагают устаревшие решения: Redux как ответ на любой вопрос о состоянии или CSS-препроцессоры как средство кроссбраузерности, хотя префиксы расставляет Autoprefixer.