Das technische Interview für deinen ersten Senior Developer: Was du testen solltest und warum
Dein erster Senior Developer ist das Interview, auf das du am wenigsten vorbereitet bist. Gründer und frischgebackene Engineering Manager kopieren meist den Prozess, den sie selbst durchlaufen haben: LeetCode-Rätsel und System-Design-Runden, dimensioniert für Unternehmen mit Millionen Nutzern. Ein Senior Developer Interview Prozess für ein SaaS-Unternehmen mit 5 bis 15 Personen muss etwas anderes testen, weil der Job etwas anderes ist. Dieser Beitrag geht durch, was Seniorität in deiner Größe bedeutet, einen vierstufigen Prozess, den du in zwei Wochen durchziehen kannst, das Take-Home-Format, das Urteilsvermögen zeigt, ohne den Goodwill der Kandidaten zu verbrennen, und die Scorecard, die deine Entscheidung ehrlich hält.
Was Seniorität in einem Unternehmen mit 15 Leuten bedeutet
In einem großen Unternehmen besitzt ein Senior Engineer einen klar abgegrenzten Ausschnitt eines Systems und geht dort in die Tiefe. Die Organisation um ihn herum absorbiert die Unklarheit: Product Manager schreiben Specs und Staff Engineers setzen die Architektur. In einem SaaS-Unternehmen mit 5 bis 15 Personen existiert dieses Gerüst nicht. Seniorität in deiner Größe bedeutet Problem Framing. Jemand gibt der Person ein vages Geschäftsproblem, etwa "Kunden fragen ständig nach Exporten", und sie kommt mit einem eingegrenzten Plan zurück, einer Liste dessen, was sie bewusst weggelassen hat, und einer Frage, die die Anforderung neu formt.
Codequalität zählt weiterhin, aber sie ist die Grundlinie, nicht das Unterscheidungsmerkmal. Viele Entwickler schreiben sauberen Code und brauchen trotzdem eine Spec in die Hand. Der teure Fehler ist, einen starken Umsetzer in eine Rolle zu holen, die einen Entscheider gebraucht hätte. Was dein erster Senior tut, wird außerdem zum Standard: Seine Coding-Patterns und sein Review-Ton werden zur Hausnorm, die jede spätere Einstellung kopiert.
Ein Senior Developer Interview Prozess, den du in zwei Wochen durchziehst
Geschwindigkeit ist Teil des Designs. Senior-Kandidaten bleiben selten lange auf dem Markt, und ein Prozess, der sich über drei Wochen zieht, verliert sie an schnellere Wettbewerber. In Deutschland ist der Einsatz noch höher, weil zwischen Angebot und Startdatum ohnehin oft eine dreimonatige Kündigungsfrist liegt. Unser Beitrag zum Einstellen von Senior Developern in Deutschland behandelt diese Marktseite im Detail.
Der Prozess hat vier Stufen:
- Ein 45-minütiges Screening mit Gründer oder Hiring Manager, aufgebaut auf vergangenen Entscheidungen statt Trivia.
- Ein bezahltes Take-Home, begrenzt auf drei oder vier Stunden.
- Ein 90-minütiges Gespräch, das ein Take-Home-Debriefing mit einer Architekturdiskussion kombiniert.
- Referenzgespräche, richtig gemacht.
Das ist der gesamte Senior Developer Interview Prozess. Er enthält absichtlich keine Whiteboard-Algorithmus-Runde: Eine verkettete Liste unter Beobachtung umzudrehen sagt fast nichts darüber aus, ob jemand eine Billing-Migration scopen kann.
Frag im Screening nach Konkretem. Die letzte technische Entscheidung, die sie bereuen. Der Incident, an den sie sich am stärksten erinnern. Was sie an der Codebasis ändern würden, die sie gerade verlassen haben. Wenn die Rolle Richtung Frontend geht, behandelt unser Beitrag zu React-Interviewfragen dieses Screening ausführlicher.
Das Take-Home: Klein, bezahlt und geformt wie deine echte Arbeit
Ein unbezahltes achtstündiges Take-Home filtert nach Leuten mit freien Wochenenden, und das ist alles, wonach es filtert. Zahle eine Pauschale, begrenze die Aufgabe auf Vertrauensbasis auf drei oder vier Stunden und baue sie aus einem bereinigten Ausschnitt deines tatsächlichen Produkts. Ein funktionierender, aber grober Service mit einem eingebauten Bug und einem fehlenden Feature funktioniert gut. Bitte darum, das Feature hinzuzufügen und eine kurze Notiz zu schreiben, was sie ändern würden, wenn ihnen der Code gehörte. Ob sie den Bug bemerken, sagt dir ebenfalls etwas.
Die schriftliche Notiz trägt so viel Signal wie der Code. Seniors unter Zeitlimit kürzen den Umfang und sagen das auch. Ihre README liest sich wie eine Nachricht an einen Kollegen: Das habe ich gemacht, das habe ich übersprungen und warum. Juniors polieren eine Ecke und schweigen zum Rest. Bewerte die Argumentation so stark wie die Umsetzung. Eine unerklärte Abkürzung ist ein größeres Warnsignal als eine erklärte.
Ein praktisches Problem bleibt: Jemand muss das bewerten, und in vielen kleinen Unternehmen hat noch niemand Arbeit auf Senior-Niveau reviewt. Unser durchgearbeitetes Beispiel dazu, was ein Senior Code Review findet, zeigt den Unterschied konkret, und ein externer Reviewer über unser Code Quality Consulting kann Einreichungen bewerten, bis du diese Seniorität im Haus hast.
Das Architekturgespräch: Trade-offs statt Patterns
Verzichte auf erfundene Szenarien. Bring eine echte Entscheidung mit, vor der dein Unternehmen steht oder die du kürzlich getroffen hast, und arbeitet sie gemeinsam durch. Der Kandidat hat keinen Kontext zu deinem Produkt, und zuzusehen, wie er sich diesen Kontext erarbeitet, ist der Test.
Das stärkste Signal ist, was sie fragen, bevor sie antworten. Seniors, die auf kleine Unternehmen kalibriert sind, fragen zuerst nach Rahmenbedingungen: wie viele Kunden, wie viel Traffic, wie viele Entwickler, was bricht, wenn das zwei Monate zu spät kommt. Kandidaten aus größeren Unternehmen springen oft direkt zum Pattern, das sie kennen, und du hörst einen Vorschlag mit Message Broker und Kubernetes-Cluster für ein Produkt mit vierzig Tenants.
Dann stell die Frage, die Level trennt: Was müsste sich ändern, damit sich deine Antwort ändert? Ein Senior Engineer kann die Schwelle benennen, an der die einfache Variante aufhört zu funktionieren und die schwerere ihre Kosten verdient. Jemand, der ein Pattern aufsagt, kann das nicht, weil das Pattern ohne seine Begründung angekommen ist.
Nutze dieselbe Session für das Take-Home-Debriefing. Bitte darum, die eigene Einreichung zu kritisieren, bevor du deine Notizen teilst. Seniors nennen ihre Abkürzungen unaufgefordert und entdecken meist ein Problem, das du übersehen hast.
Warnsignale, die ein LeetCode-Screening nie zeigt
Die Fehlermuster, die in deiner Größe schmerzen, sind in Algorithmus-Screenings unsichtbar, und die meisten davon drehen sich um Erklärung.
Ein Kandidat, der nicht erklären kann, warum eine frühere Entscheidung getroffen wurde, jenseits von "das war Standard bei meinem letzten Arbeitgeber", wird Patterns auf dieselbe Weise in deine Codebasis importieren: ohne Begründung, die du später hinterfragen kannst.
Abwehrhaltung gegenüber altem Code ist das zweite. Jeder Entwickler mit echter Erfahrung hat Dinge ausgeliefert, die er heute nicht mehr mag. Frag, was sie an ihrem letzten großen Projekt ändern würden. Ein Senior antwortet mit einer Liste und etwas Bedauern. Ausweichen oder die Behauptung, das Design sei die ganze Zeit richtig gewesen, sagt dir, wie sich Code Review mit dieser Person auf der anderen Seite anfühlen wird.
Vage Incident-Geschichten sind das dritte. Frag nach dem schlimmsten Produktionsvorfall, dem sie nah waren. Du hörst auf konkrete Mechanik: was gebrochen ist, was sie in der ersten Stunde getan haben, was sich danach geändert hat. "Es gab mal einen großen Ausfall, das Team hat das geregelt" von einem angeblichen Senior bedeutet, dass er entweder aus der Distanz zugesehen hat oder seine eigene Argumentation nicht rekonstruieren kann. Beides ist nicht das, wofür du bezahlst.
Und achte darauf, ob sie je "Ich weiß es nicht" sagen. In einem 90-minütigen technischen Gespräch sollte der Satz mindestens einmal vorkommen. Sein völliges Fehlen ist selbst eine Antwort.
Referenzgespräche, die zutage bringen, was Kandidaten nicht sagen
Die meisten Referenzanrufe sammeln einstudiertes Lob, weil die Fragen dazu einladen. Ändere die Fragen. Frag eine frühere Führungskraft, welche Art von Arbeit sie dem Kandidaten irgendwann nicht mehr gegeben hat. Frag einen früheren Kollegen, wobei der Kandidat am meisten Unterstützung brauchte und wie er reagiert hat, als zuletzt jemand gegen sein Design gehalten hat. Schließe mit einer kalibrierten Version der Frage nach der erneuten Einstellung: "Würdest du diese Person wieder einstellen, als ersten Senior Engineer in einem Unternehmen mit zehn Leuten?" Die Pause vor der Antwort sagt oft mehr als die Antwort.
Bitte um eine Führungskraft und einen Kollegen. Ein Kandidat, der keinen einzigen früheren Kollegen benennen kann, der reden will, ist für sich schon eine Information.
Die Scorecard
Lege Dimensionen und Gewichte vor dem ersten Interview fest, bewerte unabhängig vor jedem Debriefing und schreibe einen Satz Evidenz pro Bewertung. Gruppendiskussion findet nach der Bewertung statt, nie davor, damit die lauteste Stimme im Raum nicht zu deinem faktischen Einstellungsmaßstab wird.
| Dimension | Gewicht | Wie eine 4 aussieht |
|---|---|---|
| Problem Framing | 30 % | Fragt nach Rahmenbedingungen, bevor er etwas vorschlägt; scoped die kleinste Version, die das Problem löst |
| Kommunikation | 25 % | Take-Home-Notiz liest sich wie die Übergabe eines Kollegen; erklärt Entscheidungen so, dass ein Nicht-Entwickler folgen kann |
| Technisches Urteilsvermögen | 25 % | Bindet jeden Trade-off an deine Größe; kann benennen, was die Antwort ändern würde |
| Codequalität | 20 % | Einreichung ist lesbar, getestet wo es zählt, ehrlich bei Abkürzungen |
Bewerte jede Dimension von 1 bis 4. Eine Einstellung braucht einen gewichteten Durchschnitt von 3,0 ohne Dimension unter 2, und ein Problem-Framing-Wert unter 3 sollte die Einstellung unabhängig vom Gesamtwert stoppen. Die 20 % Gewicht auf Codequalität sind bewusst gewählt. Sie ist die Dimension, die sich nach der Einstellung am leichtesten verbessern lässt, und die, die Gründer am stärksten übergewichten.
Die Stellenbeschreibung übernimmt die erste Filterung
Die Scorecard scheitert, wenn die falschen Leute die Pipeline füllen. Eine Stellenbeschreibung, die gut filtert, nennt den Stack mit Versionen, beschreibt zwei echte Probleme, die die Person in den ersten sechs Monaten besitzen wird, nennt die Teamgröße klar, enthält eine Gehaltsspanne und legt genau diesen Prozess mit seinem Zeitaufwand offen. Entwickler, die wollen, dass Unklarheit für sie absorbiert wird, lesen "du wirst Architekturentscheidungen in einem Unternehmen mit zehn Leuten verantworten" und sortieren sich selbst aus. Die, die du willst, bewerben sich wegen dieses Satzes.
Wo du Hilfe bei der Durchführung bekommst
Wolf-Tech hilft Gründern, diesen Senior Developer Interview Prozess von Anfang bis Ende durchzuführen: das Take-Home aus einem bereinigten Ausschnitt der echten Codebasis bauen, als technischer Interviewer am Architekturgespräch teilnehmen oder Einreichungen bewerten, wenn im Haus noch niemand Erfahrung mit Senior-Reviews hat. Und wenn die Suche plus eine deutsche Kündigungsfrist eine Lücke von einem halben Jahr hinterlässt, deckt unsere Arbeit in individueller Softwareentwicklung die Kapazität ab, bis die neue Person anfängt.
Wenn der erste Senior dieses Jahr auf deiner Roadmap steht, schreib an hello@wolf-tech.io oder schau auf wolf-tech.io vorbei. Ein einstündiges Gespräch, bevor du die Stelle ausschreibst, ist günstiger als drei Monate Interviews mit der falschen Pipeline.