Почему выбрали Tailwind в проекте?

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

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

Как отвечать

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

Второй аргумент про сборку: в итоговый файл попадают только те классы, которые встретились в исходниках, поэтому CSS почти не растёт вместе с проектом, а удаление компонента не оставляет мусора.

Повторы прячутся в компоненты фреймворка, а не в директиву @apply. Встретили одну и ту же кнопку трижды, нужен компонент кнопки.

Обязательно назовите альтернативу и условие: CSS-модули уместнее, когда команда привыкла к обычному CSS или дизайн-система живёт отдельно от разметки.

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

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

Считают, что Tailwind отменяет знание CSS. Каскад, специфичность, flex и grid спросят на том же собеседовании, а без них утилиты превращаются в подбор классов наугад.

Уходят в крайности: сорок классов в одном теге или @apply на каждый элемент. Первое нечитаемо, второе возвращает ровно тот CSS, от которого уходили, только с лишним слоем поверх.