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

Опишіть ваш процес діагностики, коли клієнт пише «у мене не працює».

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

Користувач надіслав скриншот помилки і більше нічого. Що ви робите?

Спершу дістаньте зі скриншота все, що там є — код помилки, час, URL, ID запиту, — перш ніж просити щось іще, бо половина потрібного часто вже там. Далі поставте конкретні уточнювальні питання замість загального «надішліть деталі»: що ви робили перед цим, чи повторюється це щоразу, який браузер і ОС. Конкретне питання отримує корисну відповідь швидше за загальне і показує клієнту, що ви вже подивилися.

У чому різниця між кодами 4xx і 5xx HTTP і чому це важливо для пріоритизації?

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

Як написати баг-репорт, за яким розробник зможе працювати без уточнювальних питань до вас?

Включіть точні кроки відтворення по порядку, очікуваний результат, фактичний результат і середовище — браузер, акаунт, час, ID запиту чи замовлення, якщо застосовно. Додайте сирий текст помилки або фрагмент логу, а не переказ своїми словами, бо розробнику потрібен точний рядок для пошуку. Звіт, за яким можна діяти одразу, — це різниця між виправленням того ж дня і тижнем листування в Slack.

Як пояснити технічну аварію нетехнічному клієнту, не збрехавши і не втопивши його в жаргоні?

Формулюйте поломку через те, що клієнт більше не може зробити, а не через те, що зламалося всередині: «оформлення замовлення зараз не працює у частини користувачів» краще за «наш платіжний шлюз повертає таймаути». Дайте чесний статус і конкретний час наступного оновлення, навіть якщо оновлення — це «новин поки немає», бо мовчання сприймається гірше за погані новини. Внутрішню причину можна взагалі не згадувати, якщо не запитають, і навіть тоді — однією простою фразою.

Клієнт розлючений і погрожує скасувати підписку. Як вести розмову?

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

Що ви шукаєте в тікет-системі на кшталт Zendesk чи Intercom, окрім самої відповіді на тікет?

Теги й категорії, які пізніше роблять патерни видимими — той самий неправильно налаштований вебхук, що зʼявився у двадцяти тікетах, неможливо помітити, якщо вони позначені по-різному. Макроси й заготовлені відповіді на повторювані 80% звернень звільняють час на ті 20%, де справді потрібно думати. І чиста історія внутрішніх нотаток і ескалацій, бо тікет, переданий тричі без контексту, змушує кожного заново діагностувати проблему.

Що таке first response time і чому швидка перша відповідь не гарантує гарний час вирішення?

First response time — це скільки клієнт чекає, перш ніж почути хоч щось від людини, і саме навколо цього побудовано більшість SLA, бо мовчання — те, що змушує людей іти або ескалувати публічно. Але швидке «ми вже дивимося» без реального прогресу за ним просто відкладає роздратування, а не вирішує його, тому команди, що оптимізують лише FRT, можуть отримати швидкі підтвердження і повільні, невимірювані рішення. Час вирішення і CSAT потрібно відстежувати разом із нею, інакше метрику починають підганяти.

У черзі пʼятдесят відкритих тікетів, три позначені як термінові. Як вирішити, за що братися першим?

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