Was wird in IT-Support-Vorstellungsgesprächen wirklich geprüft?

Wer tatsächlich im Raum sitzt

Bei den meisten First-Line- oder Second-Line-Support-Stellen treffen Sie keinen professionellen Interviewer. Sie treffen den Teamleiter des Service Desk oder den IT-Manager, der derzeit die Tickets besitzt, die Sie übernehmen würden, manchmal zusammen mit einem aktiven Techniker, der die technischen Fragen stellt, weil er derjenige ist, der Ihren Lösungen vertrauen muss. In kleineren Unternehmen kann dies der einzige Systemadministrator sein, der Sie teilweise interviewt, weil er erschöpft ist und jemanden möchte, der Tickets von seinem Schreibtisch nimmt, ohne neue zu erzeugen.

Oft gibt es zunächst ein kurzes HR- oder Recruiter-Screening, hauptsächlich um Gehaltsvorstellungen, Arbeitserlaubnis und Kündigungsfrist zu prüfen. Dieses Gespräch testet nicht Ihr technisches Urteilsvermögen, und Sie sollten nicht zu viel hineininterpretieren. Das Interview, das die Entscheidung trifft, ist das mit der Person, die in Ihrer Nähe sitzen wird.

Die praktische Prüfung und was sie tatsächlich überprüft

Viele Support-Techniker-Interviews enthalten etwas Praktisches, weil über Troubleshooting zu sprechen und es zu tun unterschiedliche Fähigkeiten sind. Wie das aussieht, variiert je nach Arbeitgeber, aber gängige Versionen sind:

• Ein Laptop oder Desktop vor Ihnen mit einem eingebauten Fehler — keine Netzwerkverbindung, ein beschädigtes Benutzerprofil, ein Drucker, der nicht in die Warteschlange geht, ein Rechner, der nicht über den Anmeldebildschirm hinauskommt — und Sie werden gebeten, ihn zu finden und zu beheben, während Sie Ihre Schritte erläutern.
• Ein Whiteboard- oder mündliches Szenario: "Ein Benutzer ruft an und sagt, sein PC kann nicht auf das freigegebene Laufwerk zugreifen, erklären Sie mir, was Sie tun."
• Gelegentlich ein kurzer schriftlicher oder Online-Test zu Themen wie Subnetting, gängigen Port-Nummern oder dem Lesen einer ipconfig /all-Ausgabe und dem Erkennen, was daran falsch ist.
• Manchmal ein Probeanruf oder Rollenspiel, bei dem jemand einen frustrierten nicht-technischen Benutzer spielt und Sie nützliche Informationen aus ihm herausholen und eine Lösung ohne Fachjargon erklären müssen.

Was sie überprüfen, ist nicht, ob Sie sofort auf die richtige Antwort kommen. Es geht darum, ob Sie eine Methode haben. Ein Netzwerkfehler hat beispielsweise eine ziemlich standardmäßige Ausschlussreihenfolge: Ist das Kabel eingesteckt, ist der Adapter aktiviert, zeigt ipconfig eine gültige IP oder eine APIPA-Adresse (169.254.x.x, was Ihnen sagt, dass DHCP fehlgeschlagen ist), können Sie das Gateway anpingen, können Sie per IP, aber nicht per Name pingen (was auf DNS hinweist), können Sie extern, aber nicht intern auflösen (was auf einen bestimmten DNS-Server oder ein VPN-Split-Tunnel-Problem hinweist). Ein Kandidat, der dort beginnt, laut, zeigt etwas, das ein Kandidat, der sagt "Ich würde es neu starten, dann den Netzwerktreiber neu installieren, dann neu abbilden", nicht zeigt. Die zweite Antwort könnte schließlich funktionieren. Es ist keine Diagnose, es ist eine Abfolge von Vermutungen, und jeder, der einen Service Desk geleitet hat, kann den Unterschied in unter einer Minute erkennen.

Die Fragen, die tatsächlich Kompetenz prüfen

