Middle Technical Support Engineer — Technical support engineer interviewfragen

Ein bestimmter Fehler ist diesen Monat in zwölf Tickets aufgetaucht, eine gemeinsame Ursache ist noch nicht erkennbar. Wie gehst du vor?

Zieh alle zwölf Tickets heran und suche nach dem, was wirklich gemeinsam ist — Browser, Plan-Tarif, Feature-Flag, Tageszeit, Region —, statt anzunehmen, sie seien unabhängig, weil das Oberflächensymptom variiert. Reproduziere es mit der engsten gemeinsamen Bedingung, die du findest, und prüfe dann aktuelle Deploys oder Konfigurationsänderungen um den Zeitpunkt, als das Muster begann. Wenn du es nicht reproduzieren kannst, sind das selbst Daten, die du ans Engineering weitergeben solltest, statt die Tickets als Einzelfälle zu schließen.

Wie gibst du einem Kunden eine Zeitangabe, wenn du wirklich nicht weißt, wie lange ein Fix dauert?

Nenne eine Zeit bis zum nächsten Update, nicht bis zur Lösung, denn ein Fix-Termin, den du nicht halten kannst, ist schlimmer als ein ehrliches „ich habe noch keine Zeitschätzung, melde mich aber bis 15 Uhr". Sobald das Engineering eine echte Schätzung liefert, gibst du sie mit derselben Ehrlichkeit über die Unsicherheit weiter. Kunden ertragen Nichtwissen deutlich besser als eine Aussage, die sich später als falsch herausstellt.

Wie balancierst du CSAT und Lösungszeit, wenn sie in entgegengesetzte Richtungen ziehen?

Eine überstürzte Lösung, die das Problem nicht wirklich behebt, drückt den CSAT beim Folgekontakt, selbst wenn sie im Report schnell aussieht, also ist Geschwindigkeit ohne Korrektheit ein Scheinsieg. Der eigentliche Hebel ist meist die erste Antwort und der Update-Rhythmus — Kunden bewerten das Warteerlebnis, nicht nur die Gesamtminuten, weshalb eine langsamere Lösung mit klaren Updates oft besser bewertet wird als eine schnelle, die dann verstummt.

Ein Ticket wurde bereits dreimal zwischen Support und Engineering hin- und hergereicht, ohne Lösung. Was tust du?

Beende das Ping-Pong, indem du es selbst als einzige Anlaufstelle übernimmst — lies die komplette Historie, schreibe eine Ein-Absatz-Zusammenfassung dessen, was tatsächlich bekannt ist, und setze ein kurzes Sync-Meeting an statt einer weiteren asynchronen Übergabe. Die meisten dieser Schleifen entstehen, weil jede Seite eine leicht andere Frage beantwortet; wenn alle über denselben Reproduktionsfall sprechen, löst sich das meist auf.

Deine Ticket-Warteschlange liegt bei 200 und wächst. Was machst du tatsächlich anders als an einem normalen Tag?

Zuerst eine Batch-Priorisierung — sortiere nach Schweregrad und SLA-Bruchrisiko, bevor du überhaupt etwas beantwortest, statt der Reihe nach von oben nach unten zu arbeiten. Schicke schnelle Zwischenantworten bei Tickets mit niedrigerer Priorität, um die SLA-Uhr zu stoppen und Zeit zu gewinnen, und kümmere dich dann um die echten Notfälle. Und melde die Warteschlange selbst deinem Lead, denn eine wachsende Warteschlange ist meist ein Signal für Personalmangel oder einen wiederkehrenden Bug, kein Zustand, den man still auffangen sollte.