Почему вы выбрали структурную организацию компонентов вместо FSD?
Что проверяют
Был ли выбор структуры осознанным решением или просто тем, что получилось само. Заодно смотрят, знаете ли вы FSD настолько, чтобы отказываться от неё по существу, а не потому что не разобрались.
Как отвечать
Сначала покажите, что понимаете, за что в FSD платят: слои от shared до app, внутри слоя срезы по предметной области, сегменты ui, model, api, правило односторонних импортов (слой знает только про нижние) и вход в срез через публичный индексный файл. Ценность тут не в папках, а в запрете связей, который проверяется линтером.
Дальше назовите критерий, по которому выбирали:
- размер и срок жизни: на приложении из полутора десятков экранов и одной команды слои дают больше церемоний, чем пользы;
- состав команды: правило импортов работает, только если его соблюдают все, иначе через месяц это обычные папки со странными названиями;
- что именно болит: методология лечит спутанные зависимости между фичами. Если боль в другом (время сборки, типы, отсутствие тестов), перекладывание папок её не уберёт.
Сильный ответ заканчивается тем, что вы всё равно взяли из методологии: направление зависимостей, запрет импорта из фич в общий код, единая точка входа в модуль. И условием пересмотра: появились взаимные импорты между фичами, фичу нельзя удалить одной папкой, значит пора переходить, причём послойно, начиная с общего кода.
Где спотыкаются
Ругают FSD, не зная терминов. Ответ «там слишком много папок» вызывает уточнение про срез и сегмент, и на этом разговор про архитектуру заканчивается.
Второе: называют архитектурой раскладку по типам файлов. Папки components, hooks, utils без единого правила о направлении импортов не ограничивают ничего, и через год в общей папке лежит половина продукта.
Третье: обещают переписать всё на FSD в следующем квартале. Собеседник знает, что разовая миграция целого проекта не доводится до конца, и ждёт плана по шагам, а не обещания.