Как использовать принципы программирования в повседневной работе

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

Не знание расшифровки SOLID, а то, влияют ли принципы на решения в коде, который вы пишете каждый день. Следом почти всегда просят конкретный случай: где принцип помог, а где вы от него сознательно отступили.

Как отвечать

Возьмите два или три принципа и к каждому приложите пример из своего фронтенд-кода. Каркас такой:

• единственная ответственность: компонент, который сам ходит в API, хранит форму и рисует таблицу, вы разбили на хук useOrders, компонент формы и чистый компонент отображения. Покажите, что стало проще: хук тестируется без рендера, таблица переиспользуется;
• открытость для расширения: вместо растущей цепочки условий по типу внутри кнопки или модалки передаёте вариант через пропсы, children или словарь вариантов;
• инверсия зависимостей: компонент получает функцию загрузки или клиент API через пропсы или контекст, поэтому в тестах и Storybook его легко подменить;
• DRY с оглядкой: общий код выносите, когда повтор случился третий раз и совпадает смысл, а не только текст;
• KISS и YAGNI: не заводите глобальный стор и универсальный компонент «на будущее», пока нет второго потребителя.

Лучший ответ строится как история: была проблема (баг в двух копиях одной логики, компонент на 800 строк), вы применили принцип, получили измеримый результат. Цифры берите свои: время ревью, число регрессий, размер файла. Выдуманные проценты интервьюер распознаёт быстро.

Если коммерческого опыта мало, так и скажите и возьмите пример из пет-проекта или код-ревью, где вам указали на нарушение. Честное «я понял это на своей ошибке» звучит сильнее выученного определения.

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

Пересказывают расшифровку пяти букв без единого примера. Это ответ на другой вопрос, и собеседник перестаёт слушать на букве L.

Доводят DRY до абсурда: одна «универсальная» функция с десятью флагами хуже двух похожих, но простых. Неудачная абстракция обходится дороже дублирования.

Переносят принципы из ООП буквально и рассказывают про наследование классов в React, хотя там компоненты принято строить композицией, а не иерархией.