Eine Handvoll Fragen tauchen immer wieder auf, und sie leisten mehr Arbeit, als sie klingen.

"Erklären Sie mir, wie Sie [X] troubleshooten würden." Das ist die Kernfrage. Sie wollen nicht das Ziel, sie wollen die Reihenfolge der Operationen und die Begründung an jeder Verzweigung. Eine starke Antwort grenzt das Problem systematisch ein — Hardware versus Software, lokal versus Netzwerk, ein Benutzer versus viele — und sagt, was jeder Test ihnen sagen würde, bevor sie ihn durchführen. Eine schwache Antwort springt direkt zur Lösung, die letztes Mal bei etwas Ähnlichem funktioniert hat.

"Erzählen Sie mir von einem Fall, bei dem Ihre erste Lösung nicht funktioniert hat." Damit werden zwei Dinge überprüft: ob Sie Tickets tatsächlich selbstständig bearbeiten, anstatt immer zu eskalieren, und ob Sie dokumentieren und neu testen, anstatt zufällige Dinge auszuprobieren, bis eines funktioniert. Wenn Ihre Antwort keine Erwähnung der Überprüfung des Ereignisprotokolls, des erneuten Testens nach jeder Änderung oder der Aktualisierung des Tickets mit dem, was Sie ausgeschlossen haben, enthält, ist das eine Lücke, die sie bemerken werden.

"Wie priorisieren Sie Ihre Warteschlange?" Echte Service Desks laufen nach einer Version von Priorität und SLA — ein gesperrter VIP-Benutzer ist nicht dasselbe Ticket wie ein Druckerstau, und ein P1-Ausfall, der eine ganze Etage betrifft, hat Vorrang vor beiden. Wenn Sie über Prioritätsstufen, Auswirkung versus Dringlichkeit oder darüber sprechen, wie Sie mit einem P1 umgehen würden, das eintrifft, während Sie mitten in der Behebung von etwas anderem sind, antworten Sie aus Erfahrung. Wenn Sie sagen "Ich arbeite sie einfach der Reihe nach ab", sagt das ihnen, dass Sie entweder nicht in einem Ticketing-System mit echten SLAs gearbeitet haben oder nicht darüber nachgedacht haben.

"Erklären Sie [einen technischen Fehler] jemandem, der noch nie einen Computer benutzt hat." Das ist keine Soft-Skills-Füllerfrage. Support-Techniker verbringen den größten Teil ihres Tages mit Übersetzen, und jemand, der es im Interviewraum nicht kann, unter keinerlei Druck, wird es in einem Anruf mit einem verärgerten Benutzer um 16:45 Uhr nicht gut machen. Achten Sie auf Kandidaten, die nach einer Analogie greifen und sie kurz halten, versus solche, die das Vokabular vereinfachen, aber dieselbe langatmige Erklärung beibehalten.

Verzeichnis- und Zugriffsfragen. Je nach Umgebung erwarten Sie etwas Konkretes: Wie entsperren Sie ein Active Directory-Konto, was ist der Unterschied zwischen dem Zurücksetzen eines Passworts und dem Erzwingen einer Änderung bei der nächsten Anmeldung, wie würden Sie einen Benutzer zu einer Sicherheitsgruppe versus einer Verteilergruppe hinzufügen, was überprüfen Sie, bevor Sie jemandem erhöhte Zugriffsrechte gewähren, der danach gefragt hat. Das sind keine Trickfragen. Sie überprüfen, ob Sie tatsächlich AD-Benutzer und -Computer oder Intune oder was auch immer der Betrieb verwendet hat, anstatt nur darüber gelesen zu haben.

