Middle Technical Support Engineer — Питання на співбесіді інженера технічної підтримки

Одна й та сама помилка трапилась у дванадцяти тікетах за місяць, спільна причина поки не видна. Як ви розслідуєте?

Зберіть усі дванадцять тікетів і шукайте, що насправді спільне — браузер, тарифний план, фіча-флаг, час доби, регіон — замість того щоб вважати їх непов'язаними через різні зовнішні симптоми. Відтворіть на найвужчій спільній умові, яку знайдете, потім перевірте нещодавні деплої чи зміни конфігурації довкола моменту, коли патерн з'явився. Якщо відтворити не вдається, це саме по собі дані, які варто передати розробці, а не закривати тікети як поодинокі випадки.

Як ви називаєте клієнту строк, коли справді не знаєте, скільки займе виправлення?

Називайте час наступного оновлення, а не час вирішення проблеми, бо обіцянка строку, який ви не можете підтвердити, гірша за чесне «поки немає точного строку, але я напишу вам до 15:00». Коли розробка дасть реальну оцінку, передайте її з тією ж чесністю щодо невизначеності. Клієнти набагато краще переносять незнання, ніж ситуацію, коли їм сказали те, що виявилося неправдою.

Як ви балансуєте CSAT і час вирішення, коли вони тягнуть у різні боки?

Поспішне рішення, яке насправді не вирішує проблему, обвалює CSAT при повторному зверненні, навіть якщо у звіті виглядає швидким, тож швидкість без правильності — фальшива перемога. Справжній важіль зазвичай — перша відповідь і частота оновлень: клієнти оцінюють досвід очікування, а не лише сумарні хвилини, тому повільніше рішення з зрозумілими оновленнями часто отримує вищу оцінку, ніж швидке, але мовчазне.

Тікет уже тричі передавали між підтримкою й розробкою без результату. Що ви робите?

Зупиніть пінг-понг, узявши тікет на себе як єдину точку контакту — прочитайте всю історію, напишіть короткий підсумок того, що реально відомо, і призначте короткий синк замість чергової асинхронної передачі. Більшість таких циклів виникають через те, що кожна сторона відповідає на трохи інше питання; коли всі обговорюють один і той самий випадок відтворення, цикл зазвичай розривається.

Ваша черга тікетів — 200 і зростає. Що ви реально робите інакше, ніж у звичайний день?

Спершу пакетна пріоритизація — сортування за серйозністю і ризиком порушення SLA, перш ніж відповідати на щось, а не робота згори вниз за часом надходження. Швидко надсилайте проміжні відповіді на менш пріоритетні тікети, щоб зупинити годинник SLA і виграти час, а потім беріться за справжні термінові випадки. І повідомте про саму чергу керівнику, бо черга, що зростає, зазвичай сигнал про нестачу людей або повторюваний баг, а не те, що треба мовчки тягнути.