Расскажите про задачу с ошибками, как исправляли и последствия
Что проверяют
Как вы ведёте себя, когда сломанное уже у пользователей. У мобильной разработки цена ошибки выше, чем в вебе: мгновенно откатить релиз нельзя, новая сборка идёт через ревью, а часть людей остаётся на старой версии надолго.
Как отвечать
Берите случай с настоящими последствиями: падение приложения, потеря данных, сломанная оплата. Дальше по шагам.
- Как узнали: рост падений в отчётах,
MetricKit, обращения в поддержку, просевшая метрика экрана. Хорошо, если узнали из мониторинга, а не из отзывов в магазине. - Как локализовали: символикация стектрейса, версии и модели, на которых воспроизводится, попытка повторить локально.
- В чём была причина. Именно причина, а не место падения.
- Чем закрыли: правка, а рядом способ потушить без релиза, удалённый конфиг или флаг фичи.
- Что осталось после: тест на этот сценарий, оповещение по доле сеансов без падений, разбор с командой.
Скажите и про механику релиза: поэтапная раскатка, возможность её приостановить, ускоренное ревью для критичного фикса. Знание этих деталей показывает, что инцидент вы проходили, а не читали про него.
Где спотыкаются
Чинят симптом. Запретить файл больше двух мегабайт проще всего, но если приложение падало на распаковке большого изображения в память, причина в пиковом потреблении, и такое завершение системой в отчёты о падениях вообще не попадает. Через месяц то же самое вылезет на другом экране.
Не отделяют откат от исправления. В магазине приложений нельзя вернуть предыдущую сборку, можно только выпустить новую, поэтому план «если что, откатимся» здесь не работает, и знать это лучше заранее.
Приписывают фиксу чужие последствия: «после исправления загрузки выросли на 15%». Связь недоказуема, и вопрос про то, что ещё менялось в том релизе, разрушает всю историю.