Senior-Entwickler auswählen: Kompetenz, Evidenz und ein faires Verfahren

Senior-Softwareentwickler wählen Sie gut aus, indem Sie die Arbeit prüfen, nicht den Lebenslauf. Legen Sie fest, welche Kompetenzen die Rolle braucht, stellen Sie allen Kandidaten dieselben strukturierten Fragen, bewertet nach schriftlichen Kriterien, und sehen Sie ihnen bei einem realistischen Ausschnitt der Arbeit zu: Code schreiben und testen, ein System entwerfen, eine fremde Änderung reviewen. Jahrzehnte an Forschung zeigen, dass strukturierte Interviews und berufsspezifische Tests die Leistung weit besser vorhersagen als freie Gespräche, Berufsjahre dagegen kaum.

Dieser Leitfaden richtet sich an CTOs, Engineering-Leitungen und Gründer, die Senior-Entwickler einstellen, ob angestellt oder über einen Partner. Er zeigt, was Kompetenz bedeutet, was die Evidenz sagt, ein fünfstufiges Verfahren für eine Woche, was Sie vermeiden sollten, was in deutschsprachigen Teams anders ist und wie Sie den Standard nach dem Start halten.

#Was Kompetenz jenseits der Berufsjahre bedeutet

„Senior“ im Lebenslauf heißt meist: eine bestimmte Zahl an Jahren. Im Team heißt es etwas anderes: die Person, der Sie ein unscharfes Problem geben und die mit einer funktionierenden, getesteten und wartbaren Lösung zurückkommt, nachdem sie unterwegs die richtigen Fragen gestellt hat. Acht Kompetenzen beschreiben diese Person. Halten Sie fest, welche für Ihre Rolle am wichtigsten sind, bevor Sie den ersten Lebenslauf lesen. Diese Liste wird Ihr Interviewplan und Ihr Bewertungsbogen.

Auffällig ist, was fehlt: Jahre mit einem Framework, Zertifikate, ein Abschluss. Das kann nützlicher Kontext sein, sagt aber nicht, ob die Person die Arbeit kann, für die Sie einstellen. Eine enge Jahresvorgabe („sieben Jahre Kotlin“) filtert außerdem starke Entwickler heraus, die die Sprache erst letztes Jahr gelernt haben, auf einem Jahrzehnt solider Backend-Arbeit.

#Was die Forschung über Auswahlmethoden sagt

Die meistzitierte Zusammenfassung der Auswahlforschung ist Schmidt und Hunter (1998). Sie werteten Studien aus 85 Jahren dazu aus, wie gut Auswahlmethoden die Leistung im Job vorhersagen. 2022 haben Sackett, Zhang, Berry und Lievens diese Schätzungen im Journal of Applied Psychology neu berechnet. Ihr Ergebnis: Die früheren Korrekturen hatten die Validität überschätzt, die meisten Werte sinken um 0,10 bis 0,20, und strukturierte Interviews stehen nun an erster Stelle.

Für die Auswahl von Entwicklern folgen daraus drei Lehren. Erstens verdoppelt Struktur ungefähr den Wert eines Interviews: dieselbe Stunde, mit denselben Fragen für alle und nach schriftlichen Kriterien bewerteten Antworten, hängt etwa doppelt so stark mit der späteren Leistung zusammen wie ein freies Gespräch. Zweitens sind die stärksten Prädiktoren durchweg berufsspezifisch: Interviews über die tatsächliche Arbeit, Tests des nötigen Fachwissens, Proben der Arbeit selbst. Sackett und Kollegen weisen ausdrücklich darauf hin. Drittens taugen Berufsjahre allein kaum als Prädiktor und gehören deshalb nicht als erster Filter an den Anfang Ihres Verfahrens.

#Ein faires Auswahlverfahren für Senior-Entwickler

Das folgende Verfahren deckt die acht Kompetenzen in fünf Stufen ab und kostet Kandidaten insgesamt etwa vier bis sechs Stunden, verteilt auf rund eine Woche. Jede Stufe hat einen klaren Zweck, feste Fragen oder Aufgaben und einen Bewertungsbogen, den die interviewende Person ausfüllt, bevor sie mit anderen spricht.

