Fullstack-Entwickler:in – Interviewfragen & Gehalt
Als Fullstack-Entwickler:in verdient man in Deutschland im Median 60.000 € brutto im Jahr; die mittlere Hälfte der Gehälter liegt zwischen 50.000 € und 75.000 €.
Auf einen Blick
- Mediangehalt60.000 €
- Einstellungsdauer50–80 Tage
- Erfahrung3–6 Jahre
Gehalt für Fullstack-Entwickler:in
Festgehalt, brutto pro Jahr
- 25. Perzentil
- 50.000 €
- Median
- 60.000 €
- 75. Perzentil
- 75.000 €
| Level | 25. Perzentil | Median | 75. Perzentil |
|---|---|---|---|
| Einstieg | 38.000 € | 44.000 € | 52.000 € |
| Mittlere Erfahrung | 50.000 € | 60.000 € | 75.000 € |
| Senior | 68.000 € | 80.000 € | 100.000 € |
Zum Vergleich: Der gesetzliche Mindestlohn in Deutschland liegt seit 1. Januar 2026 bei 13,90 € brutto pro Stunde — bei einer Vollzeitstelle mit 40 Wochenstunden rund 2.410 € brutto im Monat. (BMAS: Mindestlohn steigt zum 1. Januar 2026 auf 13,90 Euro)
Bruttofixgehalt pro Jahr für eine:n Fullstack-Entwickler:in auf Mid-Level (3 bis 6 Jahre Berufserfahrung) im deutschen KMU oder Mittelstand. Berlin, München und Hamburg im SaaS-/Scale-up-Umfeld ziehen nach oben (70-90 k€), klassischer Mittelstand und Provinzstandorte tendenziell nach unten (45-55 k€). Moderner Stack (React + Node oder Python, Postgres, Kubernetes) zieht nach oben; Legacy-Stack (klassisches PHP, jQuery, ältere Java-Monolithen) zieht nach unten. Engineering-Rollen in Deutschland haben in der Regel keinen variablen Vergütungsanteil; Scale-ups bieten ergänzend VSOP/ESOP.
Quellen: Stepstone Gehaltsdaten Fullstack-Entwickler:in Deutschland 2026; Stepstone Gehaltsreport 2026; Honeypot State of Software Engineering Germany 2025; Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe
So stellen Sie eine:n Fullstack-Entwickler:in für Ihr KMU ein
Bevor Sie die Stellenausschreibung schreiben, klären Sie drei Fragen. Sie entscheiden, welches Profil Sie tatsächlich suchen, und vermeiden die häufigsten Fehler bei Tech-Einstellungen im deutschen KMU.
Frage 1: Fullstack oder Spezialist:in? Fullstack-Entwickler:innen decken Frontend und Backend auf mittlerem bis fortgeschrittenem Niveau ab; reine Spezialist:innen (Frontend-only, Backend-only) sind in ihrem Bereich tiefer. In Tech-KMUs mit weniger als 10 Entwickler:innen ist Fullstack fast immer die richtige Wahl: Spezialisierung lohnt sich erst ab einer gewissen Teamgröße und Produktkomplexität. Bei Unsicherheit nehmen Sie Fullstack mit leichter Färbung (eher Frontend-orientiert oder eher Backend-orientiert) je nach aktuellem Bedarf.
Frage 2: Welchen Stack haben Sie und wie reif ist er? Ein:e gute:r Entwickler:in mit React, Node und Postgres wird nicht sofort auf Vue, Python und MongoDB produktiv, sondern braucht 2 bis 4 Wochen Einarbeitung. Für ein Mid-Level-Profil zählt Stack-Fit mehr als absolute Seniorität. Stellen Sie Ihren Stack prominent in der Ausschreibung dar; das filtert schlecht passende Profile automatisch aus. Wenn Ihr Stack als Legacy gilt (klassisches PHP, jQuery, ältere Java-Monolithen), kommunizieren Sie das offen und suchen gezielt Profile, die Codebase-Modernisierung mögen, statt enttäuschte Wechsler:innen zu importieren.
Frage 3: Wie viel Prozent der Zeit fließt in eigenständige technische Entscheidungen? In einem Early-Stage-KMU (weniger als 5 Entwickler:innen) trifft ein:e Mid-Level-Fullstack-Entwickler:in regelmäßig Architekturentscheidungen (Library-Wahl, Design eines neuen Services, Refactor kritischer Zonen). In einem etablierten KMU (mehr als 15 Entwickler:innen) führt sie:er stärker in einem bereits durch eine:n Tech Lead gesetzten Rahmen aus. Das ideale Profil unterscheidet sich: Autonomie und Findigkeit im ersten Fall, Ausführungsqualität und Zusammenarbeit im zweiten. Klären Sie diese Dimension bereits in der Ausschreibung.
Wenn alle drei Antworten auf eine:n Fullstack-Entwickler:in in Vollzeit (und nicht auf eine:n Spezialist:in oder Tech Lead) deuten, finden Sie die passende Vorlage in der Stellenbeschreibung weiter unten.
Stellenbeschreibung Fullstack-Entwickler:in als Vorlage
[Firmenname], B2B-KMU [Branche] mit Sitz in [Stadt], [X] Mitarbeitende, [X] Mio. € ARR, sucht eine:n Fullstack-Entwickler:in zur Verstärkung eines Tech-Teams von [X] Entwickler:innen.
Ihre Aufgabe
Sie entwerfen, entwickeln und pflegen Produkt-Features über den gesamten Stack ([Frontend und Backend und Datenbank]), eigenständig auf bekannten Themen und in Abstimmung bei strukturierenden Entscheidungen. Sie berichten an die [Tech Lead / CTO / Technische Geschäftsführung].
Hauptverantwortlichkeiten
- Features von Anfang bis Ende liefern: Verständnis des Produktbedarfs, technisches Design, Implementierung Frontend und Backend, Tests, Deployment, Begleitung in Produktion.
- An Architekturentscheidungen in Ihrem Verantwortungsbereich mitwirken (Library-Wahl, Refactor, Design eines neuen Services).
- Code-Qualität sichern: Review der PRs der Kolleg:innen, Anwendung der Konventionen, Refactor im Vorbeigehen, wenn sinnvoll.
- Bei der Behebung von Produktionsvorfällen mitwirken (On-Call oder Bereitschaft je nach Organisation).
- Wichtige technische Entscheidungen und nicht-triviale Komplexitätszonen dokumentieren.
- Mit PM, Design und Geschäftsführung an Produkt-Briefings zusammenarbeiten; nicht machbare oder kontraproduktive Vorgaben konstruktiv hinterfragen.
Profil
- Unverzichtbar: [3 bis 6] Jahre professionelle Erfahrung in der Webentwicklung; solide Beherrschung mindestens eines modernen Frontend-Frameworks (React, Vue, Svelte) und Backend-Frameworks (Node, Python, Ruby, Go oder vergleichbar); Erfahrung mit Produktionsbetrieb (Deployment, Monitoring, Incident-Bearbeitung).
- Wünschenswert: Vertrautheit mit unserem Stack [React und Node / Python / andere]; Erfahrung im KMU oder Startup (hohe Autonomie); Open-Source-Beiträge oder sichtbare Side-Projects.
- Disqualifizierend: keine Erfahrung mit eigenständigem Produktionsbetrieb; Weigerung, Frontend oder Backend anzufassen; pauschale Ablehnung moderner Frameworks.
Was wir bieten
- Bruttojahresvergütung: [50-75] k€ je nach Erfahrung. Kein struktureller Variabel-Anteil; eventuell VSOP / ESOP je nach Phase des Unternehmens.
- Modell: [Vollzeit, hybrid 2-3 Tage / Woche vor Ort, Basis in [Stadt] / remote-friendly].
- Benefits: [betriebliche Altersvorsorge, Fahrrad-Leasing, Mitarbeiterbeteiligung, Urlaubstage, Homeoffice-Policy, Hardware-Budget, Weiterbildungsbudget].
- Stack: [zu ergänzen: Frontend, Backend, DB, Infra, CI/CD, Monitoring].
Sie besetzen diese Stelle? Job Studio macht aus der Vorlage eine fertige Stellenanzeige, mit Gehaltsvorschlag und Bewerbungsformular.
Interviewfragen für Fullstack-Entwickler:in
15 strukturierte Fragen, nach Typ gruppiert. Jede nennt die Kompetenz, die sie prüft; aufgeklappt sehen Sie, woran Sie eine starke Antwort erkennen.
Verhaltensbezogen 3
Beschreiben Sie die schwierigste technische Entscheidung Ihrer letzten Position. Warum war sie schwierig und wie haben Sie sie getroffen?
Technische EntscheidungsfindungWorauf eine starke Antwort hinweist
Fähigkeit, eine Entscheidung unter Unsicherheit zu strukturieren: Identifikation der Bedingungen, expliziter Abwägungen, Konsultation der betroffenen Personen, nachträgliche Validierung mit Daten. Bonus: die:der Kandidat:in erwähnt, im Verlauf die Meinung geändert oder die Entscheidung für die Zukunft dokumentiert zu haben. Wer rückblickend eine offensichtliche Entscheidung beschreibt, hat selten ernsthaft abgewogen.
Erzählen Sie mir von einem Production-Bug, den Sie behoben haben. Was war das Symptom, wie haben Sie diagnostiziert und wie lange hat es gedauert?
Debugging und InvestigationWorauf eine starke Antwort hinweist
Strukturierte Debug-Methode: Reproduktion, Logs, Instrumentierung, durch Experiment validierte Hypothesen. Ehrlichkeit zur Dauer (ein echter Production-Bug ist selten in unter 30 Min. erledigt). Bonus: die:der Kandidat:in nennt die Grundursache und den systemischen Fix, nicht nur den Hotfix. Antworten wie „Ich habe den Service neu gestartet“ ohne Diagnose deuten auf schwache Investigationsfähigkeit.
Beschreiben Sie einen Moment, in dem Sie Code refactorn oder umschreiben mussten, den Sie selbst wenige Monate zuvor geschrieben hatten. Was war in der Zwischenzeit passiert?
Lernfähigkeit und DemutWorauf eine starke Antwort hinweist
Technische Demut und Lernfähigkeit. Bonus: die:der Kandidat:in benennt, was sie:er heute von Anfang an anders machen würde. Wer noch nie eigenen Code wirklich refactorn musste, lügt oder hat Code nie über längere Zeit in Produktion gehalten.
Situativ 3
Sie entdecken in einer Code-Review eine Sicherheitslücke (SQL-Injection, Secret im Klartext, fehlende Auth-Prüfung) in einem PR einer Senior-Kollegin oder eines Senior-Kollegen. Wie reagieren Sie?
Technischer MutWorauf eine starke Antwort hinweist
Fähigkeit, eine technische Schwäche aufzuzeigen, ohne zu blockieren: sachlicher Kommentar im PR (hier ist das Risiko, hier mein Lösungsvorschlag), Lösungsangebot, Eskalation an Tech Lead, falls der PR trotz Kommentar gemergt wird. Wer es laufen lässt, weil das Profil senior ist, zeigt mangelnden technischen Mut.
Ein:e Product Manager:in verlangt ein Feature, das nach Ihrer Einschätzung 3 Wochen dauert. Die PM-Person will es in einer Woche. Wie reagieren Sie?
Kommunikation mit ProduktWorauf eine starke Antwort hinweist
Klärung des Bedarfs vor der Timeline-Verhandlung (eventuell lässt sich das Feature in zwei Phasen liefern oder vereinfachen). Optionen anbieten: MVP in einer Woche plus V2 in zwei Wochen, expliziter Scope-Cut, zusätzliche Ressourcen. Antworten wie „Ich schaffe das in einer Woche, wenn ich am Wochenende arbeite“ sind ein Warnsignal (mangelnde Selbstführung).
Sie kommen in ein Team mit erheblicher technischer Schuld: unzureichende Tests, manuelle Deployments, kaum Monitoring. Wie sieht Ihr 30-Tage-Plan aus?
Pragmatismus und PriorisierungWorauf eine starke Antwort hinweist
Zuerst Diagnose: nicht alles gleichzeitig reparieren wollen. Priorisierung nach Risiko und Wirkung (typisch: zuerst Monitoring zum Sehen, dann Tests in kritischen Zonen, dann Deployment-Automatisierung). Abstimmung mit Team und Tech Lead vor jeder Maßnahme. Wer sich direkt in eine vollständige Neuentwicklung stürzt, zeigt mangelnden Pragmatismus.
Case 3
Design: wir wollen in unsere Anwendung Echtzeit-Benachrichtigungen ergänzen (Beispiel: eine Kollegin hat Ihr Dokument kommentiert). Wie entwerfen Sie das?
System-DesignWorauf eine starke Antwort hinweist
Klärung vor dem Vorschlag (erwartetes Volumen, Latenzanforderungen, unterstützte Geräte, Persistenz ungelesener Benachrichtigungen). Kohärente Architektur: Push (WebSocket oder Server-Sent Events) vs. Pull (Polling), Persistenz (Notification-DB), Idempotenz, E-Mail-Fallback. Bonus: Anerkennung der Unsicherheitszonen (Ich würde einen POC machen, bevor ich mich zwischen WebSocket und SSE festlege). Wer ohne Klärung sofort in den Code springt, zeigt eine Design-Schwäche.
Debug: Ihre API liefert auf 2 % der Anfragen eine 500. Die Logs zeigen keinen offensichtlichen Fehler. Wie gehen Sie vor?
Debugging und InvestigationWorauf eine starke Antwort hinweist
Strukturierte Methode: (1) Log-Level auf den betroffenen Endpoints temporär erhöhen, (2) mit Metriken korrelieren (Latenz, Payload-Größe, Quelle), (3) Pattern identifizieren (Tageszeit, Request-Typ, bestimmte:r Nutzer:in), (4) Hypothesen ordnen (DB-Timeout, Race Condition, Speicher). Wer sofort auf „wird wohl die DB sein“ springt, ohne zu investigieren, hat einen Bias.
Performance: eine Seite Ihrer Anwendung braucht 8 Sekunden zum Laden. Sie haben eine Woche Zeit, sie unter 2 Sekunden zu drücken. Aktionsplan?
OptimierungWorauf eine starke Antwort hinweist
Vor dem Optimieren messen: DevTools, Lighthouse, Server-Profiler. Bottleneck identifizieren (Rendering, DB-Queries, Payload, CDN). Nach Aufwand mal Wirkung priorisieren. Antworten wie „Ich baue Caching ein“ ohne Diagnose deuten auf vorzeitige Optimierung. Bonus: erkennen, dass 8 Sekunden in Produktion meist auf ein systemisches Problem hinweisen (N+1-Queries, riesige Payload), nicht auf eine lokale Optimierung.
Fachlich 3
Wie ist Ihre Test-Strategie? Beschreiben Sie Ihr letztes Projekt: wie viele Tests, welche Typen, welche Coverage und was haben Sie wirklich gemessen?
Code-QualitätWorauf eine starke Antwort hinweist
Verständnis der Test-Pyramide (viele Unit-Tests, weniger Integrations-Tests, wenige E2E). Unterscheidung zwischen Coverage und Nutzen (90 % Coverage auf trivialem Code zählt weniger als 60 % auf kritischer Geschäftslogik). Bonus: die:der Kandidat:in nennt einen Fall, in dem ein Test eine reale Regression verhindert hat. Wer einfach „100 % Coverage“ ohne Differenzierung antwortet, zeigt schwaches Urteilsvermögen.
Was ist der Unterschied zwischen einer DB-Transaktion und einem Application-Lock? Wann setzen Sie das eine, wann das andere ein?
Backend-FundamentWorauf eine starke Antwort hinweist
DB-Transaktion: Atomarität und Isolation werden von der DB gemanagt (ACID), begrenzt auf die Transaktionsdauer. Application-Lock: Koordination zwischen Prozessen oder Instanzen über Redis, ZooKeeper oder ähnliches; nützlich, wenn die Koordination über eine einzelne DB hinausgeht (Microservices, Task-Queue). Deadlock-Risiko bei beiden. Wer die beiden Mechanismen nicht trennen kann, baut in Produktion Race Conditions ein.
Sie kommen in eine schlecht organisierte React-Codebase: Komponenten mit 500 Zeilen, Props-Drilling über 5 Ebenen, keine Trennung von Logik und Darstellung. Aktionsplan in 60 Tagen, ohne alles zu brechen?
Pragmatismus und PriorisierungWorauf eine starke Antwort hinweist
Schrittweises Vorgehen: (1) kritische Komponenten und wiederkehrende Patterns kartieren, (2) zuerst Hooks und Business-Logik extrahieren (großer Hebel, geringes Risiko), (3) große Komponenten entlang fachlicher Grenzen zerlegen, nicht entlang technischer Schemata, (4) State-Manager nur dort einführen, wo Props-Drilling tatsächlich wehtut (Context oder Zustand im KMU, Redux ab größerem Volumen). Wer sofort alles auf React Server Components umstellen will, zeigt fehlenden Pragmatismus.
Werte 3
Wie nehmen Sie eine kritische Code-Review zu Code auf, von dem Sie überzeugt waren, dass er gut ist?
CoachabilityWorauf eine starke Antwort hinweist
Offenheit: Fähigkeit, Code vom persönlichen Ego zu trennen. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er durch eine Review tatsächlich umgedacht hat. Wer beschreibt, der:dem Reviewer:in die eigene Logik erklärt zu haben, anstatt zuzuhören, zeigt eine Schwäche in der Coachability; im KMU mit kleinem Tech-Team ist das ein hartes K.o.-Signal.
Welche Rolle spielen Sie bei der technischen Weitergabe an Junior-Profile oder neue Teammitglieder?
Mentoring und WeitergabeWorauf eine starke Antwort hinweist
Aktive Mentorenhaltung: Pair-Programming, pädagogische Reviews (nicht nur ok merge), Dokumentation von Entscheidungen, Weitergabe guter Praktiken. Wer sagt „Ich helfe, wenn ich gefragt werde“, ohne mehr Konkretes, zeigt eine passive Haltung. Im KMU mit kleinem Tech-Team ist die Fähigkeit zur Weitergabe entscheidend für die Nachhaltigkeit des Teams.
Wie arbeiten Sie mit Product Manager:innen und Designer:innen zusammen? Beschreiben Sie eine Situation, in der Sie einem Briefing widersprochen haben.
Teamspiel ProduktWorauf eine starke Antwort hinweist
Partnerschaftliche Haltung: konstruktives Hinterfragen auf Basis von Machbarkeit oder Komplexität, Alternativvorschläge. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er das ursprüngliche Briefing nach Austausch akzeptiert hat (keine systematische Opposition). Wer PMs oder Designer:innen als „verstehen die Technik nicht“ beschreibt, zeigt Schwäche im Teamspiel.
Gehalt und Einstellung nach Level
Dieselbe Rolle auf jedem Level: was sie kostet, wie viel Erfahrung Sie erwarten können und wie lange die Suche meist dauert.
Junior-Fullstack-Entwickler:in
- Festgehalt, brutto pro Jahr
- 44.000 €38.000 € – 52.000 €
- Erfahrung
- 0–2 Jahre
- Einstellungsdauer
- 35–60 Tage
Fullstack-Entwickler:in (Mittlere Erfahrung)
- Festgehalt, brutto pro Jahr
- 60.000 €50.000 € – 75.000 €
- Erfahrung
- 3–6 Jahre
- Einstellungsdauer
- 50–80 Tage
Senior-Fullstack-Entwickler:in
- Festgehalt, brutto pro Jahr
- 80.000 €68.000 € – 100.000 €
- Erfahrung
- 7–12 Jahre
- Einstellungsdauer
- 60–95 Tage
Gehalt für Fullstack-Entwickler:in im Ländervergleich
Dieselbe Rolle auf demselben Level in jedem Markt, den wir abdecken, jeweils nach Quellen aus dem Land selbst.
| Land | Untergrenze | Üblich | Obergrenze |
|---|---|---|---|
| DeutschlandDiese Seite | 50.000 € | 60.000 € | 75.000 € |
| FrankreichFrançais | 45.000 € | 55.000 € | 70.000 € |
| SpanienEspañol | 38.000 € | 48.000 € | 60.000 € |
| NiederlandeNederlands | 48.888 € | 57.600 € | 66.300 € |
| ItalienItalianoMilano · sviluppo software · Junior Developer · 2–5 anni di esperienza | 33.000 € | — | 38.000 € |
Quellen
- Frankreich (abgerufen im Mai 2026): APEC, Baromètre 2025 de la rémunération des cadres tech · INSEE, DADS 2024 (PCS 388a, Ingénieurs informatiques) · Talent.io, Étude rémunération tech France 2025
- Spanien (abgerufen im Mai 2026): INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) · InfoJobs, Estado del Mercado Laboral en España 2025 · Honeypot State of Software Engineering Spain 2025
- Niederlande (abgerufen im August 2026): Nationale Vacaturebank — salaris Full stack developer in Nederland · Indeed — salaris Developer in Nederland
- Italien (abgerufen im Oktober 2026): Hays Italia Salary Guide 2026, Technology, Digital & New Media — Software Development, p. 70 (PDF Hays ospitato da QualEnergia) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
Wo Sie diese Rolle finden
LinkedIn
Recruiter Lite ab 170 € / Monat, plus 200-400 € / Monat für Job SlotsDer wichtigste aktive Sourcing-Kanal für Tech-Profile in Deutschland. Aktives Sourcing über Recruiter Lite plus personalisierte InMails ist deutlich wirksamer als reine Job Posts: gute Fullstack-Profile schauen kaum noch in den Jobs-Feed. Filtern Sie präzise auf Ihren Stack (React + Node oder Python + Postgres) und Seniorität, bevor Sie anschreiben. Generische Outreach-Sequenzen erreichen Antwortquoten unter 5 %; personalisierte Nachrichten mit klarem Stack- und Produktbezug liegen bei 15-25 %.
XING
ProJobs ab 195 € / MonatFür Tech-Profile im klassischen Mittelstand außerhalb der Berliner Startup-Szene weiterhin relevant, vor allem in NRW, Bayern und Baden-Württemberg. Besonders für Fullstack-Profile zwischen 30 und 45 Jahren, die ihr LinkedIn-Profil nicht aktiv pflegen, eine gute Ergänzung. In klassischen Industriebranchen (Maschinenbau, Industrie 4.0, traditioneller Handel) oft pari mit LinkedIn oder besser. Für reine Startup-/Scale-up-Stack-Profile schwächeres Signal.
Honeypot, GitHub Jobs Nachfolger, niche Tech-Boards
Honeypot Erfolgshonorar 15 % des Jahresfixgehalts; niche Boards 200-500 € pro AnzeigeHoneypot ist die DE-spezifische Tech-Reverse-Recruiting-Plattform: Entwickler:innen erstellen Profile, Unternehmen bewerben sich. Funktioniert besonders für Senior-Profile, die nicht aktiv suchen, aber offen für Wechsel sind. Ergänzend: Stack-spezifische Boards (German Tech Jobs, We Are Developers) und GitHub-Sponsorings für sichtbare Open-Source-Profile. Insgesamt geringeres Volumen als LinkedIn/XING, aber höhere Signalqualität pro Kontakt; gut zum Auffüllen einer LinkedIn-getriebenen Pipeline.
Evaluations-Playbook
Die Rolle der Fullstack-Entwickler:in zeigt sich über fünf Evaluations-Stufen. Die Praxisaufgabe (Stufe 3) muss realistisch und zeitlich begrenzt sein: eine 8-Stunden-Aufgabe braucht in Wirklichkeit 24 Stunden, demotiviert gute Profile und liefert kein besseres Signal als eine gut konstruierte Aufgabe von 2-3 Stunden.
Stufe 1: Lebenslauf-Lektüre
Suchen Sie nach Stack-Konsistenz (ein Profil mit React und Python wechselt nicht ohne 3-6 Monate Einarbeitung zu Java zurück), Stabilität (mindestens 18-24 Monate auf vorherigen Positionen) und Autonomiesignalen (eigene Projekte, Open-Source-Beiträge, sichtbares GitHub). Der Abschluss zählt weniger als die letzten 3-5 Jahre Praxis: ein:e Autodidakt:in mit 5 Jahren solider Produktionserfahrung zählt mehr als ein:e Top-Uni-Absolvent:in mit 2 Jahren verlängertem Praktikum.
Stufe 2: Phone Screen (30 Min.)
Nur drei Fragen: (1) Beschreiben Sie das jüngste Projekt, auf das Sie am stolzesten sind; was war Ihr konkreter Beitrag?, (2) Welche technische Entscheidung haben Sie kürzlich getroffen, an der Sie noch zweifeln? (Demut und Reflexion), (3) Warum suchen Sie jetzt einen Wechsel? Ergebnis: Go/No-Go in 5 Min. Debrief. Vermeiden Sie technische Gotcha-Fragen auf dieser Stufe.
Stufe 3: Technisches Interview (60-90 Min.)
Pair-Programming oder Code-Review auf einer begrenzten Aufgabe (45-60 Min.), gefolgt von 15-30 Min. Q&A zu Architektur und technischen Entscheidungen. Bewerten Sie die Fähigkeit, laut zu denken, Klärungsfragen zu stellen und zu iterieren. Vermeiden Sie rein akademische Algorithmen ohne Bezug zum Alltag; bevorzugen Sie Aufgaben, die dem Tagesgeschäft ähneln (Refactoring, Hinzufügen eines Features, Debug eines nicht abgedeckten Falles).
Stufe 4: System-Design-Übung (60 Min.)
Architektur-Diskussion zu einem konkreten Fall: Wie würden Sie ein System für [produktspezifische Funktion] entwerfen? Bewerten Sie die Fähigkeit, Bedingungen vor dem Vorschlag zu klären, zwischen Einfachheit und Skalierbarkeit abzuwägen und Unsicherheitszonen zu erkennen. Dies ist die prädiktivste Stufe für eine:n Fullstack-Entwickler:in, die:der im KMU eigenständig technische Entscheidungen treffen muss.
Stufe 5: Referenzen (strukturierte Überprüfung)
Rufen Sie zwei Referenzen an: eine:n ehemalige:n Tech Lead oder direkte:n Vorgesetzte:n und eine:n ehemalige:n Entwickler:innen-Kolleg:in. Stellen Sie beiden dieselben 4 Fragen: Worin ist sie:er am stärksten? Worin würden Sie eine ergänzende Person einstellen? Würden Sie sie:ihn morgen wieder einstellen, warum? Ein Beispiel einer schwierigen technischen Entscheidung in Eigenverantwortung? Die 4. Frage liefert das eigentliche Autonomie-Signal.
Woran Sie eine hervorragende Besetzung erkennen
| Kompetenz | Unter Anforderung | Auf Niveau | Über Anforderung |
|---|---|---|---|
| Technische Solidität | Stolpert über Fundamente (HTTP, DB-Transaktionen, Asynchronität). Sucht Lösungen durch Versuch und Irrtum ohne klares mentales Modell. Tut sich schwer mit dem Wechsel auf eine neue Sprache oder ein neues Framework. | Beherrscht den aktuellen Stack eigenständig. Kann ein neues Framework in 2-4 Wochen lernen. Versteht die Fundamente gut genug, um bei Bedarf tief zu debuggen. | Referenzperson für den Stack im Team und in der Lage, innerhalb weniger Wochen auf einen neuen Stack umzusteigen. Antizipiert klassische Fallen (Race Conditions, Memory Leaks, Edge Cases). Baut nützliche, nicht verfrühte Abstraktionen. |
| System-Design und Pragmatismus | Springt ohne Klärung der Bedingungen in den Code. Überarchitekturiert (Microservices für ein MVP) oder unterarchitekturiert (Spaghetti-Monolith mit 50 k LOC). Tut sich schwer beim Abwägen zwischen Einfachheit und Skalierbarkeit. | Klärt den Bedarf vor dem Coden. Pragmatisch beim Abwägen: keine vorzeitige Architektur für unsichere Zukunft, identifiziert aber Zonen, in denen ein wenig Struktur sich auszahlt. Kann pivotieren, wenn die Ausgangshypothese nicht hält. | Entwirft Systeme, die gut altern: gut gewählte Abstraktionen, minimale Abhängigkeiten, klare fachliche Grenzen. Erkennt eigene Unsicherheitszonen und schlägt gezielte POCs vor. Trainiert das Team in systemischem Denken. |
| Code-Qualität und Hygiene | Keine klare Test-Strategie; fügt Tests hinzu, um Coverage zu produzieren. Schlecht strukturierter Code (Komponenten mit 500 Zeilen, Copy-Paste, Magic Numbers). Oberflächliche Reviews. | Pyramide an Tests passend zu den fachlich kritischen Zonen. Lesbarer Code mit klarem Naming und kurzen Funktionen. Strukturierte Reviews mit umsetzbarem Feedback. Refactort im Vorbeigehen, wenn sinnvoll. | Referenz im Team für Qualität: dokumentierte Konventionen, Automatisierung der Prüfungen (Linter, Type-Checker, CI). Pädagogische Reviews, die Junior-Profile weiterentwickeln. Kann nein sagen zu Code, der die Tests besteht, aber schlecht altert. |
| Autonomie und Findigkeit | Blockiert sich stundenlang auf einem unbekannten Thema, ohne um Hilfe zu bitten, oder fragt bei jedem Hindernis sofort. Keine strukturierte Debug-Strategie. | Kann auf bekannten Themen eigenständig diagnostizieren; fragt nach vorheriger Untersuchung um Hilfe (Zusammenfassung des Problems, Hypothesen, was bereits versucht wurde). | Hohe Findigkeit auf unbekannten Themen: liest den Quellcode der Abhängigkeiten, instrumentiert die Runtime, isoliert Grundursachen. Dokumentiert die Erkenntnisse für das Team. |
| Kommunikation und Teamspiel | Erklärt die eigene Arbeit Nicht-Techniker:innen schlecht. Defensive Haltung in Reviews. Arbeitet im Silo, teilt wenig Kontext. Systematische Opposition gegenüber PMs oder Designer:innen. | Kann die eigene Arbeit gegenüber PM oder Geschäftsführung in klarer Sprache erklären. Nimmt Reviews konstruktiv auf. Teilt Kontext in Team-Reviews und 1:1. | Brücke zwischen Tech und anderen Funktionen. Moderiert technische Debriefs, macht Abwägungen verständlich, verhandelt Timelines transparent. Referenz im Team für übergreifende Kommunikation. |
Häufige Fehler bei der Besetzung dieser Rolle
Nach Konzern-Pedigree statt nach operativer Ramp einstellen
Ein:e Top-Absolvent:in einer renommierten Hochschule mit 2 Jahren bei einem DAX-Konzern oder einer Big-Tech-Niederlassung ist nicht automatisch produktiver als ein:e Autodidakt:in mit 5 Jahren Produktionspraxis in einem Startup oder KMU. Große Strukturen liefern ihren Entwickler:innen klare Specs, anspruchsvolle Reviews und solides Tooling; im KMU fehlt dieses Gerüst meist, und die fehlende Autonomie wird zur Belastung. Gewichten Sie das technische Praxisinterview und die System-Design-Übung stärker als das Pedigree im Lebenslauf.
Algorithmische Fundamente bei einer Produktrolle überbewerten
Ein:e Fullstack-Entwickler:in im KMU muss fast nie einen Graph-Algorithmus optimieren oder einen B-Baum neu implementieren. LeetCode-artige Aufgaben bevorzugen akademische Profile zulasten der operativen (die ein vollständiges Feature in Eigenverantwortung liefern können). Bevorzugen Sie Aufgaben, die dem Tagesgeschäft ähneln: ein Feature ergänzen, einen nicht abgedeckten Fall debuggen, eine überladene Komponente refactorn. Reine LeetCode-Hard-Filter sind im KMU kontraproduktiv.
Mehrtägige Take-Home-Aufgaben verlangen
Eine Take-Home-Aufgabe mit 8 oder mehr Stunden nimmt in Wirklichkeit 24 Stunden in Anspruch (mit emotionalem Investment), demotiviert die besten Profile (die parallel andere Optionen haben) und liefert kein besseres Signal als eine gut konstruierte Aufgabe von 2-3 Stunden. Messen Sie die Qualität der Argumentation, nicht die Vollständigkeit. Begrenzen Sie die erwartete Zeit explizit und akzeptieren Sie unvollständige, aber gut begründete Lösungen.
Stack- und Ökosystem-Fit unterschätzen
Ein:e gute:r React- und Node-Entwickler:in ist nicht sofort auf Vue und Python produktiv, sondern braucht 2-4 Wochen Einarbeitung. Ein Profil mit nahem Stack (React, TypeScript, Postgres für ein KMU mit demselben Stack) ist bereits in 1-2 Wochen produktiv. Stack-Fit zählt für ein Mid-Level-Fullstack-Profil mehr als die absolute Seniorität. Stellen Sie Ihren Stack prominent in der Ausschreibung dar; das filtert automatisch schlecht passende Profile aus.
Übergreifende Kommunikation unterschätzen
Ein:e Fullstack-Entwickler:in im KMU spricht fast täglich mit PMs, Designer:innen, manchmal direkt mit Geschäftsführung oder Kund:innen. Wer technisch stark ist, aber in der übergreifenden Kommunikation schwach, produziert Reibung: missverstandene Briefings, intransparente Timelines, Konflikte mit dem Produkt. Bewerten Sie die Kommunikation explizit im Interview (situative Fragen mit PM-Bezug, Erklärung eines technischen Themas in Alltagssprache).