Кто ставит задачи разработчикам: PM, аналитики или другие специалисты

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

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

Как отвечать

Разложите роли по тому, что каждая приносит:

• PM: что делаем и зачем, приоритет, срок. Уточните, о ком речь: product manager отвечает за ценность, project manager за сроки и ресурсы;
• аналитики: бизнес-аналитик описывает правила, сценарии и крайние случаи, системный доводит их до контракта: .proto-файлы для gRPC, спецификация OpenAPI, модель данных, диаграммы последовательности, маппинг полей в интеграциях;
• техлид: технические задачи, декомпозиция, нефункциональные требования, техдолг;
• соседние команды и SRE: изменения контракта у потребителей, требования к метрикам, алертам, лимитам ресурсов;
• сами разработчики: рефакторинг, обновление зависимостей в go.mod, исправление найденных проблем.

Затем скажите, что вам важно получить в задаче, чтобы сделать её хорошо на Go: контракт ручки и коды ошибок, ожидаемая нагрузка и допустимая задержка по p99, поведение при таймаутах и повторах, нужна ли идемпотентность, что пишем в логи и метрики.

Покажите работу с неполной постановкой: вы не ждёте идеального ТЗ и не додумываете молча, а задаёте вопросы до начала работы, фиксируете ответы в задаче и предлагаете свой вариант. Если постановка расходится с кодом, приходите к аналитику с конкретикой: «это поле уже читает другой сервис, предлагаю добавить новое».

Опирайтесь на опыт своей команды.

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

Говорят «работаю только по полному ТЗ». Для продуктовой команды это звучит как неготовность к диалогу.

Путают системного аналитика с аналитиком данных и приписывают аналитикам задачи по производительности. Производительность обычно приходит от техлида или SRE как нефункциональное требование.

Перечисляют роли, но не могут объяснить, как задача проходит от идеи до мержа и где в этом пути их зона. Нужна именно цепочка, а не список должностей.