Vorstellungsgespräch als Backend Developer: Fragen und Antworten

Du sitzt vor deinem Laptop, das Interview für die Backend-Stelle startet in fünf Minuten, und dein Magen dreht sich. Du hast den Code geschrieben, du kannst die Systeme erklären, aber du weißt nicht, welche Fragen kommen und wie du deine Erfahrung rüberbringst. Dieses flaue Gefühl ist normal. Aber es ist auch vermeidbar, wenn du weißt, was dich erwartet.

Die drei Phasen eines Backend-Interviews#

Ein typisches Gespräch besteht aus drei Teilen. Zuerst Screening, dann Fachfragen, am Ende Verhalten. Jeder Teil prüft etwas anderes. Wer das versteht, kann gezielt vorbereiten.

Screening: Die ersten zehn Minuten entscheiden#

Der Recruiter oder Hiring Manager will wissen, ob du zur Stelle passt. Nicht mehr. Die Fragen sind einfach, aber deine Antworten müssen klar sein.

Frage: Warum bewirbst du dich bei uns? Die schlechte Antwort: "Ich suche eine neue Herausforderung." Das sagt jeder. Die gute Antwort zeigt, dass du recherchiert hast. Nenne zwei bis drei konkrete Dinge am Unternehmen oder Produkt, die dich interessieren. Wenn das Unternehmen eine API-first-Strategie fährt, sag das. Wenn sie Go einsetzen und du Go lernen willst, sag das.

Frage: Was sind deine Gehaltsvorstellungen? Keine falsche Bescheidenheit. Nenne eine Spanne, die du recherchiert hast. Backend-Entwickler mit drei bis fünf Jahren Erfahrung liegen in Deutschland oft zwischen 60.000 und 85.000 Euro brutto, Senior-Entwickler darüber. Die Zahlen variieren stark nach Stadt, Unternehmensgröße und Tech-Stack. Prüfe aktuelle Quellen wie Entgeltatlas oder Gehalt.de.

Frage: Beschreibe kurz dein aktuelles Projekt. Du hast maximal zwei Minuten. Strukturiere deine Antwort so: Was ist das Problem? Was war deine Rolle? Welche Technologien nutzt ihr? Was war das Ergebnis? Übe das laut. Einmal. Es macht einen Unterschied.

Fachliche Fragen: Hier wird geprüft, ob du liefern kannst#

Jetzt wird es ernst. Fachfragen testen nicht nur Wissen, sondern wie du denkst. Der Interviewer will sehen, wie du ein Problem zerlegst.

Frage: Erkläre den Unterschied zwischen REST und GraphQL. Zeige, dass du beide benutzt hast. REST ist einfach, gut dokumentiert, aber oft Over- oder Under-Fetching. GraphQL gibt dem Client mehr Kontrolle, ist aber komplexer in der Caching-Strategie. Nenne ein Beispiel aus deiner Arbeit. "In unserem letzten Projekt haben wir REST für interne Services genutzt, weil die Datenstrukturen stabil waren. Für das Frontend haben wir GraphQL eingeführt, weil sich die Anforderungen schnell geändert haben."

Frage: Wie gehst du mit Datenbank-Performance um? Zeige Systematik. Zuerst das Problem identifizieren: Langsame Queries finden mit EXPLAIN oder Monitoring-Tools. Dann analysieren: Fehlen Indizes? Gibt es N+1-Probleme? Dann optimieren: Caching, Query-Umstellung, manchmal auch Datenmodell ändern. Nenne eine konkrete Maßnahme, die du umgesetzt hast.

Frage: Was sind die Trade-offs von Microservices? Viele kennen nur die Vorteile. Zeige, dass du die Nachteile kennst: höhere Komplexität im Deployment, verteilte Fehlerbehandlung, Netzwerklatenz, schwierigere Debugging. Sage klar: "Microservices lösen Organisationsprobleme, nicht technische. Wenn ein Team aus fünf Leuten einen Service baut, braucht man keine Microservices."

Frage: Wie würdest du ein System für hohe Last designen? Fang nicht mit der Architektur an. Frag erst: "Was für Last? Lesen oder Schreiben? Wie viele Requests pro Sekunde?" Dann nenne konkrete Strategien: Caching auf mehreren Ebenen, Datenbank-Replikation, horizontale Skalierung, Rate Limiting. Zeige, dass du keine Lösung suchst, bevor du das Problem verstehst.

Hier ein konkretes Beispiel für eine Antwort auf die Frage nach Datenbank-Performance:

In unserem letzten Projekt hatten wir eine API, die bei 500 Requests pro Sekunde stockte. Ich habe mit EXPLAIN ANALYZE die langsamsten Queries identifiziert. Die Hauptursache war ein fehlender Index auf einer Verknüpfungstabelle mit 2 Millionen Zeilen. Nach dem Index fiel die Antwortzeit von 800ms auf 12ms. Zusätzlich haben wir Redis-Caching für wiederkehrende Abfragen eingeführt.

