Как ты принимаешь технические решения под давлением?
Что проверяют
Спокойный trade-off-подход вместо героизма: можете ли вы быстро выбрать «достаточно хорошее» решение, зафиксировать допущения и не оставить после себя мину. Красный флаг — «сделал как получилось, потом разберёмся» без «потом».
Скелет ответа
- Критерии: риск для пользователя, срок, обратимость. Обратимое решение можно принимать быстро; необратимое (формат данных, публичный API, схема БД) заслуживает паузы даже под давлением.
- Сузить задачу: минимальное изменение, которое снимает проблему; feature flag, чтобы откатить без релиза.
- Зафиксировать допущения: комментарий в коде, тикет на «дозакрыть», сообщение команде — чтобы временное не стало постоянным.
- Коммуникация: сказать, что выбрано, почему и какова цена; договориться о времени на нормальное решение.
- После: короткий разбор — почему давление возникло и как его избежать.
Пример ответа
S: За день до релиза QA нашёл, что на iOS 17 экран оплаты падает из-за изменений в сторонней SDK, обновлённой в этом спринте.
T: Решить за несколько часов: откатывать SDK, чинить или переносить релиз.
A: Критерии: пользователь не должен попасть на крэш; релиз важен, но не критичен; откат SDK обратим, а перенос релиза — дорог. Откатил SDK на прошлую версию (обратимо, 30 минут), обернул вызов в if #available с проверкой версии и добавил feature flag на новую версию SDK. Зафиксировал в тикете: «SDK откачена, причина — крэш на iOS 17 в X, вернуть после фикса от вендора». Сообщил продукту и команде в треде.
R: Релиз вышел вовремя без крэшей. Вендор выпустил фикс через неделю, мы включили новую версию через flag. На ретро договорились обновлять сторонние SDK только в начале спринта и прогонять тесты на минимальной поддерживаемой iOS.