Wie erkenne ich einen guten Programmierer im Interview?

Warum diese Frage teuer ist – und Bauchgefühl selten hilft

Falsche Einstellungen in Entwickler‑Teams kosten Zeit, Geld und Produktfokus. Gleichzeitig sind klassische Interviews anfällig für Fehlurteile: Wer souverän spricht, wirkt schnell kompetent, auch wenn Transferleistung oder Codequalität fehlen. Der Preis dafür sind monatelange Einarbeitungen ohne Output, Teamfrust und Rehiring.

Dieser Artikel bietet eine praxisnahe Antwort aus Recruiting‑Perspektive: Welche Signale im Gespräch typischerweise bewertet werden, wie man diese Signale zuverlässig erhebt – und wie Sie typische Bias und Bewertungsfehler vermeiden.

Was „gute“ Programmierer:innen im Arbeitsalltag auszeichnet

In vielen produktiven Teams zählen reproduzierbare Arbeitsweisen oft mehr als das Lösen künstlicher Algorithmus‑Rätsel. Kurz gesagt: gute Entwickler:innen liefern nachhaltig verlässliche Lösungen, nicht nur punktuelle Ergebnisse. Im Folgenden die wichtigsten Dimensionen, die sich in der täglichen Arbeit wiederholen und sich im Interview beobachten lassen:

Problemlösen unter Ungewissheit: Anforderungen klären, Annahmen testen, iterativ enger werden.
Transfer von Erfahrung: bekannte Muster erkennen, Risiken antizipieren und pragmatisch entscheiden.
Codequalität im Kleinen: lesbarer, testbarer Code, sinnvolle Abstraktionen, Fehlertoleranz.
Kommunikation: Denkprozess erklären, Feedback einholen, mit Stakeholdern handhabbar sprechen.
Systemdenken: Wechselwirkungen, Performance, Sicherheit, Kosten, Betrieb im Blick behalten.
Lernfähigkeit: sauberes Nachziehen bei Lücken, strukturiertes Experimentieren, Post‑Mortems ernst nehmen.

Diese Faktoren lassen sich im Interview beobachten – wenn das Format auf Signale statt Show ausgelegt ist.

Validierbare Interviewsignale: Woran Sie konkret ansetzen sollten

Die Forschung zeigt, dass technische Interviewer mehr erwarten als nur „richtiges“ Code‑Ergebnis. Eine Studie von Microsoft Research beschreibt drei Kerndimensionen, auf die Interviewer tatsächlich achten: ein strukturiertes Problem‑Walkthrough, die Anwendung früherer Erfahrungen auf neue Probleme und die Fähigkeit, jenseits des Codens konstruktiv im Gespräch zu überzeugen. Quelle: The Tech‑Talk Balance: What Technical Interviewers Expect from Technical Candidates.

Aus diesen Befunden lassen sich praxisnahe Beobachtungspunkte ableiten. Kurzvorab: Achten Sie weniger auf den sauberen Endcode und mehr auf die Art, wie Kandidat:innen Probleme strukturieren, Entscheidungen begründen und Erfahrungen transferieren.

Problemverständnis sichtbar machen

Bitten Sie Kandidat:innen, die Aufgabe in eigenen Worten zu rahmen. Achten Sie auf Klärfragen zu Zielen, Randbedingungen, Datenvolumen und Fehlerfällen; auf explizite Annahmen („Ich gehe davon aus, dass …“) sowie auf eine nachvollziehbare Strukturierung: Grobskizze → Iteration → Verifikation.

Entscheidungen und Trade‑offs statt nur das Endergebnis

Gute Entwickler:innen begründen ihren Weg: Warum Lösung A statt B? Was kostet die Entscheidung später im Betrieb? Halten Sie nach Abwägungen Ausschau (Komplexität, Laufzeit, Lesbarkeit, Sicherheit, Kosten) – nicht nur nach dem finalen Code.

Erfahrungstransfer prüfen

