Bildunterschrift zum Beitragsbild: Nicht die perfekte Lösung zählt, sondern ob Kandidat:innen technische Entscheidungen nachvollziehbar erklären, prüfen und weiterentwickeln können.
Fachmagazin IT-Recruiting · Technische Auswahl
Der Code läuft. Die Präsentation ist sauber. Dann fragt der Engineering Lead, warum die Lösung unter Last kippen könnte – und das Gespräch wird plötzlich dünn. Seit generative KI brauchbaren Code, Architekturvorschläge und ausformulierte Antworten liefert, reicht ein fertiges Ergebnis als Eignungsnachweis noch weniger als früher. Wer IT-Kandidaten technisch prüfen will, muss Arbeitsweise, Urteilskraft und Verantwortung sichtbar machen.
Mit einer dreistufigen Prüfung: Zuerst wird konkrete Erfahrung plausibilisiert, dann bearbeitet die Person eine kleine arbeitsnahe Aufgabe unter transparenten KI-Regeln, anschließend verändert der Fachbereich eine Annahme und bespricht die Folgen. Bewertet werden nicht nur Ergebnis und Syntax, sondern Problemverständnis, fachliche Entscheidungen, Prüfverhalten, Grenzen und Kommunikation. Ein KI-Verbot, ein Detektor oder ein unangekündigter Tricktest ersetzt diese Struktur nicht.
Die Frage trifft einen realen Engpass. Laut der repräsentativen Bitkom-Erhebung zum IT-Arbeitsmarkt 2026 berichten 33 Prozent der befragten Unternehmen, Bewerber:innen erfüllten Anforderungen an aktuelle Technologiekenntnisse nicht. Gleichzeitig erhalten 31 Prozent kaum oder gar keine Bewerbungen auf offene IT-Stellen. Unternehmen müssen deshalb zwei Fehler vermeiden: formale Passung mit echter technischer Tiefe verwechseln – und gute Profile mit überlangen oder fachfremden Tests verlieren.
KI verschärft diese Aufgabe, sie verursacht sie nicht. Schon vor ChatGPT konnten Take-home-Aufgaben gemeinsam mit Freunden gelöst, aus Repositories kopiert oder an Dienstleister gegeben werden. Neu ist, wie schnell eine plausible Lösung entsteht. Im globalen HackerRank Developer Skills Report 2025 bevorzugen 66 Prozent der Entwickler:innen praktische Coding-Aufgaben; zugleich halten es 73 Prozent für unfair, gegen KI-unterstützte Kandidat:innen zu verlieren. Die Studie umfasst 13.732 Entwickler:innen, Engineering Manager, Recruiter:innen, Führungskräfte und Studierende aus 102 Ländern. Sie ist kein Deutschlandwert, aber ein deutlicher Hinweis auf das Konstruktionsproblem technischer Auswahl.
Ein technisches Interview soll nicht beweisen, dass jemand ohne Hilfsmittel tippen kann. Es soll zeigen, ob diese Person mit realen Hilfsmitteln verlässlich gute Entscheidungen trifft.
Leitgedanke für HR und IT-Fachbereich
Warum klassische Coding-Tests im KI-Zeitalter falsche Sicherheit geben
Ein standardisierter Algorithmustest kann Grundlagen sichtbar machen. Er sagt aber wenig darüber, wie ein Platform Engineer einen instabilen Deployment-Prozess eingrenzt, eine SAP-Beraterin widersprüchliche Prozessanforderungen klärt oder ein Security Architect Risiken priorisiert. Je weiter die Aufgabe vom Arbeitsalltag entfernt ist, desto größer wird die Gefahr, Testtraining statt Rollenpassung zu messen.
Die Herkunft bleibt unklar
Ein funktionierender Codeblock zeigt nicht, ob die Person das Problem verstanden, die Lösung selbst entwickelt oder einen Vorschlag nur übernommen hat.
Der Test entfernt den Arbeitsalltag
Wer im Job Dokumentation, Suchmaschinen, Repositories und KI nutzen darf, wird durch ein pauschales Verbot auf eine künstliche Nebendisziplin geprüft.
Ohne Beobachtung fehlt das Signal
„Alle Hilfsmittel erlaubt“ ist nur aussagekräftig, wenn sichtbar wird, wie Vorschläge geprüft, Fehler erkannt und Entscheidungen begründet werden.
Rollen werden gleichgemacht
Software Engineering, Cloud Operations, Cybersecurity, SAP und IT-Führung brauchen unterschiedliche Aufgaben und Bewertungskriterien.
Eine seriöse Antwort liegt deshalb weder im vollständigen KI-Verbot noch in blindem Vertrauen. Selbst OpenAI beschreibt in seinem Interviewleitfaden, dass die Regeln je nach Format variieren: Manche Interviews erlauben KI ausdrücklich, andere prüfen bewusst eigenständiges Problemlösen ohne KI. Die Regel muss vorher transparent sein. Kandidat:innen müssen wissen, welches Verhalten erwartet und was tatsächlich bewertet wird.
IT-Kandidaten technisch prüfen: das Drei-Ebenen-Modell
Ein belastbarer Prozess kombiniert drei Informationsquellen. Keine davon muss lang sein. Zusammen machen sie es jedoch deutlich schwerer, eine geliehene Lösung als eigene Arbeitsweise zu präsentieren.
Erfahrung plausibilisieren
Die Person beschreibt eine konkrete Situation aus einem eigenen Projekt: Ausgangslage, Größenordnung, eigener Anteil, relevante Einschränkungen und eine Entscheidung, die sie selbst getroffen hat. Der Fachbereich fragt nach Spuren echter Verantwortung: Was ging schief? Welche Alternative wurde verworfen? Wer musste überzeugt werden? Vertrauliche Kundendaten oder interner Code werden nicht verlangt.
Arbeitsprobe beobachten
Eine kleine, rollenrelevante Aufgabe wird in 30 bis 45 Minuten bearbeitet. KI-Nutzung ist entweder klar erlaubt oder für einen begründeten Teil klar ausgeschlossen. Bei erlaubter Nutzung zählt, welche Fragen gestellt, welche Vorschläge verworfen und welche Prüfungen vorgenommen werden. Das Ziel ist kein Produktionsartefakt, sondern ein beobachtbarer Denk- und Arbeitsprozess.
Eine Annahme verändern
Nach der ersten Lösung ändert die interviewende Person den Kontext: Das Datenvolumen verzehnfacht sich, eine Schnittstelle fällt aus, ein Audit verlangt Nachvollziehbarkeit oder das Team kann die vorgeschlagene Technologie nicht betreiben. Wer die Lösung verstanden hat, kann Folgen erklären, Prioritäten neu setzen und Grenzen benennen.
Der dritte Schritt ist oft ergiebiger als eine zusätzliche Stunde Testzeit. Eine auswendig gelernte oder generierte Musterlösung ist auf den Ausgangsfall optimiert. Berufliche Kompetenz zeigt sich dort, wo die Vorlage nicht mehr passt.
Was je nach IT-Rolle geprüft werden sollte
„Technisch stark“ ist kein einheitliches Merkmal. Die Prüfaufgabe muss zur tatsächlichen Verantwortung passen. Ein CISO wird nicht durch denselben Test besser beurteilt wie ein Backend Engineer; ein SAP-Prozessprofil nicht durch eine allgemeine Coding-Challenge.
| Rolle | Arbeitsnahe Aufgabe | Gutes Signal | Schwaches Signal |
|---|---|---|---|
| Software Engineering | Kleine bestehende Funktion verstehen, Fehler eingrenzen, Änderung planen und Tests ergänzen | Fragt nach Randfällen, erklärt Trade-offs, prüft KI-Vorschläge und verbessert Lesbarkeit | Produziert viel Code, kann aber Datenfluss, Fehlerbild oder Teststrategie nicht erklären |
| Cloud, Platform, SRE | Incident-Szenario mit Metriken, Logs und unvollständigen Informationen strukturieren | Trennt Symptom und Ursache, priorisiert Betriebssicherheit, denkt an Rollback und Observability | Nennt Tools und Services, ohne Abhängigkeiten oder Schadensbegrenzung zu ordnen |
| Cybersecurity | Risikoszenario bewerten und zwischen Sofortmaßnahme, nachhaltiger Kontrolle und Rest-Risiko unterscheiden | Verbindet technische Tiefe mit Geschäftsfolgen, Verantwortlichkeiten und Nachweisbarkeit | Verspricht absolute Sicherheit oder zählt Frameworks ohne Priorisierung auf |
| Data und AI Engineering | Eine fehleranfällige Pipeline oder einen Modell-Use-Case auf Datenqualität, Betrieb und Monitoring prüfen | Fragt nach Datenherkunft, Drift, Kosten, Latenz, Evaluation und Fehlerfolgen | Springt direkt zum Modell oder Tool, ohne Daten- und Betriebsrealität zu klären |
| SAP und Enterprise Applications | Prozessänderung mit Schnittstellen, Customizing, Berechtigungen und Fachbereichsfolgen einordnen | Unterscheidet Prozessownership, Konfiguration, Entwicklung und Cutover-Risiken | Bleibt bei Modulbegriffen, ohne Projektphase und eigenen Entscheidungsanteil zu präzisieren |
| IT-Leitung und Architektur | Zwei plausible Zielbilder unter Budget-, Risiko- und Teamrestriktionen abwägen | Macht Annahmen sichtbar, priorisiert, benennt Informationslücken und schafft Entscheidungsfähigkeit | Liefert ein perfektes Schaubild, aber keine tragfähige Reihenfolge oder Verantwortungslogik |
Eine faire KI-Regel für das technische Interview
Die KI-Regel gehört in die Einladung, nicht als Überraschung in den Termin. Eine klare Formulierung kann lauten: „Sie dürfen Dokumentation, Suchmaschinen und ein KI-Assistenzsystem nutzen. Bitte machen Sie kenntlich, wofür Sie es einsetzen, und prüfen Sie Vorschläge so, wie Sie es im Arbeitsalltag tun würden.“ Wenn ein kurzer Abschnitt ohne KI bearbeitet werden soll, wird auch das erklärt: welches Grundlagenverständnis geprüft wird, wie lange der Teil dauert und warum er für die Rolle relevant ist.
- Erlaubte Hilfsmittel nennen: Browser, Dokumentation, IDE, Repository, KI-Assistent und eigene Notizen.
- Beobachtbares Verhalten definieren: Fragen stellen, Annahmen markieren, Quellen oder Vorschläge prüfen, Fehler entdecken und Lösung verändern.
- Daten schützen: Keine internen Quelltexte, Kundendaten oder vertraulichen Aufgaben in öffentliche KI-Dienste kopieren.
- Gleiche Bedingungen schaffen: Kandidat:innen derselben Rolle erhalten denselben Zeitrahmen, dieselben Kerninformationen und dieselbe Bewertungsrubrik.
- Barrieren vermeiden: Das Format darf nicht voraussetzen, dass jemand ein bestimmtes kostenpflichtiges Tool oder eine ungewöhnliche Testplattform beherrscht.
Keine Abkürzung: Automatische KI-Erkennung sollte nicht darüber entscheiden, ob eine Leistung „echt“ ist. Solche Systeme liefern Wahrscheinlichkeiten, keinen belastbaren Urheberschaftsnachweis. Besser ist ein Prozess, in dem Kandidat:innen ihre Arbeit nachvollziehbar erklären und auf Veränderungen reagieren.
Aktuelle Produktentwicklung im Assessment-Markt zeigt, wohin die Praxis geht. HackerRank beschreibt in seinen Release Notes vom Juli 2026 Prüfoberflächen, die nicht nur das Ergebnis, sondern Planung, Änderungen und den Umgang mit KI sichtbar machen sollen. Das ist eine Anbieteraussage, keine unabhängige Wirksamkeitsstudie. Als Marktsignal ist sie dennoch relevant: Technische Auswahl verschiebt sich vom abgeschlossenen Code hin zum beobachtbaren Arbeitsprozess.
Die Bewertungsrubrik vor dem ersten Gespräch bauen
Die beste Aufgabe hilft wenig, wenn jede interviewende Person nach einem anderen Bauchgefühl bewertet. Sechs Kriterien reichen für viele Fachrollen. Jedes Kriterium erhält vorab beobachtbare Anker – zum Beispiel „fragt nach fehlenden Randbedingungen“, „kann zwei Alternativen mit Folgen vergleichen“ oder „prüft einen KI-Vorschlag durch Test, Dokumentation oder Gegenbeispiel“.
Wird zuerst verstanden oder sofort produziert?
Gute Kandidat:innen klären Ziel, Grenzen und fehlende Informationen, bevor sie eine Lösung festschreiben.
Ist Verantwortung hinter Begriffen erkennbar?
Bewertet werden Zusammenhänge, Größenordnungen und Folgen – nicht die Menge genannter Technologien.
Kann die Person zwischen plausiblen Wegen wählen?
Ein belastbares Urteil nennt Kriterien, Unsicherheit und Bedingungen, unter denen eine andere Option besser wäre.
Wie wird mit KI und Quellen umgegangen?
Starke Profile übernehmen Vorschläge nicht still. Sie verifizieren, testen, korrigieren und erklären Grenzen.
Wird Denken für andere anschlussfähig?
Die Person kann technische Entscheidungen so erklären, dass Team, Fachbereich und Betrieb damit weiterarbeiten können.
Was passiert nach einem Hinweis?
Nicht der erste Fehler ist das Problem. Relevant ist, ob Feedback aufgenommen und die Lösung nachvollziehbar verbessert wird.
Eine Punktzahl allein genügt nicht. Ergänzen Sie pro Kriterium ein bis zwei Beobachtungen und markieren Sie offene Fragen. So kann das Entscheidungsgremium später unterscheiden, ob ein Risiko belegt, nur vermutet oder im Prozess gar nicht geprüft wurde.
Ein kompakter Ablauf für 60 Minuten
Minuten: Kontext und Regeln
Aufgabe, Rolle der Interviewenden, erlaubte Hilfsmittel und Bewertung werden erklärt. Die Person darf Verständnisfragen stellen.
Minuten: echte Erfahrung
Ein vergleichbares Projekt wird anhand von Ausgangslage, eigenem Anteil, Entscheidung und Ergebnis plausibilisiert.
Minuten: Arbeitsprobe
Die Person strukturiert oder bearbeitet eine kleine Aufgabe und legt den Umgang mit Hilfsmitteln offen.
Minuten: veränderte Annahme
Der Fachbereich verändert einen relevanten Parameter. Kandidat:in und Interviewende besprechen Folgen und Alternativen.
Minuten: Rückfragen
Die Person erhält Raum, Team, Systemlandschaft und Auftrag zu prüfen. Auch diese Fragen sind ein fachliches Signal.
Für besonders seniorige oder geschäftskritische Rollen kann eine zweite Runde nötig sein. Dann sollte sie eine andere Unsicherheit klären – etwa Führung, Stakeholdersteuerung oder Architekturverantwortung – und nicht denselben Test mit neuen Personen wiederholen.
Wann externe Vorqualifizierung hilft – und wo ihre Grenze liegt
Recruiting kann vor dem Fachinterview viel klären: Systemkontext, Projektgröße, eigener Anteil, Motivation, Verfügbarkeit und die Plausibilität zentraler Rollenstationen. Bei anspruchsvollen IT-Profilen braucht diese Vorqualifizierung technische Sprachfähigkeit. Sonst werden Keywords abgefragt, während die eigentliche Verantwortung unsichtbar bleibt.
Die finale Tiefenprüfung gehört dennoch in den Fachbereich. Eine spezialisierte IT-Personalberatung kann Suchprofil, Kandidatensignale und Vorqualifizierungsfragen so vorbereiten, dass Engineering, Security, SAP oder IT-Leitung ihre knappe Interviewzeit auf die entscheidenden Risiken konzentrieren. Sie sollte aber keine technische Entscheidung vortäuschen, die nur das zukünftige Team belastbar treffen kann.
FAQ: IT-Kandidaten technisch prüfen
Sollten Kandidat:innen im Coding-Test KI verwenden dürfen?
Wenn KI im späteren Arbeitsalltag erlaubt ist, sollte mindestens ein Teil der Prüfung den verantwortlichen Umgang damit zeigen. Ein kurzer KI-freier Abschnitt kann ergänzend sinnvoll sein, wenn konkretes Grundlagenwissen für Betrieb, Sicherheit oder Fehleranalyse unverzichtbar ist. Beide Regeln müssen vorab transparent sein.
Wie erkennt man, ob eine Lösung wirklich verstanden wurde?
Bitten Sie die Person, Annahmen, Alternativen und Prüfungen zu erklären. Ändern Sie anschließend eine relevante Randbedingung. Wer die Lösung verstanden hat, kann Folgen ableiten, Fehler finden und den Ansatz anpassen – auch wenn die erste Fassung mit KI-Unterstützung entstanden ist.
Sind Take-home-Aufgaben noch sinnvoll?
Ja, wenn sie klein, arbeitsnah und zeitlich klar begrenzt sind. Das Ergebnis sollte in einem anschließenden Gespräch vertieft werden. Unbezahlte Aufgaben mit echtem Unternehmensnutzen oder mehrstündige Projekte schrecken gute Profile ab und liefern trotz ihres Umfangs keinen sicheren Urheberschaftsnachweis.
Wie lang darf eine technische Prüfung dauern?
Für eine erste Tiefenprüfung reichen häufig 45 bis 60 Minuten. Zusätzliche Aufgaben brauchen einen klaren, neuen Prüfzweck. Dauer allein erhöht die Aussagekraft nicht; Rollenbezug, gleiche Bedingungen und eine vorbereitete Bewertungsrubrik tun es.
Kann HR technische IT-Kompetenz allein prüfen?
HR kann Erfahrung plausibilisieren, Rahmenbedingungen klären und rollenbezogene Vorfragen stellen. Technische Tiefe und die Tragfähigkeit von Architektur-, Code-, Security- oder Betriebsentscheidungen sollte der zuständige Fachbereich bewerten. Die Aufgabenverteilung gehört vor dem ersten Gespräch festgelegt.
Was ist bei IT-Führungskräften anders?
Bei IT-Leitung, CISO, VP Engineering oder Architekturführung sollte keine kleinteilige Coding-Leistung im Mittelpunkt stehen. Prüfen Sie, wie die Person technische Risiken priorisiert, Entscheidungen unter Unsicherheit trifft, Teams einbindet und zwischen Geschäft, Architektur und Betrieb übersetzt.
Ihre technische Auswahl liefert noch zu wenig Klarheit?
Wir übersetzen Rolle, Kandidatensignale und Vorqualifizierung in einen belastbaren Suchprozess. Ihr Fachbereich erhält bessere Gesprächsgrundlagen – und behält die technische Entscheidung dort, wo sie hingehört.