Verhaltensbasierte Fragen: Hier zeigen, wer du bist#

Diese Fragen klingen weich, sind aber hart. Der Interviewer will wissen, wie du mit Konflikten, Fehlern und Unsicherheit umgehst. Die Methode: STAR. Situation, Task, Action, Result. Keine vagen Aussagen, nur konkrete Geschichten.

Frage: Beschreibe eine Situation, in der du einen Konflikt im Team hattest. Wähle eine echte Situation. Nicht die, in der du recht hattest, sondern die, in der du etwas gelernt hast. Beschreibe kurz die Situation, was dein Ziel war, was du getan hast, was das Ergebnis war. "Ich hatte eine Meinungsverschiedenheit mit einem Kollegen über die Architektur eines neuen Services. Ich habe vorgeschlagen, beide Ansätze zu prototypisieren und die Ergebnisse zu vergleichen. Am Ende haben wir eine dritte Lösung gewählt, die besser war als beide ursprünglichen Vorschläge."

Frage: Erzähl von einem Fehler, den du gemacht hast. Keine Kleinigkeiten. Nenne einen echten Fehler mit Konsequenzen. Und zeige, was du daraus gelernt hast. "Ich habe einmal ein Datenbank-Migrationsskript auf Produktion deployed, ohne es vorher gegen ein Backup zu testen. Es hat eine Spalte gelöscht, die noch gebraucht wurde. Wir mussten das Backup einspielen, drei Stunden Downtime. Seitdem teste ich jedes Migrationsskript gegen einen anonymisierten Prod-Dump."

Frage: Wie bleibst du auf dem Laufenden? Zeige, dass du lernst, aber nicht jeder Mode hinterherjagst. Nenne konkrete Quellen: bestimmte Blogs, Podcasts, Konferenzen. Sage, wie du Neues einordnest: "Ich lese viel, setze aber nur in der Arbeit um, was ich an einem kleinen Side-Projekt getestet habe."

Typische Fehler im Backend-Interview#

Die häufigsten Fehler sind vermeidbar. Zuerst: zu viel reden. Wenn du eine Frage beantwortest, strukturiere in drei Punkten, dann stopp. Zweitens: keine Fragen stellen. Am Ende kommt immer "Haben Sie Fragen?". Nutze das. Stelle Fragen über das Team, die Technik, den Alltag. Nicht über Gehalt oder Urlaub. Drittens: angeben statt erzählen. "Ich bin ein Teamplayer" sagt nichts. "Ich habe unserem Praktikanten geholfen, seine erste API zu deployen" sagt alles.

Vorbereitungs-Checkliste#

• Lies die Stellenbeschreibung dreimal durch. Markiere die Technologien, die du nicht kennst. Recherchiere sie.
• Übe deine Antwort auf "Erzähl von dir" laut. Drei Minuten, maximal.
• Wähle drei Projekte aus deinem Lebenslauf aus. Für jedes: Problem, deine Rolle, Technologien, Ergebnis.
• Bereite zwei technische Fragen vor, die du stellen willst. Nicht generische, sondern spezifische.
• Teste deine Technik: Kamera, Mikrofon, Internet. Mach einen Probelauf mit einem Freund.
• Lies dir dein Anschreiben und Lebenslauf nochmal durch. Jede Aussage dort kann abgefragt werden.
• Schlafe vorher ausreichend. Klingt banal, macht aber einen Unterschied.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie lange dauert ein typisches Backend-Developer-Interview?

Erstgespräche sind oft 30 bis 45 Minuten. Technische Interviews gehen meist 60 bis 90 Minuten, manchmal mit Live-Coding. Bei manchen Unternehmen gibt es ein Take-Home-Assignment dazwischen.

Muss ich im Interview Code schreiben?

Meistens ja. Entweder als Live-Coding auf einer Plattform oder als kleines Take-Home-Projekt. Übe vorher, Code zu schreiben, während jemand zuschaut. Das ist eine eigene Fähigkeit.

Was, wenn ich eine Frage nicht beantworten kann?

Sag es ehrlich. "Das habe ich noch nicht gemacht, aber ich würde es so angehen..." ist besser als ein geratenes falsches Antwort. Ehrlichkeit wird geschätzt.

Wie wichtig sind Soft Skills im Backend-Interview?

Sehr wichtig. Backend-Entwickler arbeiten selten allein. Kommunikation, Zusammenarbeit, Umgang mit Konflikten sind relevanter als viele denken. Verhaltensfragen sind deshalb Standard.

Soll ich nach dem Interview nach Feedback fragen?

Ja, aber nicht unbedingt direkt am Ende. Wenn du nach ein bis zwei Wochen nichts gehört hast, ist eine höfliche Nachfrage per E-Mail angemessen. Frag nach dem aktuellen Stand und ob es noch offene Fragen gibt.