Technical support engineer interviewfragen

Beschreibe deinen Diagnoseprozess, wenn ein Kunde meldet: „Es funktioniert nicht."

Verwandle die vage Beschwerde zuerst in einen reproduzierbaren Fakt: Was hat der Kunde getan, was hat er erwartet, was ist stattdessen passiert, und kannst du es selbst nachvollziehen? Grenze dann den Suchraum ein, indem du Variablen isolierst — anderer Browser, anderer Account, anderes Netzwerk —, bevor du Logs oder Code anfasst. Erst wenn du es reproduzieren kannst oder klar erklären kannst, warum nicht, gehst du zur Ursachenanalyse über, denn eine Lösung für ein nicht eingegrenztes Problem zu raten, verschwendet die Zeit aller.

Ein Nutzer schickt nur einen Screenshot eines Fehlers und sonst nichts. Was tust du?

Lies aus dem Screenshot alles heraus, was tatsächlich drinsteckt — Fehlercode, Zeitstempel, URL, eine Request-ID —, bevor du nach mehr fragst, denn oft ist bereits die Hälfte dessen vorhanden, was du brauchst. Stelle dann gezielte Rückfragen statt eines allgemeinen „schick mir mehr Details": Was hast du direkt davor gemacht, passiert es jedes Mal, welcher Browser und welches Betriebssystem. Eine konkrete Frage bringt schneller eine nützliche Antwort als eine offene und zeigt dem Kunden, dass du schon hingeschaut hast.

Was ist der Unterschied zwischen einem 4xx- und einem 5xx-HTTP-Statuscode, und warum ist das für die Priorisierung wichtig?

4xx bedeutet, dass die Anfrage selbst fehlerhaft war — falsche Authentifizierung, fehlender Parameter, nicht gefunden —, was meist auf den Client oder eine falsche Eingabe hindeutet. 5xx bedeutet, dass der Server bei einer gültigen Anfrage versagt hat, was auf eure Seite hindeutet und ein stärkeres Signal für einen echten Defekt ist statt für Fehlbedienung. Ein 5xx in einem Ticket ist meist ein Grund, schneller Richtung Engineering zu eskalieren als ein 4xx, der sich häufiger mit einer Anleitung lösen lässt.

Wie schreibst du einen Bugreport, mit dem ein Entwickler arbeiten kann, ohne dir Rückfragen stellen zu müssen?

Nenne die genauen Reproduktionsschritte in der richtigen Reihenfolge, das erwartete Ergebnis, das tatsächliche Ergebnis und die Umgebung — Browser, Account, Zeitstempel, Request- oder Bestell-ID, falls relevant. Hänge den rohen Fehlertext oder einen Log-Ausschnitt an statt einer Paraphrase, denn Entwickler brauchen die exakte Zeichenkette zum Suchen. Ein sofort umsetzbarer Bericht ist der Unterschied zwischen einem Fix am selben Tag und einer Woche Hin und Her in Slack.

Wie erklärst du einem nicht-technischen Kunden einen technischen Ausfall, ohne zu lügen oder ihn mit Fachbegriffen zu überfordern?

Beschreibe den Defekt anhand dessen, was der Kunde nicht mehr tun kann, nicht anhand dessen, was intern kaputt ist — „der Checkout funktioniert gerade bei einigen Nutzern nicht" ist besser als „unser Payment-Gateway liefert Timeouts". Gib einen ehrlichen Status und einen konkreten Zeitpunkt für das nächste Update, selbst wenn das Update lautet „noch keine Neuigkeiten", denn Schweigen wirkt schlimmer als schlechte Nachrichten. Die interne Ursache lässt du komplett weg, außer man fragt danach, und selbst dann reicht ein schlichter Satz.

Ein Kunde ist wütend und droht zu kündigen. Wie führst du das Gespräch?

Lass ihn zuerst ausreden, ohne zu unterbrechen oder das Produkt sofort zu verteidigen — die meisten Eskalationen entstehen aus dem Gefühl, nicht gehört zu werden, nicht aus dem technischen Problem selbst. Bestätige konkret, was schiefgelaufen ist, statt einer allgemeinen Entschuldigung, und nenne dann einen konkreten nächsten Schritt mit Zeitrahmen statt vager Beruhigung. Wenn du es in diesem Gespräch wirklich nicht lösen kannst, sag das klar und erkläre genau, was als Nächstes passiert, statt das Gespräch versanden zu lassen.

Worauf achtest du bei einem Ticketsystem wie Zendesk oder Intercom, außer beim reinen Beantworten von Tickets?

Tags und Kategorien, die Muster später sichtbar machen — derselbe fehlkonfigurierte Webhook, der in zwanzig Tickets auftaucht, bleibt unsichtbar, wenn sie nicht einheitlich getaggt sind. Makros und Standardantworten für die wiederkehrenden 80 Prozent, was Zeit für die 20 Prozent freimacht, die wirklich Urteilsvermögen brauchen. Und eine saubere Spur interner Notizen und Eskalationen, denn ein dreimal ohne Kontext weitergereichtes Ticket kostet jeden Beteiligten Zeit für eine erneute Diagnose.

Was ist die First Response Time, und warum garantiert eine schnelle erste Antwort keine gute Lösungszeit?

Die First Response Time ist die Zeit, bis ein Kunde überhaupt von einem Menschen hört, und darauf sind die meisten SLAs aufgebaut, weil Schweigen der Grund ist, warum Kunden abwandern oder öffentlich eskalieren. Aber ein schnelles „wir schauen uns das an" ohne echten Fortschritt dahinter verzögert nur den Frust, statt ihn zu lösen, sodass Teams, die nur auf FRT optimieren, am Ende schnelle Eingangsbestätigungen und langsame, unbeobachtete Lösungen haben. Lösungszeit und CSAT müssen parallel gemessen werden, sonst wird die Kennzahl manipuliert.

Deine Warteschlange hat fünfzig offene Tickets, drei sind als dringend markiert. Wie entscheidest du, womit du zuerst anfängst?

Zuerst nach Schweregrad, nicht nach Eingangsreihenfolge — ein vollständiger Ausfall, der viele Kunden betrifft oder Zahlungen blockiert, geht immer vor dem kosmetischen Bug eines einzelnen Nutzers, egal wer zuerst geschrieben hat. Prüfe innerhalb der Kategorie „dringend", ob alle drei tatsächlich diese Schwelle erreichen oder ob jemand ein kleineres Problem als dringend markiert hat, um die Warteschlange zu überspringen — das passiert ständig und braucht eine klare Definition, auf die man sich berufen kann. Der Rest wird in SLA-Reihenfolge abgearbeitet, und wenn die Warteschlange für eine Person wirklich zu groß ist, ist das selbst ein Signal, das man melden sollte, statt es stillschweigend aufzufangen.