Das Wichtigste in Kürze
- Die Prüfung eines Softwareentwicklers beginnt mit der Definition der Aufgabe und des benötigten Levels, nicht mit dem CV.
- Ein gutes technisches Interview kombiniert eine Praxisaufgabe, ein Code-Review und eine Systemdesign-Diskussion, abgestimmt auf die Seniorität des Kandidaten.
- Bei Remote-Entwicklern zählen Kommunikation und Englisch genauso viel wie der Code – prüfen Sie beides direkt im Interview.
- Vergleichen Sie Kandidaten mit dem Level, das die Aufgabe tatsächlich erfordert, und mit Ihrem Budget, statt automatisch die erfahrenste Person einzustellen.
- Bei DevKit interviewen Senior Engineers jeden Kandidaten und liefern Interview-Notizen, Level, Englisch, Zeitzone und Monatssatz mit – so können Sie frühe Screening-Runden überspringen.
Wie prüft man einen Softwareentwickler?
Um einen Softwareentwickler zu prüfen, definieren Sie zuerst Aufgabe und Level, sichten den CV auf Belege statt auf Keywords und führen dann ein technisches Interview mit Praxisaufgabe, Code-Review und Systemdesign-Diskussion, abgestimmt auf die Seniorität. Zum Abschluss prüfen Sie die Kommunikation, holen Referenzen ein und vereinbaren eine kurze Probezeit mit klaren Zielen.
Jeder Schritt beantwortet eine andere Frage. Die Rollendefinition zeigt, wie gute Arbeit aussieht. Das Interview zeigt, ob der Kandidat sie leisten kann. Referenzen und Probezeit zeigen, ob er sie in Ihrem Team auch dauerhaft leistet.
Definieren Sie zuerst die Aufgabe und das benötigte Level
Die meisten Fehler bei der Einstellung passieren vor dem ersten Interview. Halten Sie schriftlich fest, was der Entwickler in den ersten drei Monaten tun wird: Codebasis, Stack, zu lösende Probleme und wie viel Anleitung er bekommt. Daraus ergibt sich, ob Sie einen Junior, einen Mid-Level-Entwickler, einen Senior oder einen Tech Lead brauchen.
Seien Sie ehrlich beim Level. Ein Senior Engineer langweilt sich bei Routine-Features oft und ist dafür zu teuer, während ein Junior ohne Mentoring scheitert. Wählen Sie das Level passend zur Aufgabe – und erst dann passend zum Budget.
- Haupt-Stack sowie Muss- und Kann-Anforderungen
- Erwartete Verantwortung: Aufgaben, Features, Systeme oder das ganze Team
- Wer den Code reviewt und an wen die Person berichtet
- Erforderliche Überschneidung der Arbeitszeiten und Englischniveau
Warnsignale im CV beim Screening von Entwicklern
Ein CV ist ein Ausgangspunkt, kein Beweis. Suchen Sie nach konkreten Belegen dafür, was die Person gebaut hat und welche Rolle sie dabei hatte. Lange Technologielisten ohne Kontext sagen wenig aus.
Keines dieser Signale sollte allein zum Ausschluss führen, aber jedes verdient im Interview eine direkte Nachfrage.
- Skill-Listen, die jedes Framework nennen, während die Projektbeschreibungen keines davon erwähnen
- Vage Formulierungen wie „mitgearbeitet an“ oder „beteiligt an“ ohne Ergebnis oder Verantwortung
- Senioritätstitel, die nicht zum beschriebenen Aufgabenumfang passen
- Häufige, sehr kurze Einsätze ohne Erklärung
- Bei einer Senior-Rolle keine Erwähnung von Tests, Code-Reviews oder Produktivsupport
Checkliste fürs technische Interview: Aufbau nach Seniorität
Ein starkes technisches Interview hat drei Teile. Eine Praxisaufgabe zeigt, wie der Kandidat tatsächlich Code schreibt: Halten Sie sie kurz und nah an Ihrer echten Arbeit, und lassen Sie ihn seine Entscheidungen erläutern. Eine Code-Review-Übung, bei der er einen kleinen Pull Request mit eingebauten Fehlern prüft, zeigt Urteilsvermögen, Sorgfalt und die Art, wie er Feedback gibt.
Der dritte Teil ist das Systemdesign, und es sollte mit der Seniorität wachsen. Juniors können ihn überspringen oder eine einzelne Komponente besprechen. Mid-Level-Entwickler sollten ein Feature von Anfang bis Ende entwerfen. Seniors und Tech Leads sollten Abwägungen, Skalierung und Fehlerszenarien behandeln und erklären, wie sie ein Team durch die Umsetzung führen würden. Viele Teams fragen inzwischen auch, wie Kandidaten KI-Coding-Assistenten nutzen und wie sie generierten Code prüfen.
Kommunikation ist Teil des Interviews, kein separater Schritt. Prüfen Sie bei Remote-Entwicklern, ob sie eine technische Entscheidung klar auf Englisch erklären, bei unklaren Anforderungen die richtigen Fragen stellen und eine kurze, gut lesbare Zusammenfassung schreiben können.
| Level | Praxisaufgabe | Code-Review | Systemdesign | Kommunikation und Verantwortung |
|---|---|---|---|---|
| Junior | Sauberer, funktionierender Code für eine kleine, klar umrissene Aufgabe; grundlegende Tests | Erkennt offensichtliche Bugs und Benennungsprobleme | Nicht erforderlich oder eine einfache Komponente | Bittet früh um Hilfe, setzt Feedback um |
| Mid-Level | Baut ein vollständiges Feature mit Tests und sinnvoller Struktur | Findet Logik-, Edge-Case- und Lesbarkeitsprobleme | Entwirft ein Feature von Anfang bis Ende innerhalb eines bestehenden Systems | Arbeitet eigenständig an Aufgaben, begründet Entscheidungen klar |
| Senior | Löst ein unklar definiertes Problem und macht Abwägungen transparent | Spricht Design-, Performance- und Sicherheitsbedenken mit klarer Begründung an | Entwirft einen Service oder ein System inklusive Skalierung und Fehlerszenarien | Verantwortet Features bis in die Produktion, unterstützt andere als Mentor |
| Tech Lead | Prüft oder gestaltet eher einen Lösungsansatz, als ihn von Grund auf zu schreiben | Gibt Feedback, das die Standards des Teams verbessert | Legt die Architektur fest, plant Migrationen, balanciert Delivery und technische Schulden | Bringt Entwickler und Stakeholder zusammen, trifft und erklärt Entscheidungen |
Referenzen und Erwartungen an die Probezeit
Referenzen sind am nützlichsten, wenn Sie konkrete Fragen stellen: Wofür war die Person verantwortlich, wie ist sie mit einem Produktionsproblem umgegangen, würden Sie wieder mit ihr arbeiten? Allgemeines Lob sagt wenig aus – achten Sie auf konkrete Beispiele.
Die Probezeit ist die letzte Prüfung. Legen Sie für die ersten Wochen zwei oder drei klare Ziele fest, etwa ein kleines Feature ausliefern, einen Code-Review-Zyklus durchlaufen und an Rufbereitschaft oder Standups teilnehmen, und besprechen Sie den Fortschritt gemeinsam. Erwarten Sie nicht sofort volles Tempo; achten Sie auf eine stetige Einarbeitung, gute Fragen und Code, der das Review besteht.
Wie Sie Entwickler-Kandidaten mit Ihrem Budget abgleichen
Bewerten Sie jeden Kandidaten nach denselben Kriterien aus Ihrer Rollendefinition – anhand der Interview-Notizen, nicht aus dem Gedächtnis. Vergleichen Sie das Ergebnis dann mit den Kosten. Die beste Wahl ist der Kandidat, der das von der Aufgabe geforderte Level zu einem für Sie tragbaren Satz erfüllt – nicht automatisch der erfahrenste.
Liegen zwei Kandidaten nah beieinander, entscheiden Sie sich bei einer Remote-Rolle für den mit der besseren Kommunikation und der größeren Überschneidung der Arbeitszeiten. Erfüllt niemand die Anforderungen, suchen Sie weiter, statt den Anspruch zu senken.
Wie eine Prüfung durch Engineers Ihnen Zeit spart
Diesen Prozess für jeden Kandidaten vollständig durchzuführen, kostet echte Engineering-Zeit – oft die knappste Ressource im Team. Wenn Sie einen starken internen Einstellungsprozess und die Zeit dafür haben, behalten Sie ihn bei. Wenn nicht, kann ein Staffing-Partner Ihnen den Großteil der Arbeit abnehmen.
Bei DevKit besteht jeder Kandidat ein technisches Interview mit unseren Senior Engineers. Jedes Profil enthält Interview-Notizen, Level, Englisch, Zeitzone, Verfügbarkeit und einen klaren Monatssatz – Sie starten also mit Belegen statt mit einem bloßen CV. Wir vermitteln Ihnen Entwickler aus unserem eigenen Team und privaten Netzwerk, darunter Senior-Profis, die kaum auf Jobbörsen zu finden sind, liefern die Shortlist mit CVs in 3–5 Werktagen und bieten kostenlosen Ersatz inklusive Übergabe, falls ein Entwickler nicht passt.
Sprechen Sie mit uns über Ihren Personalbedarf
Nennen Sie uns die Rollen, die Sie besetzen möchten. Wir antworten innerhalb eines Werktags und senden Ihnen geprüfte CVs in 3–5 Tagen.
hi@devkit.agency