Использовал ли принципы SOLID во фронтенд разработке

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

Умеете ли вы перенести принципы из мира классов в компонентный фронтенд, а не пересказать определения. Вопрос о вашем опыте, поэтому следом почти наверняка попросят пример из проекта и спросят, где SOLID во фронтенде только мешает.

Как отвечать

Покажите каждый принцип на примере React или того фреймворка, с которым работаете:

• S, единственная ответственность: компонент не должен одновременно ходить в API, хранить форму и рисовать таблицу. Загрузку выносят в хук (useOrders) или в TanStack Query, логику формы в отдельный хук, а компонент отображения получает готовые данные;
• O, открытость для расширения: новые варианты добавляются через композицию, children, слоты и props, а не через растущий switch (type) внутри компонента;
• L, подстановка: обёртка над кнопкой или инпутом должна вести себя как нативный элемент. Типизируете props через React.ComponentProps<"button">, пробрасываете ...rest и ref, не ломаете onClick и disabled;
• I, разделение интерфейсов: компоненту аватара нужны src и name, а не весь объект user с тридцатью полями. Узкие props упрощают переиспользование и тесты;
• D, инверсия зависимостей: компонент зависит от абстракции, а не от конкретного axios. API-клиент приходит через контекст, параметр хука или DI, как в Angular через inject(), и в тестах его легко подменить.

Дальше нужен свой пример: какой компонент разрастался, что вы разделили, что стало проще. Если сознательно SOLID не применяли, скажите честно и покажите, что те же идеи у вас работали под другими названиями: кастомные хуки, композиция вместо наследования, презентационные компоненты.

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

Пересказывают учебник с примерами про фигуры и животных. Интервьюер спрашивал про фронтенд, и без компонента или хука ответ выглядит заученным.

Строят иерархии наследования компонентов, чтобы «соблюсти» принцип подстановки. React рекомендует композицию, классовое наследование компонентов в нём почти не используется.

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