Есть ли дизайн в проекте?
Что проверяют
Работали ли вы по макетам дизайнера или собирали интерфейс сами, и насколько самостоятельны в обоих случаях. Следом обычно спрашивают: «Что делаете, если в макете нет состояния ошибки или мобильной версии?» Иногда это одновременно вопрос о команде: будет ли у вас дизайнер на новом месте.
Как отвечать
Опишите процесс конкретно:
- источник макетов: Figma, Dev Mode для отступов и экспорта ресурсов, auto layout и переменные, по которым видно, как блок ведёт себя при растягивании;
- дизайн-система: токены цветов, отступов и типографики, которые превращаются в CSS-переменные или тему (
ThemeProvider, конфиг Tailwind), компоненты в Storybook, сверка с дизайнером на уровне компонентов, а не экранов; - пробелы в макете: загрузка, пустой список, ошибка, длинный текст, промежуточные ширины. Сильно звучит, когда вы находите их сами и приносите дизайнеру списком, а не додумываете молча;
- без дизайнера: библиотека компонентов (MUI, Ant Design, shadcn/ui), единая сетка и шкала отступов, гайды платформы;
- качество реализации: адаптивность, доступность (контраст, фокус, семантика), разумная точность по макету.
Примеры нужны свои: какой продукт, был ли дизайнер на полную ставку, как проходила приёмка вёрстки. Если дизайнера не было, так и скажите и объясните, чем держали единообразие интерфейса. В конце уместно спросить в ответ, есть ли дизайнер и дизайн-система у них: от этого зависит, сколько UI-решений ляжет на вас.
Где спотыкаются
Отвечают общими словами вроде «дизайн важен для пользовательского опыта». Интервьюеру нужен ваш процесс, а не тезис.
Занимают крайнюю позицию. «Верстаю строго по макету, остальное не моё» звучит пассивно, «правлю макет как считаю нужным» говорит о том, что договариваться вы не привыкли.
Не умеют читать макет: не знают про auto layout и переменные в Figma, меряют отступы на глаз и не спрашивают про состояния. Такого кандидата сложно отпустить работать с дизайнером напрямую.