1. Strukturiertes Interview (60 Minuten)

Stellen Sie allen Kandidaten dieselben fünf oder sechs Fragen zu echter früherer Arbeit, mit vorab geplanten Nachfragen. „Erzählen Sie von einem Produktionsvorfall, den Sie vom Alarm bis zur Behebung verantwortet haben. Was haben Sie danach geändert?“ prüft Verantwortung. „Beschreiben Sie eine technische Entscheidung, gegen die Sie argumentiert und verloren haben. Was ist passiert?“ prüft Kommunikation und Urteilsvermögen. Bewerten Sie jede Antwort auf einer Skala von 1 bis 4 mit schriftlichen Ankerbeispielen dafür, wie eine 2 und eine 4 klingen, damit zwei Interviewer mit „stark“ dasselbe meinen.

2. Realistische Arbeitsprobe oder Pairing-Session (90 bis 120 Minuten)

Geben Sie eine kleine, abgeschlossene Aufgabe aus Ihrer echten Domäne: ein Feature in einem vorbereiteten Repository ergänzen, einen fehlschlagenden Test reparieren, einen API-Endpunkt erweitern. Führen Sie sie live als Pairing-Session mit einem Ihrer Entwickler durch, auf Wunsch im eigenen Editor der Kandidatin oder des Kandidaten. Sie sehen, wie jemand fremden Code liest, Fragen stellt, testet und erklärt. Umgekehrt sieht die Person, wie Ihr Team arbeitet, und auch das gehört zu einem fairen Verfahren.

3. System-Design-Gespräch (60 Minuten)

Wählen Sie ein System nahe an dem, was die Person bauen wird: einen Buchungsdienst, eine Rechnungsstrecke, ein Benachrichtigungssystem. Beginnen Sie mit den Anforderungen und lassen Sie nach Last, Daten und Ausfällen fragen. Gute Senior-Entwickler sprechen über Abwägungen, Datenmodelle, über das, was passiert, wenn eine Abhängigkeit ausfällt, und darüber, wie sie eine erste Version ausliefern und weiterentwickeln. Bewerten Sie die Begründung, nicht ob jemand Ihre Architektur nachzeichnet.

4. Code-Review-Übung (45 Minuten)

Zeigen Sie einen realistischen Pull Request mit 150 bis 300 Zeilen und eingebauten Problemen: eine fehlende Berechtigungsprüfung, ein ungetesteter Randfall, ein irreführender Name, eine Datenbankabfrage in einer Schleife. Bitten Sie um ein Review wie für einen Kollegen. Diese eine Übung zeigt Codequalität, Testen, Sicherheitsbewusstsein und Ton. Wer den Fehler in der Zugriffskontrolle findet und die Kommentare freundlich formuliert, ist selten und wertvoll.

5. Referenzen (zwei Gespräche à 20 Minuten)

Sprechen Sie mit zwei Personen, die der Kandidat selbst nennt, idealerweise einer früheren Leitung und einem Kollegen, und nur mit seinem Einverständnis. Stellen Sie jedes Mal dieselben strukturierten Fragen: Was hat die Person verantwortet, wie ist sie mit Meinungsverschiedenheiten umgegangen, würden Sie wieder mit ihr arbeiten und in welcher Rolle? Referenzen ändern eine Entscheidung selten allein, können aber einen Zweifel aus den anderen Stufen bestätigen oder ausräumen.

#Bewertung und Einstellungsentscheidung

Die meisten Fehlbesetzungen entstehen nicht in schlechten Interviews, sondern in einer schlechten Entscheidungsrunde, in der die lauteste oder ranghöchste Stimme das Ergebnis bestimmt. Drei Gewohnheiten verhindern das. Interviewer reichen ihren Bewertungsbogen vor der Abstimmung ein und sprechen vorher nicht über die Person. Die Runde geht Kompetenz für Kompetenz durch, mit Belegen („Berechtigungsprüfung übersehen, nach einem Hinweis gefunden“) statt Adjektiven („wirkte fit“). Und die einstellende Führungskraft entscheidet gegen den Maßstab, der vor der Suche festgelegt wurde, nicht im Vergleich zu den anderen Kandidaten derselben Woche.

