На основе чего выбираются подходы по проектированию, например микрофронтенды и FSD
Что проверяют
Умеете ли вы выбирать архитектуру под ограничения проекта, а не по популярности термина. Ключевая проверка спрятана в самой формулировке: микрофронтенды и FSD стоят на разных уровнях, и если кандидат обсуждает их как альтернативы, становится ясно, что он знает только названия.
Как отвечать
Сначала развести понятия. FSD (Feature-Sliced Design) это методология раскладки кода внутри одного приложения: слои shared, entities, features, widgets, pages, app, внутри слоя слайсы по предметной области, внутри слайса сегменты ui, model, api, lib. Правило одно: импорт идёт только вниз по слоям и только через публичный интерфейс слайса. Решает проблему кодовой базы, где всё импортирует всё, и делает удаление фичи операцией на один каталог.
Микрофронтенды это про независимую сборку и выкладку частей одного продукта разными командами: Module Federation, композиция на этапе сборки, сборка на сервере или на краю. Цена высокая: дублирование зависимостей, общий роутинг и состояние, рассинхрон версий дизайн-системы, тяжелее сквозные тесты и хуже первая отрисовка.
Дальше критерии выбора: сколько команд и нужны ли им независимые релизные циклы, есть ли легаси, от которого нужно уходить по частям, какой срок жизни и размер кодовой базы, насколько жёсткие требования к скорости загрузки и SEO. И отдельно скажите, что подходы совместимы: каждый микрофронтенд внутри спокойно раскладывается по FSD.
Где спотыкаются
Первое: противопоставляют их и «выбирают одно». Это выбор между способом нарезки папок и способом деплоя, они не конкурируют.
Второе: расшифровывают FSD наугад, чаще всего как что-то про функциональное программирование. Готовые шпаргалки этим грешат, а интервьюер слышит подмену сразу.
Третье: берут микрофронтенды на вырост в команде из трёх человек. Получается распределённый монолит: общее состояние, синхронные релизы и общие поломки, только теперь ещё и через несколько репозиториев.