Как устроен продукт?
Что проверяют
Видите ли вы продукт целиком, а не только свои компоненты: для кого он, как по нему идёт пользователь и где в этой картине фронтенд. Следом обычно спрашивают, какую часть делали лично вы и что бы поменяли.
Как отвечать
Идите сверху вниз и уложитесь минут в пять:
- продукт и пользователи: какую задачу решает, ключевые сценарии, масштаб в понятных цифрах: аудитория, число экранов, частота релизов;
- клиентская часть: SPA, SSR или гибрид, например Next.js с серверным рендерингом публичных страниц и клиентским личным кабинетом. И почему так: SEO, скорость первой загрузки, требования к офлайну;
- данные и API: REST или GraphQL, есть ли BFF, как устроены авторизация и обновление токенов, чем кэшируются запросы (TanStack Query, SWR, RTK Query);
- поставка: сборщик, CI с линтером и тестами, превью-стенды на ветку, feature flags, раздача статики через CDN;
- наблюдаемость: сбор ошибок фронтенда, метрики Core Web Vitals, продуктовая аналитика;
- ваша зона: какие модули ваши, какие решения вы продвигали и чем это закончилось.
Цифры и примеры берите из своего проекта, чужой шаблон узнаётся сразу. Если продукт под NDA, описывайте архитектуру без названий и клиентов, это нормально и выглядит профессионально. Если вы работали в маленькой части большой системы, так и скажите и опишите границы: откуда приходят данные и куда уходят ваши события.
Тот же вопрос полезно задать работодателю в конце собеседования. По ответу видно, есть ли у фронтенда своя архитектура и владелец или команда просто верстает по макетам.
Где спотыкаются
Перечисляют стек вместо устройства: «React, Redux, TypeScript». Интервьюеру нужны связи между частями и причины выбора, а не список библиотек.
Говорят только «мы». Непонятно, что делали вы лично, а следующий вопрос будет ровно об этом.
Уходят в бэкенд, которого не знают, и путаются в деталях. Честнее очертить границу своей зоны и сказать, что о соседях вы знаете на уровне контрактов API.