Есть ли согласованный дизайн задачи

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

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

Как отвечать

Опишите, как вы проверяете макет до старта. Готовый дизайн это не одна картинка экрана, а набор состояний:

• состояния данных: загрузка, пустой список, ошибка, очень длинный текст, одна запись и тысяча;
• интерактивность: hover, focus, disabled, активное состояние, анимации переходов;
• адаптив: брейкпоинты, мобильная версия, поведение таблиц на узком экране;
• доступность: контраст, видимый фокус, работа с клавиатуры;
• дизайн-система: собран ли экран из существующих компонентов и токенов или требует новых.

В Figma удобно смотреть через Dev Mode и статус «Ready for dev»: он показывает, что дизайнер считает макет готовым. Недостающее собирайте в вопросы и фиксируйте ответы в задаче, а не в личке, чтобы договорённость видели тестировщик и ревьюер.

Если дизайн не согласован, а сроки идут, не ждите и не рисуйте сами. Начните с того, что от макета не зависит: работа с API, состояние, логика, каркас на компонентах дизайн-системы. Раннюю сборку на стенде или в Storybook покажите дизайнеру, так расхождения всплывают до ревью.

Подкрепите ответ своим примером: какой вопрос по макету вы задали вовремя и какую переделку это сэкономило. Если такого случая не было, опишите, как действовали бы, и не выдумывайте историю.

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

Верстают по черновику «чтобы не простаивать», а потом переделывают половину экрана после финальной версии.

Молча отступают от макета, потому что «так удобнее в коде». Даже разумное отступление нужно согласовать, иначе его вернут как баг.

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