IT-Support Vorstellungsgespräch: die Fragen, die wirklich kommen

Die meisten bereiten sich auf Fachfragen vor. Im First-Level-Support kommen die aber kaum. Wer sich die tatsächlich gestellten Fragen ansieht, findet fast nur Situationen: ein verärgerter Anrufer, drei Tickets gleichzeitig, ein Problem, das du nicht lösen konntest.

Welche Fragen kommen im IT-Support-Vorstellungsgespräch wirklich?

Geht man die veröffentlichten Fragenkataloge für First-Level-Stellen durch und vergleicht sie mit Erfahrungsberichten aus IT-Foren, bleibt ein erstaunlich kleines Set übrig. Und es ist überwiegend nicht technisch.

• Situative Fragen, die klare Favoriten. Wie gehen Sie vor, wenn ein verärgerter Anrufer ein dringendes Problem hat? Wie priorisieren Sie mehrere Anfragen, die gleichzeitig reinkommen? Beschreiben Sie einen Fall, den Sie nicht sofort lösen konnten.
• Fragen zur Arbeitsweise. Wie dokumentieren Sie Ihre Fälle, und warum halten Sie das für wichtig? Wie halten Sie sich auf dem Laufenden?
• Genau eine Vorgehensfrage. Meist an einem Alltagsfall: jemand kann sich nicht anmelden, jemand kommt nicht an ein Laufwerk, etwas druckt nicht. Gefragt ist nicht die Lösung, gefragt ist dein Weg dorthin.
• Der Standardteil. Stärken, fünf Jahre, warum wir, warum die IT.

Was in den Katalogen praktisch nicht vorkommt: abgefragtes Produktwissen. Keine Versionsnummern, keine Klickpfade, kein Prüfungsstoff. Wer sich darauf vorbereitet, lernt für eine Prüfung, die nicht stattfindet.

Warum dein Fachwissen kaum abgefragt wird

Für eine Einstiegsstelle sucht niemand fertiges Wissen. Jedes Haus hat eigene Systeme, eigene Prozesse, eigene Software. Was du an Produktwissen mitbringst, ist in der Hälfte der Fälle das falsche und in zwei Jahren veraltet.

Eingearbeitet wird ohnehin. Was nicht eingearbeitet werden kann, ist die Art, wie du an ein Problem herangehst, das du noch nie gesehen hast. Ob du ruhig bleibst. Ob du fragst, bevor du rätst.

Im Support-Gespräch wird nicht geprüft, was du weißt. Geprüft wird, ob du aus einem vagen „geht nicht" ruhig einen Befund machst.

Das erklärt auch, warum die üblichen Vorbereitungslisten so wenig bringen: Sie geben Antworten auf Fragen, deren Zweck sie missverstanden haben. Dasselbe Missverständnis steckt hinter der Hoffnung, ein Schein löse das Problem — was Zertifikate am Anfang tatsächlich bringen und was nicht, ist eine eigene Rechnung.

„Ein Nutzer kann sich nicht anmelden." Wie gehst du vor?

Das ist die eine Vorgehensfrage, und an ihr entscheidet sich das Gespräch. Sie klingt technisch, ist aber eine Frage nach deiner Methode — und du kannst sie beantworten, ohne je in einem Rechenzentrum gestanden zu haben.

Die falsche Antwort ist eine Lösung: „Ich setze das Passwort zurück." Damit hast du geraten. Die richtige Antwort ist eine Reihenfolge, denn „kommt nicht rein" hat drei völlig verschiedene Ursachen, die sich für den Nutzer identisch anfühlen.

• Erst das Konto selbst. Ist es gesperrt oder deaktiviert? Das sind zwei verschiedene Dinge. Gesperrt heißt meist: zu viele Fehlversuche. Deaktiviert heißt: jemand hat es bewusst abgeschaltet.
• Dann die Gruppe. Kommt er zwar rein, aber nicht an sein Laufwerk, ist das Konto in Ordnung und die Mitgliedschaft fehlt. Rechte fließen über Gruppen, nicht über Personen.
• Zuletzt das Objekt-Recht. Erst wenn Konto und Gruppe stimmen, schaust du auf die Berechtigung am Ordner selbst.

Und dann kommt der Teil, der einen guten Kandidaten von einem sehr guten trennt. Ein Konto war gesperrt, du entsperrst es, zwanzig Minuten später ist es wieder zu. Wer jetzt erneut entsperrt, dreht sich im Kreis. Die eigentliche Frage ist, was das Konto sperrt.

