Backend Developer Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich orientiere mich an klaren, konsistenten Konventionen und überlege mir aus Sicht der Nutzer, welche Endpunkte sie wirklich brauchen. Gute Fehlermeldungen, sinnvolle Statuscodes und eine verständliche Dokumentation sind für mich Pflicht. Ich versioniere die API, damit Änderungen bestehende Clients nicht überraschend brechen. Vor der Festlegung hole ich Feedback von den nutzenden Teams ein.

Musterantwort

Zuerst analysiere ich die langsamen Abfragen, etwa mit EXPLAIN, um die Ursache zu finden. Häufig helfen passende Indizes, das Umschreiben ineffizienter Queries oder das Vermeiden des N+1-Problems. Wenn das nicht reicht, ziehe ich Caching oder Read-Replicas in Betracht. Ich messe vor und nach jeder Änderung, um die Wirkung zu belegen.

Musterantwort

Ich validiere und bereinige sämtliche Eingaben und nutze parametrisierte Abfragen gegen SQL-Injection. Authentifizierung und Autorisierung trenne ich klar und vergebe Rechte nach dem Prinzip der minimalen Berechtigung. Sensible Daten verschlüssele ich und halte Abhängigkeiten aktuell, um bekannte Lücken zu schließen. Sicherheit denke ich von Beginn an mit, nicht erst am Ende.

Musterantwort

Ich gehe davon aus, dass externe Dienste jederzeit ausfallen können, und baue entsprechend Timeouts, Retries und Circuit Breaker ein. Wichtige Operationen gestalte ich möglichst idempotent, damit Wiederholungen keinen Schaden anrichten. Über Monitoring und Alerts erkenne ich Probleme früh. So bleibt das System auch bei Teilausfällen handlungsfähig.

Musterantwort

Ich starte bewusst oft mit einem gut strukturierten Monolithen, weil er einfacher zu entwickeln und zu betreiben ist. Microservices ziehe ich erst in Betracht, wenn klare Skalierungs- oder Organisationsgründe dafür sprechen. Die Aufteilung orientiere ich an fachlichen Grenzen und nicht an technischen Schichten. Wichtig ist mir, die zusätzliche Komplexität ehrlich gegen den Nutzen abzuwägen.

REST ist ein Architekturstil für Web-APIs, der auf Ressourcen, eindeutigen URLs und den HTTP-Methoden GET, POST, PUT und DELETE basiert. Wichtige Prinzipien sind Zustandslosigkeit, eine einheitliche Schnittstelle und die klare Trennung von Client und Server.

ACID steht für Atomicity, Consistency, Isolation und Durability. Diese Eigenschaften garantieren, dass Transaktionen vollständig oder gar nicht ausgeführt werden, Daten konsistent bleiben, parallele Zugriffe sich nicht stören und bestätigte Änderungen dauerhaft gespeichert sind.

Caching beschleunigt häufige Lesezugriffe, indem Ergebnisse zwischengespeichert werden, etwa mit Redis. Das größte Risiko ist veraltete Information, weshalb eine durchdachte Strategie zum Invalidieren des Caches entscheidend ist.

Authentifizierung klärt, wer ein Nutzer ist, etwa über Passwort oder Token. Autorisierung legt fest, was dieser bereits identifizierte Nutzer tun darf, also welche Ressourcen und Aktionen ihm erlaubt sind.

Eine Message Queue entkoppelt Sender und Empfänger, indem Nachrichten zwischengespeichert und asynchron verarbeitet werden. Sie ist sinnvoll bei lastintensiven Aufgaben, Lastspitzen oder wenn Dienste unabhängig voneinander skalieren sollen.

Eine zentrale Übersichtsseite lud quälend langsam, weil eine Abfrage tausende Zeilen ohne Index durchsuchte. Ich habe die langsame Query identifiziert und einen passenden Index sowie eine schlankere Abfrage erstellt. Nach dem Deploy sank die Ladezeit von mehreren Sekunden auf unter eine halbe Sekunde. Die Nutzerbeschwerden hörten daraufhin auf.

Ein Drittanbieter-API fiel sporadisch aus und brachte unseren Bestellprozess ins Stocken. Ich habe Retries mit zunehmenden Wartezeiten und einen Circuit Breaker eingebaut, um Ausfälle abzufedern. Zusätzlich habe ich einen Fallback ergänzt, der Aufträge zwischenspeicherte. Der Prozess blieb dadurch auch bei Störungen stabil.

Bei einem Review fiel mir auf, dass Nutzereingaben ungeprüft in eine SQL-Abfrage flossen. Ich habe die Stelle sofort auf parametrisierte Abfragen umgestellt und nach ähnlichen Mustern im Code gesucht. Anschließend habe ich das Team für die Gefahr sensibilisiert und eine Richtlinie ergänzt. So konnten wir eine potenzielle Lücke schließen.

Vor einer großen Marketingaktion erwarteten wir ein Vielfaches des üblichen Traffics. Ich habe Lasttests durchgeführt, um Engpässe zu finden, und kritische Endpunkte mit Caching entlastet. Zudem habe ich die horizontale Skalierung vorbereitet, damit bei Bedarf mehr Instanzen anliefen. Die Aktion lief ohne Ausfälle ab.