Fragen Sie nach ähnlichen Situationen: „Erzählen Sie von einem Bug/Incident/Refactor, der hier relevant ist. Was war übertragbar, was nicht?“ Beobachten Sie, ob Muster benannt und sauber auf den neuen Kontext gemappt werden.

Kommunikation als Teil der Leistung

Lassen Sie den Denkprozess laut werden. Gute Kandidat:innen teilen Hypothesen, Zwischenstände und Unsicherheiten; reagieren produktiv auf Nachfragen und Gegenbeispiele; und übersetzen Technik kurz für Nicht‑Techniker:innen.

Stichproben für Codequalität

Vorab: Ein kurzer, gezielter Code‑Check zeigt oft mehr über Alltagsqualität als komplexe Puzzleaufgaben. Nutzen Sie kleine Live‑Aufgaben oder kuratierte Take‑Homes mit klaren Beurteilungskriterien. Prüfen Sie dabei konkret Verständlichkeit (Benennungen, Struktur, Kommentare im richtigen Maß), Testansatz (Unit‑/Property‑Tests, Edge Cases), Fehlerbehandlung und Robustheit, Vereinfachungen (YAGNI) sowie Wartbarkeit (kleine, fokussierte Funktionen, Modularität).

Interviewformate im deutschen Recruiting‑Kontext – Stärken und Schwächen

Unterschiedliche Formate messen Unterschiedliches. Setzen Sie sie bewusst ein und kombinieren Sie wenige, aber valide Bausteine.

Kurzes Screening (15–20 Min., remote): prüft Basispassung, Kommunikationsstil, Erwartungen. Schwäche: misst kaum Tiefgang. Eignet sich zum Klären von Rahmen und Motivation.
Technischer Deep‑Dive (45–60 Min.): ideal für Problemstruktur, Trade‑offs und Erfahrungstransfer. Benötigt vorbereitetes Szenario aus Ihrer Domäne.
Live‑Coding/Pair‑Programming (30–60 Min.): misst Arbeitsweise unter Beobachtung, Lesbarkeit, Testdenken. Achten Sie auf realistische, kleine Aufgaben und ein kooperatives Setting, nicht auf „Show‑Juggling“.
Take‑Home (Richtwert 2–4 Std., je nach Seniorität/Aufgabe begrenzen): erlaubt Sorgfalt und Tests. Bewertungsfallen: unklare Erwartungen, zu hoher Zeitaufwand, Intransparenz bei der Auswertung. Nutzen Sie klare Abgabekriterien und offerieren Sie Alternativen (z. B. Code‑Review eines Mini‑Repos statt Full‑App).
Strukturierte Interviews mit Rubrics: werden häufig eingesetzt; können Vergleichbarkeit erhöhen und subjektiven Einfluss verringern, wenn sie konsequent angewandt werden.

Praxis‑Tipp: Knappe, gut vorbereitete Prozesse können – insbesondere im deutschen Markt – ein Wettbewerbsvorteil sein. Zwei gut vorbereitete Gespräche mit strukturierter Bewertung können einer fünfstufigen Marathon‑Pipeline überlegen sein – effizienter und dennoch oft ausreichend für vergleichbare Entscheidungen.

Bias und typische Bewertungsfehler – und wie Sie sie reduzieren

Kurzfassung zuerst: Interaktion verzerrt Bewertungen; längere, persönlichere Kontakte können Bias verstärken. Ein Working Paper des ifo Instituts zu rund 60.000 Mock‑Interviews auf einer Plattform für Software Engineers findet geringere Bewertungen für Frauen – selbst bei Kontrolle objektiver Codequalität. Der Gap wird größer mit längerer persönlicher Interaktion; automatisierte Leistungsmetriken allein beheben ihn nicht. Quelle: Decoding Gender Bias in Interviews.

Häufige Biasquellen im Tech‑Interview:

Halo‑/Horns‑Effekt: ein starker/schwacher Eindruck färbt alles Weitere.
Affinitäts‑Bias: Sympathie für ähnliche Lebensläufe, Uni, Hobbys.
Overweighting von Sprechgewandtheit: rhetorisch starke Kandidat:innen werden überschätzt.
Ungleiche Gesprächsdynamik: Unterbrechen, Herablassung, Zeitasymmetrien.

