Как строилась архитектура проекта и почему были выбраны определенные решения

Что проверяют

Можете ли вы объяснить устройство проекта через решения и их причины: какие были ограничения, какие альтернативы рассматривали, чем заплатили. Следом обычно спрашивают, что бы вы сделали иначе сегодня.

Как отвечать

Рассказывайте про свой реальный проект, от требований к решениям. Удобный каркас для фронтенда:

• рендеринг: SPA на Vite, SSR или SSG на Next.js или Nuxt. Выбор зависит от SEO, скорости первого экрана и того, насколько интерфейс живёт за логином;
• структура кода: по фичам или по слоям, Feature-Sliced Design, монорепозиторий на pnpm workspaces, Nx или Turborepo, микрофронтенды через Module Federation, если несколько команд релизятся независимо;
• состояние: серверные данные в TanStack Query или RTK Query с кэшем и инвалидацией, клиентское в Zustand, Redux Toolkit или просто в контексте. Само разделение этих двух видов состояния уже сильный аргумент;
• связь с бэкендом: REST с генерацией типов из OpenAPI, GraphQL, BFF-слой;
• качество: TypeScript в строгом режиме, ESLint, тесты на Vitest и Testing Library, e2e на Playwright, дизайн-система в Storybook.

У каждого пункта назовите причину и цену: «взяли микрофронтенды, потому что четыре команды мешали друг другу релизами, заплатили дублированием зависимостей и сложной общей навигацией». Цифры приводите свои: размер бандла, LCP, время сборки.

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

Где спотыкаются

Перечисляют стек вместо решений: «React, Redux, TypeScript». Без причины и альтернативы это список технологий, а не архитектура.

Уходят в бэкенд: микросервисы и Node.js на сервере не отвечают на вопрос, как устроен клиент и почему именно так.

Складывают всё подряд, включая ответы API, в глобальный Redux-стор и называют это архитектурой. Сейчас от кандидата ждут понимания, что серверный кэш и состояние интерфейса живут по разным правилам.