Unser Auswahlverfahren
Jeder Engineer, den wir vermitteln, besteht zwei Live-Assessments von je 60 Minuten in einer echten Codebase: eines ohne KI-Tools, eines mit den eigenen Agents. Beide Scorecards sehen Sie, bevor Sie die Person kennenlernen.
-
01
Schritt 1
Prüfung der Bewerbung
Produktiver Code mit einer Commit-Historie, die Iterationen zeigt, passend zu Rolle und Stack. Keine Tutorial-Projekte und keine Angaben zu KI-Tools ohne Code dahinter.
-
02
Schritt 2
Kennenlerngespräch
Antwortet auf die Frage, die tatsächlich gestellt wurde.
-
03
Schritt 3 · Assessment 1
Assessment Grundlagen
Sechzig Minuten in einer unbekannten Codebase, ohne KI-Tools. So zeigt sich, ob jemand ein System selbstständig lesen, das eigentliche Problem finden und Abwägungen begründen kann.
Zur Scorecard -
04
Schritt 4 · Assessment 2
AI-native Assessment
Sechzig Minuten an neuen Tickets, mit den eigenen Agents. So zeigt sich, wie jemand die Arbeit plant, die Ergebnisse des Agents prüft und entscheidet, was sicher live gehen kann.
Zur Scorecard -
05
Schritt 5
Führungsgespräch und Referenzen
Für Senior- und kundennahe Rollen: eine stimmige Darstellung in zwei Gesprächen und frühere Vorgesetzte, die sie bestätigen.
-
06
Schritt 6
Entscheidung
Alle Scorecards werden gemeinsam betrachtet und schriftlich begründet. Der starke Eindruck einer einzelnen Interviewerin oder eines einzelnen Interviewers gleicht eine Scorecard nicht aus, die die Hürde nicht genommen hat.
-
07
Schritt 7
Aufnahme in die Shortlist
Engineers, die jede Stufe bestehen, werden passend zu Ihren Rollen und Ihrem Stack zugeordnet. Die scorecards erhalten Sie, bevor Sie die Personen kennenlernen.
Shortlist anfordern
Warum wir Take-home-Aufgaben und Coding-Tests abgeschafft haben
Alle Take-Home-Aufgaben sehen heute gleich aus, weil alle von Modellen geschrieben werden. LeetCode misst Mustererkennung unter Zeitdruck. Keines von beidem zeigt die Grundlagen, und keines zeigt die Agentenfähigkeiten.
Deshalb haben wir beides ersetzt, durch zwei Live-Assessments in einer echten Codebase: eines ohne Agents, eines mit. Diese Scorecards füllen wir für jeden Engineer aus, den wir vermitteln.
Assessment 1 · KI-Tools aus
Die Grundlagenprüfung
Der Engineer bekommt eine Codebasis, die er noch nicht kennt, eine Handvoll Tickets, darunter einen Produktionsfehler, und 60 Minuten Zeit. Die Sitzung läuft wie ein normaler Arbeitsblock, ohne KI-Tools.
Zur ScorecardAssessment 2 · KI-Tools an
Die AI-native-Prüfung
Der Engineer erhält neue Tickets in einer ähnlichen Codebase und dazu die KI-Coding-Tools, die er sonst auch nutzt. Das Assessment zeigt, was er tut, wenn ein Agent den Großteil der Arbeit erledigt: ob er zuerst plant, ob er liest, was zurückkommt, und ob er eine Änderung erklären kann, die er nicht selbst getippt hat.
Zur ScorecardWarum Grundlagen mit Agents weiter zählen
Der Engineer bekommt eine Codebasis, die er noch nicht kennt, eine Handvoll Tickets, darunter einen Produktionsfehler, und 60 Minuten Zeit. Die Sitzung läuft wie ein normaler Arbeitsblock, ohne KI-Tools.
Was gut aussieht
- Liest den Datenfluss und die Fehlermodi, bevor Code angefasst wird
- Priorisiert den Produktionsfehler und kann benennen, was er betrifft
- Führt das Symptom auf die eigentliche Ursache zurück
- Fügt den Test hinzu, der den Fehler abgefangen hätte
Was schlecht aussieht
- Behebt das Symptom und geht weiter
- Behandelt jedes Ticket als gleiches Risiko
- Kann sagen, dass eine Änderung funktioniert, aber nicht warum
- Ändert gemeinsam genutzten Code, ohne zu prüfen, wer davon abhängt
Die Bewertungskriterien · sechs Kriterien
Kommunikation
Benennt Abwägungen und sagt, was nicht erledigt wurde, anstatt still zu werden. Fragt nach, wenn ein Ticket unklar ist, anstatt zu raten.
Englischniveau
Wird verstanden und ist verständlich, mündlich wie schriftlich. Kann ein Argument vertreten und hält es auch bei einer Nachfrage.
Priorisierung
Die Reihenfolge, in der Tickets bearbeitet werden, entspricht der angegebenen Dringlichkeit. Der Produktionsfehler kommt immer zuerst.
Debugging
Findet Ursachen strukturiert, vom Symptom zur Ursache, statt durch Versuch und Irrtum. Überprüft die Lösung, bevor er sie als abgeschlossen meldet.
Kontextwechsel-Hygiene
Behält den Überblick darüber, welche Tickets offen sind und wo jedes steht, wenn gewechselt wird. Nimmt eine Aufgabe wieder auf, ohne alles erneut lesen zu müssen.
Technisches Verständnis
Zeigt Tiefe beim Stack, bei den komplexen Abläufen der Anwendung und im Terminal. Startet die Anwendung und sieht sich die Codebase an, bevor etwas geändert wird.
Agents bauen alles, was Sie ihnen vorgeben
Der Engineer erhält neue Tickets in einer ähnlichen Codebase und dazu die KI-Coding-Tools, die er sonst auch nutzt. Das Assessment zeigt, was er tut, wenn ein Agent den Großteil der Arbeit erledigt: ob er zuerst plant, ob er liest, was zurückkommt, und ob er eine Änderung erklären kann, die er nicht selbst getippt hat.
Was gut aussieht
- Hält Annahmen, Randbedingungen und Grenzfälle schriftlich fest
- Kennzeichnet alle Änderungen, die Daten, Authentifizierung oder Abrechnung betreffen
- Prüft das Diff und fragt den Agenten nach der Begründung für den gewählten Ansatz
- Hinterlässt etwas Wiederverwendbares
Was schlecht aussieht
- Gleiche Prüftiefe bei einer Textänderung und einer Migration
- „Der Agent hat es getan“ als Erklärung
- Erneutes Prompten statt den Kontext zu korrigieren
- Akzeptiert einen Plan, der das bereits im Repository Vorhandene dupliziert
Die Bewertungskriterien · sechs Kriterien
Überprüfung von KI-Ausgaben
Erkennt halluzinierte APIs, subtil fehlerhafte Logik oder Sicherheitslücken im generierten Code, bevor dieser ausgeliefert wird, anstatt ihm zu vertrauen, nur weil er kompiliert.
Tool-Orchestrierung
Weiß, wann Aufgaben an den Agenten übergeben werden (Scaffolding, Boilerplate, Tests) und wann manuell codiert wird (neue Logik, schwierige Grenzfälle), und führt beides parallel in Worktrees aus.
Spezifikationsgetriebene Entwicklung
Zerlegt ein vages Ticket in Teilaufgaben, die klein genug sind, damit das Tool sie zuverlässig ausführen kann, anstatt die gesamte unklare Anforderung auf einmal hineinzuwerfen.
Prompt- und Kontext-Engineering
Richtet den Prompt und den Aufgabenkontext so ein, dass das Tool in einem oder zwei Durchläufen brauchbare Ergebnisse liefert, anstatt dieselbe vage Anfrage immer wieder zu stellen.
KI-gestützte Fehleranalyse
Nutzt den Agenten für die Ursachenanalyse, Log-Triage und Stack Traces, ohne den Schritt zu überspringen, den Fehler selbst zu reproduzieren und zu verstehen.
Kontextwechsel-Hygiene
Auch hier wird die Disziplin beim Kontextwechsel bewertet, diesmal mit laufenden Agents. Ein guter Engineer weiß, was jeder Agent gerade tut, kehrt zum richtigen zurück und lässt den Wechsel nicht von Benachrichtigungen steuern.
Was Senior Engineers von schnellen unterscheidet
Sie passen nicht auf eine Scorecard. Deshalb achten wir in beiden Assessments darauf.
01
Urteilsvermögen nach Risiko
Eine Textänderung, ein risikoarmes Refactoring und eine Zahlungsmigration sollten nicht dieselbe Prüfung erhalten. Gute Engineers beschleunigen beim ersten und bremsen deutlich beim dritten. Agents erledigen alle drei mit derselben Geschwindigkeit und demselben Selbstvertrauen.
Im Assessment
Liest der Kandidat den Migration-Diff Zeile für Zeile und überfliegt nur die Textänderung? Spricht er den Auswirkungsbereich an, bevor wir es tun?
02
Verantwortungsbewusstsein
Wenn Sie es mergen, gehört es Ihnen. Tests, Observability, Rollout und das Debugging nach dem Release sind Teil der Arbeit, unabhängig davon, ob ein Mensch oder ein Agent den Code geschrieben hat.
Im Assessment
„Der Agent hat das gemacht“ lassen wir im Assessment nicht als Erklärung gelten, und in einem Incident Review Ihres Teams wird es genauso wenig akzeptiert.
03
Leverage
Die besten Engineers schließen das Ticket ab und hinterlassen das Repo so, dass der nächste Agent besser darin arbeiten kann: ein wiederverwendbarer Befehl, eine präzisere CLAUDE.md, ein Test, der die ganze Fehlerklasse abfängt.
Im Assessment
Hat das, was sie in der Stunde gebaut haben, das nächste Ticket einfacher gemacht, oder haben sie das Repository genau so hinterlassen, wie sie es vorgefunden haben?
Whitepaper
Der nächste 10X Engineer
Warum die besten Engineers heute weniger Code schreiben, und wie man sie von allen anderen unterscheidet.
Vierzehn Seiten von Bo Wesdorp, unserem CTO: was die Rolle heute bedeutet, was AI-native heißt, warum der klassische Einstellungsprozess nicht mehr funktioniert, und beide Scorecards vollständig.
Häufig gestellte Fragen
Falls Ihre Frage nicht dabei ist, helfen wir Ihnen gerne weiter.
Kontakt aufnehmenVeröffentlichen Sie Ihre Beurteilung?
Ja. Beide Assessments, Beispiele für gute und schlechte Ergebnisse und die zwölf Kriterien der beiden Scorecards finden Sie auf dieser Seite und im Whitepaper „The Next 10X Engineer“.
Kann ich die Ergebnisse eines Kandidaten einsehen?
Ja. Jeder Engineer auf der Shortlist wird mit beiden ausgefüllten Scorecards vorgestellt. Sie sehen diese, bevor Sie jemanden persönlich treffen.
Wer führt die Assessments durch?
Beide Assessments führen Senior Engineers durch, die täglich mit diesen Tools Software für den Produktivbetrieb bauen. Recruiter bewerten keine Kandidaten.
Warum kein Take-home-Test oder Coding-Test?
Take-home-Aufgaben werden heute von Sprachmodellen gelöst, und LeetCode-Tests messen das Abrufen von Mustern unter Zeitdruck. Keiner von beiden zeigt die grundlegenden Fähigkeiten oder die Agent-Kompetenzen.
Sehen Sie die Scorecards, bevor Sie jemanden treffen
Teilen Sie uns die Stelle mit. Wir schicken Ihnen namentlich genannte Engineers mit beiden ausgefüllten Scorecards innerhalb von fünf Werktagen.
ISO 27001Zertifiziert