Был ли опыт работы с срочными запросами при недостатке данных и как вы действовали
Что проверяют
Как вы действуете, когда срок жёсткий, а требований или данных не хватает: ждёте, молча додумываете или фиксируете допущения и снижаете риск. Следом обычно спрашивают, что было бы, окажись допущение неверным, и как вы откатили бы решение в мобильном приложении.
Как отвечать
Нужна одна реальная история по схеме STAR с вашими цифрами: сколько было времени, чего не хватало, что вышло в итоге. Каркас:
- ситуация: например, фичу нужно выпустить к акции через неделю, а контракта API ещё нет или макеты неполные;
- что вы выяснили в первые часы: минимальный набор вопросов к продукту и бэкенду, без которого нельзя начинать, и кто принимает решение по остальному;
- допущения письменно: список в задаче или в чате, с согласием заказчика. Так решение становится общим, а не висит на вас одном;
- изоляция неизвестного: интерфейс репозитория и фейковая реализация на заглушках или
MockWebServer, чтобы экран делался параллельно с бэкендом; экран не падает наnullи пустых списках; - обратимость: мобильный релиз не откатить за минуту, поэтому фичу закрывают флагом через Remote Config и выпускают поэтапным раскатом в Google Play, следя за падениями в Crashlytics;
- итог и вывод: что сработало, какое допущение не подтвердилось и что вы теперь делаете иначе.
Если такого опыта не было, скажите прямо и расскажите ближайший: учебный или пет-проект со сжатым сроком. Можно описать, как действовали бы по этим шагам. Честный небольшой пример сильнее выдуманного масштабного.
Где спотыкаются
Рассказывают, как героически сделали всё за ночь, молча додумав требования. Для интервьюера это риск: в следующий раз догадка окажется неверной.
Приводят круглые проценты без источника, вроде «жалобы упали на 30%». На вопрос, как это мерили, ответа нет, и доверие ко всей истории пропадает.
Забывают про специфику мобильной разработки и предлагают «быстро поправить потом», хотя исправление доедет до пользователей только после ревью в сторе и обновления приложения.