Um die KI-Kompetenz von Engineers zu beurteilen, muss man über die bloße Tool-Kenntnis hinausschauen und die Arbeitsgewohnheiten in den Blick nehmen: wie sie Modelle steuern, Output prüfen und reagieren, wenn das Modell mit falscher Gewissheit antwortet. Ein Entwickler, der KI bereits in der Produktion eingesetzt hat, zeigt das darin, wie er Abwägungen beschreibt, nicht nur darin, welche Tools er benennt.
Warum das übliche Vorstellungsgespräch scheitert
Die Frage „Verwenden Sie Copilot oder Cursor?“ sagt Ihnen kaum etwas. Der Einsatz dieser Tools ist mittlerweile nahezu universell. Entscheidend ist, wie ein Engineer diese Tools einsetzt, was er überprüft und an welchem Punkt er sich entscheidet, sich nicht mehr auf sie zu verlassen.
Ein standardisierter Coding-Test, der allein und unter Zeitdruck absolviert wird, liefert ebenfalls nur begrenzte Aussagekraft. Engineers, die in ihrer tatsächlichen Arbeit auf KI-Unterstützung zurückgreifen, werden diese auch während eines Tests selbstverständlich nutzen wollen. Ein Verbot misst das Falsche. Erlaubt man sie ohne strukturiertes Nachgespräch, lässt sich der Engineer nicht vom Output unterscheiden.
Worauf Sie stattdessen achten sollten
Wie sie eine kürzlich erledigte KI-gestützte Aufgabe beschreiben. Bitten Sie sie, etwas zu erläutern, das sie im letzten Monat mit KI-Hilfe entwickelt haben. Achten Sie dabei auf: welchen Prompt oder welchen Kontext sie dem Modell gegeben haben, was zurückkam und falsch oder unvollständig war, was sie geändert haben und wie sie entschieden haben, dass es auslieferungsbereit ist. Vage Antworten oder Antworten, die KI als eine Black Box behandeln, der man unkritisch vertraut hat, sind aufschlussreich.
Wie sie KI-generierten Code reviewen. Eine sinnvolle Übung besteht darin, ihnen einen kurzen Code-Abschnitt vorzulegen, den sie nicht selbst geschrieben haben und der teilweise subtile Fehler enthält. Beobachten Sie, ob sie ihn lesen oder nur überfliegen. Beobachten Sie, ob sie Probleme erkennen, die plausibel wirken, aber falsch sind. Das überschneidet sich mit normalem Code-Review-Know-how, wird aber dadurch zugespitzt, dass KI-Output auf bestimmte Weisen versagt: zuversichtliche Halluzinierung von APIs, Logik, die strukturell korrekt, aber im Verhalten falsch ist, sowie stillschweigend eingebaute Sicherheitsannahmen.
Wie sie über Kontext sprechen. Engineers, die KI gut einsetzen, haben in der Regel eine klare Vorstellung davon, was in einen Prompt gehört, wie viel Kontext einzubeziehen ist und wann ein Gespräch so weit abgedriftet ist, dass ein Neustart bessere Ergebnisse liefert. Wer sich noch nie mit context engineering befasst hat, gibt damit ein Signal. Wer dezidierte Meinungen dazu hat, ebenfalls, und das ist es wert, vertieft zu werden.
Wie sie mit einer unvollständigen Spezifikation umgehen. Legen Sie ihnen eine Aufgabenstellung vor, der absichtlich Details fehlen. Stellen sie Rückfragen, treffen sie explizite Annahmen und weisen sie darauf hin, was sie vor der Generierung von etwas Wesentlichem bestätigt haben möchten? Oder schließen sie Lücken stillschweigend und liefern selbstbewusst ein Ergebnis? KI-Tools verstärken gute wie schlechte Gewohnheiten im Umgang mit Unklarheiten.
Wo das Modell falsch lag. Fragen Sie direkt: „Schildern Sie mir eine Situation, in der das Modell Ihnen etwas geliefert hat, das korrekt wirkte, es aber nicht war.“ Wenn ihnen kein konkretes Beispiel einfällt, setzen sie KI entweder nicht ernsthaft im produktiven Betrieb ein oder sie überprüfen die Ausgaben nicht. Beides ist relevant.
Signale, die wenig aussagen
Zu wissen, welche Tools existieren, ist kein Nachweis von Kompetenz. Beschreiben zu können, was eine RAG-Pipeline oder ein MCP server ist, sagt Ihnen nicht, ob jemand eine solche aufbauen oder bewerten kann. Zertifikate und abgeschlossene Kurse in diesem Bereich haben nur begrenzten Vorhersagewert; das Feld hat sich schneller entwickelt als die meisten Lehrpläne.
Das Abschlussgespräch strukturieren
Wenn Sie während einer technischen Aufgabe den Einsatz von KI erlauben, planen Sie unmittelbar danach ein 20-minütiges Abschlussgespräch ein. Bitten Sie die Person, jeden Teil des erstellten Ergebnisses zu erläutern. Fragen Sie, was das Modell falsch gemacht hat und wie sie das festgestellt haben. Fragen Sie, was sie bei mehr Zeit anders machen würden. Dieses Vorgehen ist nützlicher als jede Hausaufgabe, die poliert und ohne Gespräch abgegeben wird.
Mehr darüber, was sich in diesem Prozess strukturell verändert hat, erfahren Sie unter was den Coding-Test abgelöst hat.
Was wir prüfen
Bei Miyagami prüfen wir jeden Engineer in zwei Assessments. Das erste läuft ohne AI-Tools und deckt Grundlagen ab, darunter Debugging, Priorisierung und Kommunikation. Im zweiten nutzen die Kandidaten ihre gewohnten AI-Tools, und wir beobachten, was sie damit tatsächlich tun: Ob sie AI-Output prüfen, bevor sie ihm vertrauen, wie sie mehrere Tools steuern und ob sie Verantwortung für Code übernehmen, den sie nicht selbst getippt haben. Risikoeinschätzung und die Wirkung des Tool-Einsatzes werden über beide Assessments hinweg bewertet. Alle Details dazu, worauf wir achten und warum, finden Sie unter So prüfen wir.
Kurze Antworten
Sollte ich KI-Tools im technischen Interview verbieten?
Das Verbot von KI-Tools misst eine Arbeitsweise, die von den meisten Produktionsumgebungen abweicht. Wer sie mit einem strukturierten Nachgespräch zulässt, erhält aussagekräftigere Signale: Sie können sehen, was der Engineer akzeptiert hat, was er erkannt hat und wie er das Ergebnis erklärt.
Was ist die einzeln nützlichste Interviewfrage zur KI-Kompetenz?
Bitten Sie den Engineer, eine kürzlich mit KI-Unterstützung entwickelte Arbeit zu beschreiben und zu erläutern, wo das Modell falsch lag. Die Qualität und Konkretheit der Antwort sagt mehr aus als jede Frage zur Tool-Kenntnissen.
Signalisiert das Wissen über KI-Tools wie RAG oder Agenten eine starke KI-Kompetenz?
Konzeptuelles Wissen ist für sich genommen ein schwaches Signal. Der aussagekräftigere Beleg ist, ob der Engineer beschreiben kann, wie er ein Tool im Produktiveinsatz genutzt hat, was schiefgelaufen ist und wie er es bemerkt hat.