In dem Fall, der mir zuletzt geschildert wurde, war es ein Diensthandy im Spind: Der Nutzer hatte sein Passwort am Freitag geändert, das Mailkonto auf dem Telefon lief noch mit dem alten und hat sich im Minutentakt angemeldet. Der Befund lautet nicht „Konto gesperrt". Er lautet: ein Gerät mit veraltetem Passwort sperrt das Konto wiederholt, Gerät gehört bereinigt.

Das ist der Unterschied zwischen einem Symptom und einer Ursache. Genau diese drei Ebenen übst du im Modul Zugriff & Rechte, und die Denkweise dahinter, aus einem „geht nicht" einen sauberen Befund zu machen, ist der Kern von Den Fehler einkreisen.

„Wie priorisierst du?" und „Was, wenn du nicht weiterkommst?"

Diese beiden kommen fast sicher, und beide haben eine bessere Antwort als die naheliegende.

Beim Priorisieren ist die schwache Antwort „der Reihe nach" und die zweitschwächste „wer am lautesten ruft". Die brauchbare Antwort fragt nach Reichweite: Betrifft es einen Menschen oder eine ganze Abteilung? Steht dadurch Arbeit still? Wer so antwortet, denkt in Betriebsauswirkung statt in Warteschlange, und das ist genau der Reflex, den man im Service-Desk sucht.

Bei „was, wenn du nicht weiterkommst" wird ein Eingeständnis erwartet, aber kein Achselzucken. Du sagst, bis wohin du geprüft hast, was du damit ausschließen konntest, und gibst genau das weiter. Was sauberes Eskalieren von bloßem Weiterreichen unterscheidet, kannst du in zwei Sätzen zeigen, und kaum ein Bewerber tut es.

Was sagst du, wenn du noch keine Erfahrung hast?

Nicht: „Ich habe zwar keine Erfahrung, aber ich lerne schnell." Das ist eine Entschuldigung, und es wird als eine gehört.

• Nenn übertragbare Praxis, nicht guten Willen. Wer an einer Rezeption oder im Lager gearbeitet hat, hat aufgebrachte Menschen beruhigt, Vorgänge dokumentiert, unter Zeitdruck priorisiert. Das sind keine Ersatzqualifikationen, das ist der halbe Job. Welche Voraussetzungen für den IT-Quereinstieg tatsächlich zählen, überschneidet sich stark mit dem, was hier gefragt wird.
• Sag, was du geübt hast, nicht was du gesehen hast. „Ich habe 40 Stunden Videos geschaut" ist wertlos. „Ich habe Anmelde- und Rechteprobleme an gestellten Fällen durchgespielt und kann dir zeigen, wie ich vorgehe" ist eine Aussage.
• Sprich einen Bruch im Lebenslauf selbst an. Wer ihn aussitzt, macht ihn größer. Wie sich ein abgebrochenes Studium im Gespräch sauber einordnen lässt, ist erlernbar.

Welche Rückfragen solltest du selbst stellen?

Am Ende bekommst du Zeit für eigene Fragen. Wer keine hat, hinterlässt eine Lücke. Diese zeigen, dass du den Alltag im Blick hast und nicht nur die Stelle.

• Wie viele Tickets laufen pro Tag auf einen Mitarbeiter? Sagt mehr über die Arbeitsrealität als jede Stellenbeschreibung.
• Wie ist die Übergabe an die zweite Stufe geregelt? Zeigt, dass du in Prozessen denkst statt in Einzelfällen.
• Wer arbeitet ein, und wie lange? Völlig legitim, niemand nimmt das negativ auf.
• Wie sind Schichten und Rufbereitschaft geregelt? Gehört zusammen mit der Frage, was im First-Level an Aufgaben und Gehalt anliegt, vor die Unterschrift statt danach.

Was am Ende den Ausschlag gibt

Man stellt dich nicht ein, weil du die richtigen Antworten kanntest. Man stellt dich ein, weil dein Gegenüber sich vorstellen kann, dich am Montag ans Telefon zu setzen, ohne dass etwas eskaliert.

Dafür brauchst du keinen Schein und keine drei Jahre Erfahrung. Du brauchst ein Vorgehen, das du erklären kannst, weil du es tatsächlich einmal gemacht hast. Den Unterschied zwischen jemandem, der über Fehlersuche gelesen hat, und jemandem, der sie durchgeführt hat, hört man in zwei Sätzen.