Eine Sicherheitsfrage, fast immer. Etwas wie "Ein Benutzer schreibt Ihnen eine E-Mail und sagt, er habe auf einen Link geklickt und jetzt verhalte sich sein Rechner seltsam, was tun Sie zuerst?" Sie wollen Isolation vor Untersuchung — vom Netzwerk trennen, noch nicht neu starten, falls forensische Nachverfolgung möglich ist, nach oben melden, nicht einfach einen Virenscan durchführen und weitermachen. Und irgendwo werden sie prüfen, ob Sie jemals nach Ihrem Admin-Passwort von jemandem gefragt wurden, der behauptete, ein Manager in Eile zu sein, und was Sie getan haben.

Wie eine oberflächliche Antwort klingt

Leute, die einstellen, können normalerweise innerhalb von ein oder zwei Sätzen erkennen, wann eine Antwort auswendig gelernt und nicht erlebt ist. Ein paar Muster tauchen häufig auf:

• Die Lösung nennen ohne die Diagnose. "Ich würde es neu abbilden" als erste Zeile einer Antwort, ohne Erwähnung dessen, was Ihnen sagen würde, dass eine Neuabbildung tatsächlich erforderlich ist.
• Das Ticketing-System als Papierkram behandeln statt als Aufzeichnung. Wenn Sie nicht sagen können, was Sie in die Ticket-Notizen schreiben würden, oder Sie beschreiben, wie Sie Tickets schließen, ohne die Lösung mit dem Benutzer zu bestätigen, wird das bemerkt.
• Zertifizierungsinhalte rezitieren ohne angehängte Geschichte. Zu wissen, dass DNS auf Port 53 läuft, ist nicht dasselbe wie tatsächlich ein DNS-Problem verfolgt zu haben. Wenn Sie CompTIA A+ oder Network+ oder ein ITIL-Foundation-Zertifikat halten, erwarten Sie, dass es zur Sprache kommt — aber der Interviewer weiß bereits, dass viele Leute diese Prüfungen bestehen, ohne etwas reparieren zu können. Sie werden eine Folgefrage stellen, die erfordert, dass Sie die Sache tatsächlich getan haben, nicht nur studiert.
• Vage Verantwortungssprache. "Wir haben es behoben" oder "das Team hat es gelöst", wenn gefragt wird, was Sie persönlich getan haben.
• Keine Erwähnung des Benutzers überhaupt. Eine technisch korrekte Antwort, die nie die Rückmeldung bei der Person erwähnt, die das Ticket erstellt hat, liest sich als jemand, der Maschinen repariert, nicht die Probleme von Menschen.

Was Sie tatsächlich vorbereiten sollten

Haben Sie zwei oder drei echte Tickets bereit, um sie im Detail zu besprechen — nicht der interessante einmal-im-Jahr-Ausfall, sondern gewöhnliche: ein Drucker, der nicht in die Warteschlange ging, ein VPN-Abbruch für einen Benutzer, eine Kontosperrung, die sich als zwischengespeicherte Anmeldeinformationen auf einem Telefon herausstellte. Seien Sie bereit, unaufgefordert zu sagen, was Sie überprüft haben und in welcher Reihenfolge, und was Sie als Nächstes getan hätten, wenn das Erste nicht funktioniert hätte. Wenn Ihr aktueller oder letzter Job einen bestimmten Stack verwendet — ServiceNow, Zendesk, Intune, SCCM, eine bestimmte AD-Struktur — kennen Sie die tatsächlichen Begriffe, die Sie dort für Dinge verwenden, weil vage Beschreibung sich genauso liest wie Unerfahrenheit, auch wenn sie es nicht ist. Und wenn Sie nach einem Szenario gefragt werden, das Sie wirklich nicht bearbeitet haben, sagen Sie es und argumentieren Sie trotzdem laut durch; das ist näher daran, was der Job tatsächlich ist, als jede Antwort richtig zu bekommen.

Wenn Sie Bewerbungen versenden und keine Rückmeldung erhalten, bevor Sie überhaupt zu diesem Stadium kommen, liest jobmarket.pro die Anzeige vollständig, gleicht sie mit Ihrer tatsächlichen Erfahrung ab und erstellt die Bewerbung daraus, anstatt aus einem generischen Lebenslauf.