Был ли опыт работы с архитектурой фронтенд-приложения, например atomic design или feature-sliced design

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

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

Как отвечать

Сначала разведите подходы, они про разное:

• Atomic Design (Брэд Фрост): методология для интерфейса и дизайн-системы. Атомы, молекулы, организмы, шаблоны, страницы. Отвечает на вопрос, из чего собраны кнопка и карточка, но не говорит, где живут запросы к API и бизнес-логика;
• Feature-Sliced Design: архитектура всего приложения. Слои сверху вниз: app, pages, widgets, features, entities, shared (слой processes в актуальной версии методологии устарел). Слои делятся на слайсы по предметной области, слайсы на сегменты ui, model, api, lib;
• правило импортов FSD: модуль импортирует только из слоёв ниже, слайсы одного слоя друг друга не импортируют, наружу торчит публичный API через index.ts.

Дальше расскажите свой случай: какой был проект, сколько человек в команде, как выглядела структура до и после, что было трудно. Например, как решали, где лежат «добавить в корзину» и «карточка товара», и как ловили нарушения импортов линтером (Steiger или правила eslint-plugin-boundaries).

Если опыта нет, скажите честно: работали с разбиением по типам (components, hooks, services) или по фичам, видели, где такая структура начинает мешать, и понимаете, какую проблему решает FSD. Это лучше пересказа документации.

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

Выдают Atomic Design за архитектуру приложения. Интервьюер спрашивает, где хранится состояние и где лежат запросы, и ответа нет.

Называют фичей всё подряд. В FSD фича это действие пользователя, которое несёт ценность, а сущность, например пользователь или заказ, живёт в entities.

Не могут объяснить, как бороться с кросс-импортами. Прямой импорт соседнего слайса размывает границы, и через полгода от архитектуры остаются только названия папок.