Расскажите об интересном инциденте в системе

Что проверяют

Как вы ведёте себя в проде: видите ли метрики и логи, отличаете ли симптом от причины, доводите ли дело до профилактики. Для Go интервьюер заодно проверит знание характерных граблей языка: утёкшие горутины, гонки за общим состоянием, брошенные контексты, паника в отдельной горутине, которая роняет весь процесс.

Как отвечать

Возьмите одну историю и расскажите строго по порядку: как узнали о проблеме, что видели на графиках, как локализовали, что сделали как временную меру, что стало настоящим исправлением, что изменили, чтобы это не повторилось.

Называйте инструменты по именам: профили pprof по куче и по горутинам, детектор гонок в тестах, трассировка запроса, метрики и логи. Хороший по плотности пример: на графике ровный рост числа горутин, в профиле горутин десятки тысяч висят на записи в канал без читателя, причина в отменённом запросе, после которого писатель никто не разбирает. Лечится контекстом с таймаутом и корректным завершением, а не увеличением лимита памяти.

Добавьте вывод: какой алерт появился, какой тест закрыл дыру, что записали в разбор инцидента. Это показывает инженера, а не человека, которому однажды повезло.

Где спотыкаются

Рассказывают починку без диагностики: перезапустили, стало лучше. Перезапуск это остановка кровотечения, и если вы не знаете, что именно текло, инцидент вернётся в следующий пик нагрузки.

Не разделяют временное решение и системное. Подняли лимит памяти, закрыли задачу, поехали дальше. Интервьюер ждёт продолжения про поиск корневой причины и слышит, что его не было.

Строят рассказ вокруг виноватых: подвёл соседний сервис, база вела себя странно, задачу поставили неправильно. Даже если так и было, в этой истории не видно вашего вклада, а видно человека, с которым тяжело разбирать общий инцидент.