К кому обращаться при недостаточно описанной задаче

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

Умеете ли вы снимать неопределённость сами, прежде чем писать код, и знаете ли, кто в команде отвечает за требования. Следом обычно спрашивают: «А если автор задачи недоступен, а срок горит?»

Как отвечать

Покажите порядок действий, а не одно имя. Удобный каркас:

• сначала сами: перечитать задачу, связанные тикеты в Jira, страницы в Confluence, историю коммитов по затронутому коду и существующие тесты. Часто ответ уже есть в соседнем эпике или в том, как ведёт себя текущий сервис;
• постановщик: аналитик или продакт, если вопрос про бизнес-правило. Приходите со списком конкретных вопросов и вариантами: «при пустом customerId возвращаем 400 или создаём гостевой заказ?»;
• техлид или ментор: если неясно, как вписать задачу в архитектуру, какой сервис трогать, можно ли менять контракт API;
• владелец соседней системы: когда задача упирается в чужой сервис, его схему данных или топик Kafka;
• фиксация: договорённость записывается в тикет, иначе через неделю её никто не вспомнит, а ревьюер спросит, откуда взялось такое поведение.

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

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

Отвечают «пойду к руководителю», и на этом всё. Интервьюер слышит, что вы понесёте любую неясность наверх, не попробовав разобраться сами.

Уходят в другую крайность: «додумаю и сделаю». Для Java-бэкенда это часто означает неверный контракт API или миграцию схемы, которую потом придётся откатывать.

Не упоминают, что договорённость надо записать. Устное «вроде договорились» потом превращается в спор на ревью или в баг на проде.