Бывали ли случаи, когда нужно было изменить требования бизнеса
Что проверяют
Умеете ли вы не только выполнять задачи, но и спорить с требованием, когда оно вредит продукту, причём аргументами, а не фразой «так нельзя». Следом обычно спрашивают, чем всё закончилось и как вы договаривались, если бизнес не согласился.
Как отвечать
Нужна одна реальная история: какое было требование, почему оно не работало, что вы предложили, чем кончилось. У Java-разработчика хорошие основания для спора обычно технические и измеримые:
- нагрузка: отчёт хотели генерировать синхронно в HTTP-запросе, а он строился минутами. Предложили асинхронную выгрузку через очередь и уведомление о готовности;
- согласованность данных: требовали точный остаток в реальном времени на всех витринах, а это распределённые блокировки. Договорились о задержке в несколько секунд;
- закон и безопасность: хранить лишние персональные данные или писать их в логи открытым текстом;
- стоимость: месяц разработки ради одного клиента там, где хватает настройки.
В рассказе покажите свои действия: оценили трудоёмкость и риски, подготовили альтернативу с цифрами, донесли её до аналитика или владельца продукта, зафиксировали решение в задаче. Цифры берите свои: время ответа до и после, сэкономленные недели, число обращений в поддержку.
Если такого опыта не было, скажите прямо и расскажите историю поменьше: как нашли противоречие в постановке и уточнили её до начала разработки. Это тот же навык на раннем этапе. Можно добавить, как поступили бы: сначала выяснить цель бизнеса, потом предлагать решение.
Где спотыкаются
Подают историю как «бизнес хотел глупость, а я поправил». Интервьюер слышит, что с вами будет трудно договариваться.
Рассказывают командную историю без себя: «мы провели встречу, мы внедрили Agile». Непонятно, что сделали лично вы.
Не называют компромисс. Требование почти никогда не отменяется целиком, и история без цены решения звучит выдуманной.