Praktische Gegenmaßnahmen (kurze Einordnung): Strukturierte Abläufe und geteilte Bewertungsgrundlagen können helfen, subjektiven Einfluss zu verringern. Konkret:

Struktur und Standardisierung: gleiche Kernfragen und Bewertungskriterien pro Rolle.
Rollenverteilung: eine Person führt, eine beobachtet und protokolliert.
Mehrfaches, unabhängiges Rating: Scores getrennt erfassen, dann erst diskutieren.
Klare Rubrics: verhaltensnahe Skalen statt „Bauchgefühl“.
Anonymisierte Aufgaben, wo möglich (z. B. Take‑Homes ohne persönliche Daten).
Gesprächsdisziplin: Redezeiten ausbalancieren, Nachfragen symmetrisch stellen.

Praxisleitfaden: Fragen, Rubric und Ablauf, die funktionieren

Im Folgenden ein kompakter Baukasten, der sich in deutschen Teams bewährt.

Drei bewährte Fragetypen

Problem‑Walkthrough (Domänenbezug)

„Wir müssen täglich 10 Mio. Zeilen Logdaten nach Anomalien durchsuchen und einen Alert auslösen. Wie würden Sie vorgehen? Welche Trade‑offs sehen Sie zwischen Genauigkeit, Kosten und Latenz?“

Bewertungsanker: Strukturierung, Annahmen, Datenfluss, Back‑of‑the‑Envelope‑Abschätzung, Risikoanalyse, Iterationsvorschlag.

Transferfrage (Erfahrung anwenden)

„Erzählen Sie von einem Produktionsincident, der Sie heute zu einer anderen Architekturentscheidung gebracht hat. Was davon ist hier übertragbar, was nicht?“

Bewertungsanker: Mustererkennung, Kausalität, Gegenmaßnahmen, Lernschleife (Post‑Mortem), Grenzen des Transfers.

Code‑Review‑Probe (kleines Snippet, 30–40 Zeilen)

„Was würden Sie in diesem Code ändern und warum? Welche Tests fehlen? Welche Edge Cases?“

Bewertungsanker: Lesbarkeit, Testbarkeit, Fehlerbehandlung, Vereinfachung, Nebenwirkungen/Komplexität.

Minimal‑Rubric für schnelle, faire Entscheidungen

Die folgende Kurzrubrik hilft, subjektive Eindrücke schnell in vergleichbare Scores zu überführen. Verwenden Sie sie als Basis und passen Sie Gewichtungen an Ihre Rolle an.

Skala 1–4 je Kriterium (1 = schwach, 4 = stark). Summenbereich: 6–24.

Problemstrukturierung: Klärt Ziele/Randbedingungen, macht Annahmen explizit, arbeitet iterativ.
Entscheidungen & Trade‑offs: Begründet Alternativen, sieht Betriebs‑ und Produktfolgen.
Erfahrungstransfer: Nannte relevante Beispiele, zog passende Schlüsse, benannte Grenzen.
Codequalität: Lesbarkeit, Tests, Fehlertoleranz, sinnvolle Abstraktionen.
Kommunikation: Klarheit, aktives Nachfragen, Umgang mit Feedback, Stakeholder‑Übersetzung.
Zusammenarbeit: Pairing‑Signale, konstruktiver Umgang mit Unsicherheit, Ownership.

Interpretation der Summe (Kurznote):

20–24: Stark passend; Angebot erwägen, Referenzen/Arbeitsprobe optional absichern.
16–19: Solide; bei Unklarheit ein fokussiertes Zweitgespräch oder Mini‑Task.
12–15: Risikoprofil; nur bei starker Rolle/Team‑Hebel und Entwicklungsplan.
< 12: Keine Einstellung; Feedback und ggf. Talentpool.

Beispiel‑Ablauf für 45–60 Minuten

