Junior Technical Support Engineer — Technical support engineer interviewfragen

Was prüfst du zuerst, wenn sich ein Nutzer nicht einloggen kann?

Ob der Fehler bei der Eingabe der Zugangsdaten, direkt danach oder schon vor dem Laden der Seite auftritt, denn das deutet auf völlig unterschiedliche Ebenen hin — Tippfehler oder Reset-Problem, Session- oder 2FA-Problem, oder ein größerer Ausfall. Prüfe, ob es einen oder mehrere Nutzer betrifft, denn ein einzelner Account deutet auf den Account selbst hin, ein Cluster auf euren Dienst. Erst nach dieser Eingrenzung schaust du dir Account-Status, Passwortstatus oder Server-Logs an.

Was bedeutet ein 404-Fehler für einen Kunden, in einfachen Worten?

Die Seite oder Ressource, die er angefordert hat, existiert unter dieser Adresse nicht — sie wurde verschoben, gelöscht, oder der verwendete Link war falsch. Es lohnt sich zu prüfen, ob es ein defekter Link ist, den du beheben kannst, eine Ressource, die legitim entfernt wurde, oder eine URL, die der Kunde falsch eingegeben hat, denn Lösung und Erklärung unterscheiden sich in jedem Fall.

Ein Kunde sagt „die App ist langsam". Welche Fragen stellst du, bevor du irgendetwas tust?

Wann es begonnen hat, ob es dauerhaft ist oder zu bestimmten Momenten auftritt, ob es eine bestimmte Aktion betrifft oder alles, und ob es auf anderen Geräten oder Netzwerken auftritt. „Langsam" kann eine fünf Sekunden lange Ladezeit bedeuten, einen Spinner, der nie fertig wird, oder eine tatsächlich normale Leistung, die sich für diesen Nutzer nur langsam anfühlt — und jeder Fall braucht einen anderen nächsten Schritt.

Was ist ein Knowledge-Base-Artikel, und wann solltest du einen schreiben, statt einfach das Ticket zu beantworten?

Es ist eine Self-Service-Antwort auf eine Frage, die Kunden wiederholt stellen, so geschrieben, dass jemand sein Problem selbst lösen kann, ohne ein Ticket zu öffnen. Wenn du eine fast identische Frage drei oder mehr Mal beantwortet hast, lohnt sich ein Artikel, denn jeder zukünftige Kunde, der ihn findet, spart ein Ticket, statt eins zu erzeugen.

Wie entscheidest du, wann du ein Ticket eskalierst, statt es selbst zu lösen?

Wenn Zugriff, Codeänderungen oder Wissen nötig sind, das du nicht hast — zum Beispiel eine Datenkorrektur, die nur das Engineering ausführen kann, oder ein Bug, der einen echten Fix statt eines Workarounds braucht. Eskaliere mit allem bereits Gesammelten im Anhang statt nur „bitte helft", damit die nächste Person nicht von vorn anfangen muss.

Welchen Ton verwendest du in einer schriftlichen Support-Antwort, und was solltest du vermeiden?

Klar, direkt und freundlich, ohne künstlich fröhlich zu wirken — sag, was du gefunden hast, was du dagegen tust und wann sich der Kunde wieder meldet. Vermeide relativierende Formulierungen, die klingen, als würdest du deiner eigenen Antwort nicht trauen, und Fachjargon, den der Kunde selbst nie benutzt hat; spiegle lieber sein Vokabular, statt es mitten im Ticket zu korrigieren.