В каком виде приходит задача

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

Как вы работаете с постановкой: берёте что дали и молча делаете или умеете добрать недостающее. Заодно смотрят, что вы считаете достаточным описанием.

Как отвечать

Опишите реальный процесс и назовите, что должно быть в задаче, чтобы её можно было брать в работу:

• цель и польза: зачем это пользователю или бизнесу. Без этого нельзя предлагать более дешёвое решение той же задачи;
• макет и состояния: не только основной вид, но и пустое состояние, загрузка, ошибка, длинный текст, узкий экран. Дизайнер редко рисует всё, и это первое, что стоит уточнять;
• контракт данных: адрес и формат ответа, что приходит при ошибке, есть ли пагинация. Если бэкенд ещё не готов, договариваются о контракте заранее и работают на заглушке;
• критерии приёмки: по каким проверкам задача считается сделанной;
• ограничения: поддержка браузеров, доступность, влияние на скорость загрузки.

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

Уместно назвать инструменты (Jira, Youtrack, Linear), но не сводить ответ к ним: инструмент это форма, а спрашивают про содержание.

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

Отвечают «задачи приходят в Jira» и замолкают.

Говорят, что берут в работу задачу без критериев приёмки, а потом переделывают по три раза.

Не упоминают уточняющие вопросы вовсе. Для фронтенда это половина работы, потому что крайние состояния интерфейса в макете обычно не нарисованы.