Создавал ли ты UI kit во frontend проектах

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

Отличаете ли вы набор компонентов от библиотеки, которой пользуются другие команды. UI kit это продукт с версиями, документацией и обратной совместимостью, и по ответу видно, делали вы такое или просто вынесли кнопки в общую папку.

Как отвечать

Разложите по слоям. Внизу токены: цвета, типографика, шаг отступов, радиусы. Они живут отдельно от компонентов и обычно раздаются переменными CSS, чтобы тема переключалась без пересборки. Выше примитивы: кнопка, поле, модальное окно, выпадающий список. Ещё выше составные блоки продукта, которым в общей библиотеке чаще не место.

Что показывает опыт:

• продуманный API: проброс ref и произвольных атрибутов на корневой узел, контролируемый и неконтролируемый режимы у полей, слоты вместо десятка булевых пропсов;
• доступность: фокус внутри модалки, возврат фокуса при закрытии, движение стрелками по списку, роли и подписи;
• явно заданный способ переопределить стили, иначе потребители полезут в чужие классы селекторами;
• документация с живыми примерами, обычно Storybook, и снимки экранов как защита от случайных визуальных правок;
• отдельный пакет, версии по семантике и заметки о переходе на новую мажорную версию.

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

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

Пишут свой select и теряют клавиатуру, экранные читалки и поведение на мобильных. Это самый дорогой компонент в любой библиотеке, и начинать с него не стоит.

Второе: тащат в библиотеку продуктовую логику, запросы к своему API и навигацию. Такой кит невозможно взять в соседний проект, он превращается в копию одного приложения.

Третье: ломают совместимость без версии и инструкции по переходу. Один переименованный проп в общем пакете это упавшие сборки у всех команд сразу.