0–5 Min: Warm‑up, Rollen klären, Ziel des Gesprächs.
5–25 Min: Problem‑Walkthrough (Domänenfall), Nachfragen, kleine Iteration.
25–40 Min: Code‑Review‑Probe oder kurzes Pairing am Editor (keine Trickaufgaben).
40–50 Min: Transferfrage + Trade‑offs in der Kandidat:innen‑Historie.
50–55 Min: Fragen der Kandidat:innen (Team, Architektur, Delivery‑Prozess).
55–60 Min: Nächste Schritte, Zeitrahmen, Feedbackkultur erklären.

Rollen: Eine Person moderiert, eine protokolliert entlang der Rubric, optional eine Fachexpertin/ein Fachexperte für Deep‑Dives. Scores getrennt notieren, erst danach in 10–15 Minuten intern abgleichen.

Trade‑offs und wann das Interview nicht genügt

Interviews zeigen Potenzial in kurzer Zeit. Sie ersetzen nicht:

Arbeitsproben aus echter Umgebung (z. B. kleines, bezahltes Mini‑Projekt oder Probe‑Pairing an einem nicht‑kritischen Modul).
Referenzen, die Substanz prüfen (konkret nach Beitrag, Kollaboration, Zuverlässigkeit fragen; keine „Wie war’s so?“‑Smalltalks).
Für Senior‑Rollen: Portfolio‑Gespräche zu Architekturentscheidungen, Incidents, Migrationsprojekten und deren messbaren Effekten.

Wichtig ist ein sauberer Erwartungsschnitt: Kultur‑Passung ist relevant, darf aber technische Eignung nicht überdecken. Klären Sie, was für die Rolle „Must‑have“ ist – und was man realistisch in den ersten Monaten entwickeln kann.

Häufige Bewertungsfallen – und wie Sie sie vermeiden

Kurz zusammengefasst: Vermeiden Sie Puzzle‑Fokus, Ergebnisfixierung und unklare Kriterien. Hier die Kernfehler und wie man sie konkret umgeht:

Leetcode‑Rätsel können vor allem Übung und Prüfungsskills messen; je nach Rolle und Aufgabenzuschnitt bildet das die Produktfähigkeit nur begrenzt ab. Besser: Aufgaben aus Ihrer Domäne, klein skaliert.
Ergebnisfixierung: Nur auf „läuft“ sehen, nicht auf Weg dorthin. Der Weg verrät Reife.
Unklare Kriterien: Ohne Rubric werden lautere Stimmen im Debrief dominieren.
Ungleiche Zeitverteilung: Kandidat:innen kommen nicht zum Denken, weil der Interviewer redet.
Format‑Overkill: Zu viele Runden schrecken gute Kandidat:innen ab – besonders im deutschen Markt mit parallelen Angeboten.

Vor der Einladung: erste Signale richtig lesen

Schon vor dem Gespräch lassen sich Anhaltspunkte sinnvoll deuten: zielgerichtete Anschreiben, aussagekräftige Projekte, Community‑Beitrag – statt reiner Keyword‑Listen. Eine deutschsprachige HR‑Einordnung dazu bietet die Personalwirtschaft: „Wie erkenne ich einen Top‑Entwickler am Lebenslauf?“ (untermauert, dass Leidenschaft und Substanz wichtiger sind als Buzzword‑Sammlungen). Link: Personalwirtschaft.

Fazit: Die Kurz‑Checkliste für Hiring‑Teams

Formate auf Signale ausrichten: Problem‑Walkthrough, Transfer, Code‑Qualität – nicht Show.
Struktur statt Bauchgefühl: Standardfragen, Rubric, getrennte Scores, kurzes Debrief.
Bias aktiv reduzieren: Gesprächsdisziplin, symmetrische Nachfragen, ggf. anonymisierte Take‑Homes.

Wenn Teams dieselbe Erwartung an „gut“ teilen, steigen Entscheidungsqualität und Candidate Experience spürbar. Ein einstündiges, gut vorbereitetes Tech‑Interview kann gute Anhaltspunkte liefern, wie jemand bei Ihnen morgen echte Probleme angeht – genau darum geht es.