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

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

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

Как отвечать

Начните с вопросов к задаче: нужны ли SEO и быстрая первая отрисовка, это публичный сайт или внутренняя админка, сколько команд будет работать в одном коде. От ответа зависит основа:

• фреймворк: для публичного продукта с SEO подойдёт Next.js (App Router) или Nuxt, для внутреннего SPA хватит React или Vue на Vite. Create React App официально объявлен устаревшим, начинать на нём нельзя;
• язык: TypeScript в режиме strict с первого коммита, потом включить его гораздо сложнее;
• состояние: разделить серверное и клиентское. Серверное держит TanStack Query или RTK Query, для клиентского хватает Zustand, во Vue стандарт это Pinia. Context API не менеджер состояния, а способ передать значение вниз по дереву;
• формы: React Hook Form и Zod, одна схема и для типов, и для проверки;
• стили: CSS Modules или Tailwind. Рантайм CSS-in-JS плохо дружит с серверными компонентами;
• тесты: Vitest и Testing Library для компонентов, Playwright для e2e, MSW для моков API;
• качество: ESLint, Prettier, проверка типов и тесты в CI на каждый pull request.

Архитектуру опишите через границы: модули по фичам или Feature-Sliced Design, у каждого модуля публичный index.ts, глубокие импорты запрещены правилом линтера. Типы контракта с бэкендом генерируйте из OpenAPI. Если приложений несколько, берите монорепозиторий на pnpm workspaces с Turborepo. Ключевые решения фиксируйте в ADR.

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

Перечисляют стек без единого «потому что». Список «React, Redux, Jest» без связи с требованиями звучит как чтение резюме.

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

Забывают про процесс: code review, соглашения по структуре, мониторинг ошибок через Sentry и Web Vitals. Без них выбранный стек не спасает от хаоса.