Halten Sie den Maßstab auch unter Zeitdruck. Eine Stelle, die einen Monat länger offen bleibt, kostet weniger als ein Senior-Entwickler, von dem Sie sich nach sechs Monaten wieder trennen müssen. Erfüllt niemand den Maßstab, prüfen Sie als Nächstes, ob er zur Rolle passt, statt ihn für den nächsten Kandidaten zu senken.

#Was Sie vermeiden sollten

• Denksport- und Rätselfragen. „Wie viele Fenster gibt es in New York?“ sagt wenig über Softwareentwicklung. Googles damaliger Personalchef nannte solche Fragen „a complete waste of time“ (ABC News, 2013), und Highhouse, Nye und Zhang (2018) beschreiben sie als ohne Validitätsnachweis und für Bewerber verunsichernd.
• Lange unbezahlte Hausaufgaben. Eine Take-Home-Aufgabe von mehr als zwei oder drei Stunden misst freie Zeit, nicht Können, und erfahrene Entwickler mit Job und Familie sagen oft ab. Halten Sie solche Aufgaben kurz und klar umrissen, vergüten Sie längere Arbeit oder ersetzen Sie sie durch eine Live-Pairing-Session.
• Algorithmus-Abfragen ohne Bezug zur Stelle. Einen Binärbaum am Whiteboard umzudrehen, prüft Interview-Training. Wenn die Rolle diese Art von Arbeit nicht wirklich verlangt, prüfen Sie die Probleme, die die Person tatsächlich lösen wird.
• Unstrukturierte Gespräche über den „Cultural Fit“. Ein angenehmes Gespräch ohne feste Fragen ist die schwächste Form des Interviews und das Einfallstor für Verzerrungen. Prüfen Sie Zusammenarbeit und Werte mit strukturierten Fragen wie alles andere.
• Ein langsames Verfahren. Starke Senior-Entwickler haben meist mehrere Optionen. Halten Sie das ganze Verfahren bei rund zwei Wochen und sagen Sie Kandidaten zu Beginn, was jede Stufe umfasst.

#Sprache, Zusammenarbeit und Fairness in DACH-Teams

Viele Entwicklungsteams in Deutschland, Österreich und der Schweiz arbeiten auf Englisch, während das Geschäft drumherum Deutsch spricht. Legen Sie fest, welche Sprache welcher Teil der Rolle wirklich braucht, und beschreiben Sie das mit den Niveaus des Gemeinsamen Europäischen Referenzrahmens (GER) statt mit „fließend“. Wer in einem englischsprachigen Squad arbeitet, braucht Deutsch vielleicht nur für den Alltag; wer Workshops mit deutschsprachigen Anwendern leitet oder deutsche Spezifikationen liest, braucht deutlich mehr. Prüfen Sie die Sprache dort, wo sie zählt, etwa indem Sie das System-Design-Gespräch auf Deutsch führen.

Arbeitsgewohnheiten zählen so viel wie Sprache. In DACH-Teams wird oft erwartet, dass Entscheidungen schriftlich festgehalten, abgestimmt und dann eingehalten werden, und direktes Feedback im Code-Review ist normal. Fragen Sie im strukturierten Interview, wie die Person mit einem Reviewer umgeht, der anderer Meinung ist, und wie sie eine Entscheidung dokumentiert.

