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