Der klassische Coding-Test, ein zeitlich begrenztes Algorithmus-Rätsel in einem leeren Editor, verliert an Bedeutung. Die meisten Teams, die ihn ersetzen, nutzen aufgabenbasierte technische Bewertungen, Code-Walkthroughs oder Live-Sitzungen, bei denen Kandidaten mit ihren üblichen Werkzeugen arbeiten, einschließlich KI-Assistenten.
Warum der Algorithmus-Test nicht mehr funktioniert
Das klassische Whiteboard- oder HackerRank-Format war schon immer ein Näherungswert. Es maß eine bestimmte Art von Leistung, nämlich das Lösen eingeschränkter Rätsel unter künstlichem Druck, nicht aber das umfassendere Urteilsvermögen, das in einer echten Codebasis gefragt ist. Dieser Näherungswert war bereits vor dem Aufkommen von KI-Tools unzulänglich. Heute ist er noch schwerer zu rechtfertigen.
Ein Kandidat, der Dynamic-Programming-Muster auswendig kennt, ist nicht zwangsläufig ein besserer Entwickler als jemand, der das nicht tut. Und ein Kandidat, der eine binäre Suche aus dem Gedächtnis schreiben kann, sagt nichts darüber aus, ob er übernommenen Code lesen, einen subtilen, von einem Modell generierten Fehler erkennen oder bei einem unvollständigen Ticket sinnvolle Entscheidungen treffen kann.
Das Aufkommen leistungsfähiger KI-Coding-Assistenten hat die Lücke weiter vergrößert. Entwickler, die täglich auf solche Tools setzen und sie gut einsetzen, sind beim ungestützten Lösen von Rätseln möglicherweise langsamer, in der Praxis jedoch schneller und zuverlässiger. Das Testen des Ersteren benachteiligt das Letztere.
Was Teams stattdessen verwenden
Es gibt keinen einheitlichen Ersatz. Verbreitete Ansätze, die häufig kombiniert werden:
- Take-home-Aufgabe an einer echten Codebasis. Der Kandidat erhält ein kleines, praxisnahes Problem, einen fehlgeschlagenen Test, eine Feature-Anfrage, ein Refactoring, und gibt funktionierenden Code mit einer kurzen Erklärung zurück. Die Bewertung konzentriert sich auf Struktur und Entscheidungen, nicht nur darauf, ob der Code läuft.
- Code-Walkthrough. Der Kandidat bringt ein aktuelles Stück eigener Arbeit mit und erläutert es. Dabei zeigt sich, wie er über Design, Kompromisse und Wartbarkeit nachdenkt, Dinge, die kein Algorithmus-Test erfasst.
- Live-Session mit erlaubten AI-Tools. Der Interviewer beobachtet, wie der Kandidat einen Assistenten einsetzt: was er eingibt, was er übernimmt, was er hinterfragt. Das ist aufschlussreicher als zuzusehen, wie jemand ohne Hilfsmittel tippt.
- Strukturiertes technisches Gespräch. Anstatt Code zu schreiben, diskutiert der Kandidat ein System-Design- oder Debugging-Szenario. Nützlich für Senior-Positionen, bei denen Urteilsvermögen wichtiger ist als das Erinnern von Syntax.
Jede Methode hat Schwächen. Take-home-Aufgaben kosten den Kandidaten Zeit und können ausgelagert werden. Walkthroughs setzen voraus, dass der Kandidat vorzeigbare Arbeit hat. Live-Sessions erfordern einen erfahrenen Interviewer, der weiß, wie guter Einsatz von AI-Tools aussieht.
Was der Wandel über Einstellungskriterien verrät
Den Test zu ersetzen ist einfacher, als sich darüber zu einigen, wonach man eigentlich sucht. Teams, die von Algorithmus-Tests abgerückt sind, stellen oft fest, dass sie kein klares Rahmenwerk hatten, was der Ersatz messen soll.
Bei Stellen, bei denen AI-Tools zentral sind, umfassen die relevanten Fähigkeiten: zu wissen, wann man generiertem Code vertrauen kann und wann man ihn prüfen sollte, unbekannten Code schnell zu lesen, plausibel wirkende Fehler zu erkennen und Entscheidungen zu treffen, wenn Anforderungen unklar sind. Nichts davon erscheint auf einem LeetCode-Leaderboard. Eine ausführlichere Übersicht finden Sie unter wie man die AI-Kompetenz eines Engineers bewertet.
Die verwandte Frage, worauf Reviewer bei AI-generiertem Output achten sollten, wird in wie man AI-generierten Code reviewt behandelt.
Das Risiko, einen Proxy durch einen anderen zu ersetzen
Einige Teams sind zu rein gesprächsbasierten Interviews oder Portfolio-Reviews übergegangen, ohne eine technische Überprüfung hinzuzufügen. Das tauscht ein Problem gegen ein anderes aus. Ein Kandidat kann Kompromisse flüssig diskutieren, ohne sie umsetzen zu können, genauso wie ein Algorithmus-Test jemanden bestehen lassen kann, der keine produktionsreife Software entwickeln kann.
Die besseren Alternativen verbinden ein praktisches Element, etwas, das der Kandidat tatsächlich erstellt oder durcharbeitet, mit ausreichend Struktur, sodass verschiedene Kandidaten anhand derselben Kriterien verglichen werden. Ohne Struktur tendieren Interviews dazu, Selbstsicherheit und Kommunikationsstil gegenüber fachlicher Kompetenz zu bevorzugen.
Was wir prüfen
Die Eignungsprüfung von Miyagami verwendet weder Algorithmusrätsel noch Take-Home-Projekte. Kandidaten absolvieren zwei Live-Sitzungen: eine Grundlagenbeurteilung ohne KI-Tools und eine AI-native Beurteilung mit den Tools, die sie normalerweise verwenden. In beiden Sitzungen achten die Prüfer auf Aspekte wie Eigenverantwortung, Urteil nach Risiko und den Umgang der Kandidaten mit mehrdeutigen statt klar formulierten Tickets. Die vollständigen Bewertungskriterien und das Sitzungsformat sind unter „Wie wir prüfen“ beschrieben.
Kurze Antworten
Ist das Coding-Interview vollständig tot?
Nicht vollständig. Viele große Unternehmen setzen es weiterhin im großen Maßstab zur Vorauswahl ein. Kleinere Teams und solche, die für AI-native-Rollen einstellen, entfernen sich am schnellsten davon und ersetzen sie durch aufgabenbasierte Überprüfungen oder Live-Sessions, bei denen KI-Tools erlaubt sind.
Was ist die beste Alternative zu einem Coding-Test?
Es gibt kein einzelnes Format, das am besten ist. Die meisten Teams kombinieren eine realistische Take-home-Aufgabe mit einem strukturierten Gespräch oder Walkthrough. Entscheidend ist, Urteilsvermögen und Review-Fähigkeit zu messen, nicht Gedächtnis oder Rätsellösegeschwindigkeit.
Können Kandidaten KI einfach nutzen, um einen Take-home-Coding-Test zu bestehen?
Ja, weshalb die Überprüfung der Einreichung genauso wichtig ist wie das Ergebnis. Ein anschließendes Walkthrough-Gespräch, bei dem der Kandidat gebeten wird, Entscheidungen zu erläutern und eingebaute Fehler zu finden, trennt schnell echtes Verständnis von unkritisch akzeptiertem generierten Code.