Ein strukturiertes Verfahren ist in Deutschland zugleich Ihr bester Schutz. Weist eine abgelehnte Bewerberin nach dem Allgemeinen Gleichbehandlungsgesetz (AGG) Indizien nach, die eine Benachteiligung wegen eines geschützten Merkmals vermuten lassen, muss der Arbeitgeber beweisen, dass keine vorlag (§ 22 AGG). Schriftliche Fragen, Bewertungsbögen und belegbare Entscheidungen machen das möglich. Ansprüche müssen innerhalb von zwei Monaten nach Zugang der Absage schriftlich geltend gemacht werden, und die Entschädigung für jemanden, der auch bei benachteiligungsfreier Auswahl nicht eingestellt worden wäre, ist auf drei Monatsgehälter begrenzt (§ 15 AGG).

Zwei Besonderheiten betreffen Referenzen. Beschäftigte in Deutschland haben beim Ausscheiden Anspruch auf ein schriftliches Arbeitszeugnis, das nach dem Gesetz klar formuliert sein muss und keine versteckten Aussagen enthalten darf (§ 109 GewO); in der Praxis werden seine Standardformeln trotzdem als Notenskala gelesen, nehmen Sie es also als Kontext, nicht als Beleg. Und kontaktieren Sie Referenzgeber nur mit Einverständnis der Kandidaten, am besten Personen, die sie selbst genannt haben, denn Sie erheben dabei personenbezogene Daten über sie.

#Den Standard nach dem ersten Tag halten

Das Interview setzt eine Untergrenze; den eigentlichen Standard setzen die täglichen Gewohnheiten des Teams. Ein starker Entwickler in einem Team ohne Reviews, Tests und Dokumentation schreibt mit der Zeit Code wie alle anderen. Vier Gewohnheiten halten den Standard dort, wo Sie eingestellt haben.

• Code-Review bei jeder Änderung. Googles öffentliche Leitlinien sagen, ein Reviewer solle eine Änderung freigeben, sobald sie die Code-Gesundheit insgesamt eindeutig verbessert, auch wenn sie nicht perfekt ist, und dass Kommentare, bei denen jemand etwas lernt, immer willkommen sind. Diese Balance hält Reviews schnell und macht sie zum Lernwerkzeug.
• Pairing in den ersten Wochen. Lassen Sie neue Entwickler mit jemand Erfahrenem an echten Tickets arbeiten. Das überträgt das ungeschriebene Wissen einer Codebasis schneller als jedes Dokument und zeigt Ihnen früh, ob die Besetzung passt.
• Tests als Teil von „fertig“. Eine Änderung ohne Tests für das Verhalten, das sie hinzufügt, ist nicht fertig. Automatische Prüfungen in der Pipeline machen daraus eine Teamregel statt einer persönlichen Diskussion.
• Dokumentation, die aktuell bleibt. Ein kurzer Architekturüberblick, Entscheidungsprotokolle für schwer umkehrbare Weichenstellungen und Runbooks für den Betrieb. Neue Entwickler sollten sie im Onboarding aktualisieren, was zugleich der beste Test dafür ist, wie gut sie sind.

Bewerten Sie die Besetzung ehrlich nach dem ersten und nach dem dritten Monat, anhand derselben Kompetenzen, die Sie im Verfahren geprüft haben. Wenn etwas nicht funktioniert, sprechen Sie es früh an: Das ist fairer gegenüber der Person und dem Team.

#Checkliste für die Einstellung von Senior-Entwicklern

#Wie wir bei Bespoke IT Entwickler auswählen

Bei Bespoke IT prüfen die Entwickler, die unsere eigenen Produkte bauen, jedes Profil, das wir vorschlagen, statt dass ein Recruiter Stichwörter im Lebenslauf abgleicht. Bevor etwas unterschrieben ist, lernen Sie die Person in einer Arbeitssitzung an Ihrem eigenen Problem kennen, und passt es nicht, bringen wir die nächste Person. Sie arbeitet in Ihrem Repository, mit Ihren Tools und in Ihren Routinen. Sehen Sie sich unser Angebot für IT-Fachkräfte an, schätzen Sie die Kosten eines Teams oder sagen Sie uns, wen Sie brauchen. Wenn Sie ein größeres Junior-Team gegen ein kleineres Senior-Team abwägen, beleuchtet unser Artikel warum ein Senior-Entwicklungsteam die Abwägungen.