Interviewfragen für Softwareentwickler, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Lies dann die ausführliche Antwort und such dir zwei oder drei Punkte aus, die du mit deiner eigenen Arbeit ergänzt. Interviewer wollen Zielkonflikte und echte Beispiele hören, keine Definitionen.

Was mit je nach Version oder je nach Anbieter markiert ist, hängt von einem Release oder einem Anbieter ab. Prüf die aktuelle Dokumentation, bevor du ein Detail zitierst.

Was ein Softwareentwickler können muss

• Eine Hauptsprache, und die gut: zum Beispiel JavaIn 20 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Modernes Java (Records, Streams, Generics) in einem Framework wie Spring, mit Tests und einem Build-Tool., PythonIn 26 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Sauberes, getestetes Python: ein kleiner Webdienst oder ein Skript, das andere ausführen können, mit Typen, Tests und Packaging., C#In 20 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).C# auf .NET: Web-APIs, asynchroner Code, Dependency Injection und Tests; verbreitet bei Banken und in der Industrie. oder TypeScriptIn 11 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).JavaScript mit Typen: Daten modellieren, Fehler vom Compiler finden lassen und die Typen ehrlich halten.. Gut heißt: Du kannst fremden Code darin lesen und erklären, warum er sich so verhält.
• Tests: Unit-TestsIn 8 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Schnelle Tests für je ein Stück Logik; sie laufen bei jeder Änderung und schlagen aus genau einem Grund fehl. (kleine, schnelle Tests für ein Stück Logik), Integrationstests (mehrere Teile zusammen) und wann sich welche lohnen.
• Versionsverwaltung: GitIn 33 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Branches, Pull Requests, eine saubere Historie und einen Merge-Konflikt ohne Panik lösen. mit Branches und Pull Requests (eine vorgeschlagene Änderung, die andere prüfen, bevor sie gemergt wird).
• Ausliefern: CI/CDIn 29 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Jede Änderung wird automatisch gebaut und getestet; eine grüne Pipeline darf ausliefern, eine rote stoppt das Release. (jede Änderung wird automatisch gebaut, getestet und dann ausgeliefert), DockerIn 12 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Einen Dienst samt Abhängigkeiten in ein Image packen, das auf dem Laptop und in Produktion gleich läuft. (ein Container: das Programm mit allem verpackt, was es zum Laufen braucht) und eine Cloud.
• Daten: SQLIn 18 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Joins und Aggregationen schreiben, einen Ausführungsplan lesen und wissen, wann ein Index hilft., Tabellen und Indizes und wovor dich eine Transaktion schützt (mehrere Änderungen, die nur gemeinsam gelingen oder gemeinsam scheitern).
• Entwurf: klare Namen, kleine Funktionen, APIsIn 6 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Eine HTTP-API entwerfen: klare Ressourcen, Statuscodes, Versionierung, Paging und hilfreiche Fehlermeldungen. (der vereinbarte Weg, auf dem zwei Programme miteinander sprechen) und Design PatternsIn 1 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Bewährte Lösungen für häufige Entwurfsprobleme (Adapter, Strategy, Observer); einsetzen, wenn sie den Code einfacher machen. nur dort, wo sie den Code einfacher machen.
• Sicherheitsgrundlagen: die häufigen Angriffe auf Websoftware und wie Code sie verhindert.
• Teamarbeit: Code-Reviews, Schätzungen und die Arbeit in agilenIn 10 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Kurze Zyklen aus Planen, Bauen und Zeigen; den Plan an das anpassen, was man lernt. Teams.

Code schreiben und ändern

Worauf achtest du, wenn du den Code einer Kollegin oder eines Kollegen reviewst?

Worauf sie achten: dass es beim Code-Review darum geht, Probleme früh zu finden und Wissen zu teilen, freundlich und ohne Glaubenskriege über Stil.

Kurze Antwort: „Zuerst: Macht der Code, was das Ticket verlangt, auch in den Randfällen? Dann: Ist er getestet, gut lesbar und später leicht zu ändern? Ich stelle Fragen statt Anweisungen, trenne ‚muss behoben werden‘ von ‚wäre schön‘ und überlasse die Formatierung einem automatischen Werkzeug.“

Die ausführliche Antwort: Ich lese die Beschreibung und das Ticket vor dem Code, damit ich weiß, was er tun soll. Zuerst suche ich Fehler: leere Eingaben, eine fehlende Prüfung, ein Fehler, der still verschluckt wird, zwei Nutzer, die gleichzeitig dasselbe tun. Dann die Tests: Gibt es einen Test für das neue Verhalten, und würde er fehlschlagen, wenn der Code falsch wäre? Dann die Lesbarkeit: Namen, Größe der Funktionen, Kommentare, die erklären, warum, statt was. Ich halte Reviews klein und schnell; eine Änderung von ein paar hundert Zeilen bekommt ein besseres Review als eine von mehreren tausend. Geht eine Diskussion zweimal hin und her, reden wir miteinander, statt weiter zu tippen.

Schwache Antwort: „Ich prüfe, ob er unserem Styleguide folgt.“ Stil ist Sache eines Formatierers; ein Review, das nur Kommas findet, übersieht die Fehler.

Nachfrage: „Ein Senior-Kollege lehnt deine Änderungen immer wieder wegen kleiner Vorlieben ab. Was tust du?“ Schlag vor, die Regeln einmal gemeinsam festzulegen, sie aufzuschreiben oder in den Formatierer zu packen, und die Reviews für das zu nutzen, was wirklich zählt.

Wie würdest du ein großes, altes Stück Code refaktorieren, das niemand anfassen will?

Worauf sie achten: dass du riskanten Code sicher änderst, in kleinen Schritten, mit Tests als Sicherheitsnetz.

Kurze Antwort: „Zuerst schreibe ich Tests, die festhalten, was der Code heute tut, auch die seltsamen Teile. Dann refaktoriere ich in kleinen Schritten, jeder ausgeliefert und getestet, und ändere das Verhalten nur in einem eigenen Schritt. Ich fange dort an, wo das Geschäft den Schmerz spürt, nicht dort, wo der Code am hässlichsten aussieht.“

Die ausführliche Antwort: Refaktorieren heißt, die Struktur von Code zu ändern, ohne zu ändern, was er tut. Bei altem Code besteht die Gefahr darin, etwas kaputtzumachen, an das sich niemand mehr erinnert. Also: Characterization Tests schreiben (Tests, die das heutige Verhalten festhalten, ob richtig oder falsch). Eine Nahtstelle finden, einen Punkt, an dem du ansetzen kannst, etwa eine Funktionsgrenze. Kleine Stücke herauslösen, ihnen klare Namen geben und jeden Schritt ausliefern. Bei hohem Risiko alten und neuen Weg hinter einem Schalter nebeneinander laufen lassen, damit du sofort zurückkannst. Die Arbeit mit dem Team und dem Product Owner abstimmen und an etwas knüpfen, das ihnen wichtig ist, etwa weniger Fehler oder schnellere Änderungen in diesem Bereich.

Schwache Antwort: „Ich würde es komplett neu schreiben.“ Große Neuschreibungen dauern meist viel länger als geplant und verlieren die versteckten Regeln, die der alte Code gelernt hatte.

Nachfrage: „Es gibt keine Tests und keine Zeit, viele zu schreiben. Was jetzt?“ Teste nur den Weg, den du gleich änderst, und ergänze für jeden Fehler, den du dort behebst, einen Test.

Was sind technische Schulden, und wie entscheidest du, wann du sie zurückzahlst?

Worauf sie achten: dass du über Codequalität in der Sprache des Geschäfts sprechen kannst.

Kurze Antwort: „Technische Schulden sind die Mehrkosten jeder künftigen Änderung, weil früher eine Abkürzung genommen wurde. Ich zahle sie zurück, wenn sie Arbeit bremsen, die wir als Nächstes vorhaben, und ich mache sie mit einem Ticket und einer Schätzung sichtbar, damit sie eine Entscheidung sind und kein Geheimnis.“

Die ausführliche Antwort: Manche Schulden sind eine vernünftige Wahl, etwa eine einfache Version auszuliefern, um schneller zu lernen. Zum Problem werden sie, wenn die Zinsen wachsen: Jede Änderung in dem Bereich dauert länger, geht öfter kaputt oder macht den Leuten Angst. Ich führe eine kurze Liste der schlimmsten Bereiche mit den Kosten, die sie verursachen, etwa Fehler, verlorene Stunden oder langsame Releases. Dann kann das Team sie gegen Features abwägen. Ein fester Anteil jedes Sprints für Aufräumarbeiten funktioniert oft besser als ein großes Aufräumprojekt.

Schwache Antwort: „Unser Code hat keine technischen Schulden.“ Jede echte Codebasis hat welche.

Nachfrage: „Der Product Manager sagt, dafür ist nie Zeit.“ Zeig die Kosten in seinen Begriffen, etwa wie viel länger Features in diesem Bereich dauern, und schlag eine kleine, messbare Verbesserung vor.

Testen und Debugging

Wie entscheidest du, was du mit Unit-Tests, Integrationstests und End-to-End-Tests abdeckst?

Worauf sie achten: dass du mit einem Ziel testest und Kosten und Nutzen jeder Testart kennst.

Kurze Antwort: „Viele schnelle Unit-Tests für die Logik, weniger Integrationstests für die Stellen, an denen Teile aufeinandertreffen, etwa die Datenbank oder ein anderer Service, und eine Handvoll End-to-End-Tests für die Wege, mit denen das Unternehmen Geld verdient. Jeder Fehler bekommt einen Test, bevor er behoben wird.“

Die ausführliche Antwort: Ein Unit-Test prüft ein Stück Logik für sich und läuft in Millisekunden; du kannst also Tausende davon haben. Ein Integrationstest prüft, ob dein Code wirklich mit der Datenbank, einer Queue oder einer anderen API funktioniert; er ist langsamer, findet aber die Fehler in der Verdrahtung. Ein End-to-End-Test bedient das ganze System wie ein Nutzer; er ist langsam und anfällig, beschränk ihn also auf die wichtigen Abläufe wie Registrierung und Bezahlung. Diese Form nennt man Testpyramide. Gute Tests schlagen aus einem klaren Grund fehl, hängen nicht voneinander ab und laufen bei jeder Änderung in der Pipeline. TestautomatisierungIn 8 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Automatisierte Tests auf mehreren Ebenen (Unit, Integration, End-to-End), die in der Pipeline laufen. lohnt sich nur, wenn ein roter Test das Release wirklich stoppt.

Schwache Antwort: „Wir streben volle Testabdeckung an.“ Abdeckung zeigt, was gelaufen ist, nicht, was geprüft wurde.

Nachfrage: „Deine End-to-End-Tests schlagen zufällig in einem von zehn Läufen fehl. Was tust du?“ Behandle Flaky Tests als Fehler: Finde die Ursache (Timing, geteilte Daten, die Reihenfolge der Tests), behebe sie oder entferne den Test, und lass ihn nie einfach neu laufen, bis er grün ist.

In der Produktion taucht ein Fehler auf, den du auf deinem Rechner nicht nachstellen kannst. Wie findest du ihn?

Worauf sie achten: ein ruhiges Vorgehen Schritt für Schritt, mit Belegen statt Raten.

Kurze Antwort: „Zuerst begrenze ich den Schaden, dann sammle ich Belege: Logs, Fehlerberichte, welche Nutzer, welche Version. Ich suche, was sich zwischen Produktion und meinem Rechner unterscheidet, etwa Daten, Einstellungen, Last oder Timing, und grenze es Unterschied für Unterschied ein.“

Die ausführliche Antwort: Wenn Nutzer betroffen sind, stoppe ich zuerst den Schaden: das letzte Release zurückrollen oder das Feature abschalten. Dann sammle ich Fakten: Wann fing es an, passt es zu einem Release, welche Eingaben lösen es aus? Logs mit einer Request-ID lassen mich eine Anfrage durch jeden Service verfolgen. Typische Ursachen für „läuft bei mir“ sind andere Daten (ein leeres Feld, ein Sonderzeichen), eine andere Konfiguration, eine andere Version einer Bibliothek, echte Last oder das Timing zwischen zwei Prozessen. Ich schreibe einen fehlschlagenden Test, der den Fehler nachstellt, behebe ihn und behalte den Test, damit er nicht zurückkommt. Dann frage ich, warum er nicht aufgefallen ist, und schließe auch diese Lücke.

Schwache Antwort: „Ich baue Print-Ausgaben ein und deploye neu, bis ich ihn finde.“ Das ist langsam und riskant auf einem Live-System.

Nachfrage: „Es passiert nur unter hoher Last.“ Vermute eine Race Condition oder eine Ressourcengrenze, etwa einen Connection Pool, der leerläuft; stell es mit einem Lasttest nach.

Was ist eine Race Condition, und wie verhinderst du sie?

Worauf sie achten: dass du verstehst, was schiefgeht, wenn zwei Dinge gleichzeitig passieren.

Kurze Antwort: „Eine Race Condition ist ein Fehler, bei dem das Ergebnis davon abhängt, welcher von zwei Prozessen zuerst ankommt, etwa zwei Leute, die den letzten Platz buchen. Ich verhindere sie, indem ich den kritischen Schritt atomar mache, also ganz oder gar nicht, mit einer Datenbanktransaktion, einem Unique Constraint oder einer Sperre, und indem ich so wenig veränderliche Daten wie möglich teile.“

Die ausführliche Antwort: Der klassische Fall ist „lesen, prüfen, schreiben“: Zwei Anfragen lesen beide, dass ein Platz frei ist, und buchen ihn beide. Die Lösung: Die Datenbank prüft und schreibt in einem Schritt, zum Beispiel mit einem Update, das nur gelingt, wenn der Platz noch frei ist, oder mit einer Unique-Regel, die die zweite Buchung ablehnt. Innerhalb eines Programms teilst du möglichst keine Daten zwischen Threads und schützt sie mit einer Sperre, wo es nicht anders geht. Aktionen, die wiederholt werden können, etwa eine Zahlung, machst du idempotent: Zweimal ausgeführt, haben sie dieselbe Wirkung wie einmal, meist mit einem eindeutigen Schlüssel pro Anfrage.

Schwache Antwort: „Wir bauen eine kurze Wartezeit ein, damit sie nicht kollidieren.“ Warten versteckt den Fehler, es behebt ihn nicht.

Nachfrage: „Die Sperren haben alles langsam gemacht.“ Weniger sperren (eine Zeile, nicht die Tabelle), die Sperre kürzer halten oder die Prüfung den eigenen Regeln der Datenbank überlassen.

Datenbanken

Eine Seite ist wegen einer einzigen Datenbankabfrage langsam. Wie machst du sie schneller?

Worauf sie achten: dass du zuerst misst und weißt, was ein Index tut.

Kurze Antwort: „Ich schaue mir den Ausführungsplan an, der zeigt, wie die Datenbank die Abfrage ausführt, und sehe, ob sie die ganze Tabelle liest. Meist hilft ein Index auf den Spalten, nach denen wir filtern oder joinen, weniger Zeilen und Spalten abzurufen oder eine Abfrage zu entfernen, die für jede Zeile einmal läuft.“

Die ausführliche Antwort: Ein Index ist wie das Register eines Buchs: Die Datenbank findet Zeilen, ohne jede Seite zu lesen. Ich prüfe den Plan vorher und nachher, denn ein Index, der nicht genutzt wird, bremst nur die Schreibzugriffe. Häufige Probleme: kein Index auf einer Spalte, nach der gefiltert oder gejoint wird, eine Funktion um die Spalte herum, die den Index ausschaltet, jede Spalte abfragen, wenn die Seite drei braucht, und das „N+1“-Problem, bei dem der Code eine Abfrage für eine Liste ausführt und dann eine weitere für jeden Eintrag. Werden die Daten viel öfter gelesen als geändert, kann ein Cache helfen, aber dann brauche ich einen Plan für den Fall, dass die zwischengespeicherte Kopie veraltet ist. SQLIn 18 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Joins und Aggregationen schreiben, einen Ausführungsplan lesen und wissen, wann ein Index hilft. und eine Datenbank wie PostgreSQLIn 6 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Eine verbreitete Open-Source-Datenbank: Schemas, Indizes, Transaktionen und sichere Migrationen. kommen hier oft zur Sprache.

Schwache Antwort: „Einen Index auf jede Spalte legen.“ Jeder Index kostet Platz und bremst jedes Insert und jedes Update.

Nachfrage: „Im Test ist die Abfrage schnell, in der Produktion langsam.“ Die Produktion hat viel mehr Daten und eine andere Verteilung der Werte; teste mit realistischen Datenmengen.

Wie änderst du eine Datenbanktabelle sicher, während die Anwendung läuft?

Worauf sie achten: dass du Schemaänderungen ohne Ausfallzeit und mit einem Weg zurück ausliefern kannst.

Kurze Antwort: „In kleinen, abwärtskompatiblen Schritten: die neue Spalte ergänzen, in alte und neue schreiben, die alten Daten hinüberkopieren, das Lesen auf die neue Spalte umstellen und erst dann die alte entfernen. Jeder Schritt ist ein eigenes Release, damit ein Rollback nie auf eine Datenbank trifft, die er nicht lesen kann.“

Die ausführliche Antwort: Eine Migration ist eine per Skript ausgeführte Änderung an der Struktur der Datenbank, die mit dem Code in der Versionsverwaltung liegt. Das Risiko: Während eines Releases laufen neuer und alter Code gleichzeitig, also müssen beide in jedem Schritt mit der Datenbank funktionieren. Große Tabellen brauchen Sorgfalt: Manche Änderungen sperren die Tabelle minutenlang, kopiere die Daten also in Paketen. Mach vorher ein Backup, teste die Migration an einer Kopie der Produktionsdaten und wisse, wie du jeden Schritt rückgängig machst.

Schwache Antwort: „Nachts die App stoppen und das Skript laufen lassen.“ Viele Systeme können nicht stoppen, und nachts ist niemand da, der hilft, wenn es schiefgeht.

Nachfrage: „Die Migration ist auf halbem Weg gescheitert.“ Genau deshalb ist jeder Schritt klein und lässt sich gefahrlos wiederholen; du behebst den Fehler und führst ihn erneut aus oder machst diesen einen Schritt rückgängig.

APIs und Systemdesign

Wie würdest du eine REST-API zum Anlegen und Bezahlen von Bestellungen entwerfen?

Worauf sie achten: klare Ressourcen, ehrliche Fehler, sichere Wiederholungen und Raum zum Wachsen.

Kurze Antwort: „Ressourcen als Substantive benannt, etwa Bestellungen und Zahlungen, die üblichen HTTP-Methoden und Statuscodes, ein Schlüssel pro Anfrage, damit eine wiederholte Zahlung nicht doppelt abgebucht wird, Paging für Listen, klare Fehlermeldungen und eine Version, damit alte Clients weiter funktionieren.“

Die ausführliche Antwort: In einer REST-APIIn 6 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Eine HTTP-API entwerfen: klare Ressourcen, Statuscodes, Versionierung, Paging und hilfreiche Fehlermeldungen. ist jedes Ding eine Ressource mit einer Adresse, und die HTTP-Methode sagt, was zu tun ist: GET zum Lesen, POST zum Anlegen und so weiter. Das Anlegen einer Bestellung antwortet mit „created“ und der Adresse der neuen Bestellung; eine fehlerhafte Anfrage bekommt eine Meldung, die sagt, welches Feld falsch ist. Zahlungen müssen idempotent sein: Der Client schickt einen eindeutigen Schlüssel, und eine zweite Anfrage mit demselben Schlüssel bekommt das erste Ergebnis zurück, statt noch einmal abzubuchen. Listen werden seitenweise ausgeliefert, damit ein Aufruf nicht eine Million Zeilen zurückgeben kann. Jeder Aufruf prüft, wer fragt und was er sehen darf. Dokumentiere die API so, dass ein anderes Team sie nutzen kann, ohne dich zu fragen.

Schwache Antwort: eine einzige Adresse, die ein Feld „action“ annimmt und immer „OK“ antwortet, auch bei Fehlern.

Nachfrage: „Eine mobile App nutzt noch die alte Version.“ Lass die alte Version weiterlaufen, kennzeichne sie als auslaufend und nenne ihren Nutzern das Datum.

Entwirf einen URL-Shortener. Führ mich durch dein Systemdesign.

Worauf sie achten: dass du zuerst nach den Zahlen fragst, einfach anfängst und weißt, wo es bricht.

Kurze Antwort: „Ich würde fragen, wie viele Links am Tag und wie viele Klicks, und dann mit einem Service und einer Datenbank anfangen: einen kurzen Code neben der langen Adresse speichern, ihn bei jedem Klick nachschlagen und einen Cache ergänzen, weil es weit mehr Klicks als neue Links gibt. Dann würde ich darüber sprechen, was passiert, wenn es wächst oder ein Teil ausfällt.“

Die ausführliche Antwort: Ein Interview zum Systemdesign ist ein Gespräch, kein Zeichenwettbewerb. Ich kläre die Anforderungen: Laufen Links ab, dürfen Leute ihren Code selbst wählen, zählen wir Klicks? Ich schätze die Last, denn Lesezugriffe sind hier viel häufiger als Schreibzugriffe. Der einfache Entwurf: eine API, die einen kurzen Code erzeugt (zum Beispiel einen zufälligen, gegen die vorhandenen geprüft), eine Datenbanktabelle mit diesem Code als Schlüssel und bei jedem Klick eine Weiterleitung. Ein Cache vor der Datenbank liefert beliebte Links schnell aus. Das Zählen der Klicks geht in eine Queue (eine Warteschlange von Nachrichten, die später verarbeitet werden), damit es die Weiterleitung nie bremst. Dann die Fehlerfälle: Was, wenn der Cache ausfällt (aus der Datenbank lesen), die Datenbank ausfällt (Links aus dem Cache liefern) oder jemand den Dienst nutzt, um schädliche Links zu verbreiten (neue Adressen prüfen und Meldungen erlauben)?

Schwache Antwort: mit MicroservicesIn 6 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Wissen, wann sich das Aufteilen eines Systems lohnt und was es kostet: Netzwerkfehler, Datenkonsistenz, Tracing., drei Datenbanken und einem Message Bus anfangen, bevor du fragst, wie groß es wird.

Nachfrage: „Der Traffic wächst auf das Hundertfache.“ Mehr Kopien des zustandslosen Service hinter einem Load Balancer, mehr Cache und Kopien der Datenbank für Lesezugriffe.

Wann würdest du ein System in Microservices aufteilen, und wann nicht?

Worauf sie achten: dass du die Kosten genauso kennst wie den Nutzen.

Kurze Antwort: „Wenn verschiedene Teams verschiedene Teile nach ihrem eigenen Zeitplan ausliefern müssen oder ein Teil ganz anders skalieren muss. Nicht als Standard: Eine gut strukturierte einzelne Anwendung ist einfacher zu bauen, zu testen und zu betreiben, und viele Teams sollten dort anfangen.“

Die ausführliche Antwort: Microservices sind kleine Services, die je eine Aufgabe und ihre eigenen Daten haben und über das Netzwerk miteinander sprechen. Sie lassen Teams unabhängig arbeiten und ausliefern. Der Preis ist real: Netzwerkaufrufe schlagen fehl und sind langsam, die Daten sind verteilt, sodass es schwerer ist, sie konsistent zu halten, und du brauchst Tracing, um eine Anfrage über Services hinweg zu verfolgen, dazu mehr Automatisierung für Deployments. Ein „modularer Monolith“, eine Anwendung mit klaren inneren Grenzen, bietet viel von der Struktur ohne diesen Preis und lässt sich später entlang genau dieser Grenzen aufteilen.

Schwache Antwort: „Microservices sind immer moderner.“

Nachfrage: „Zwei Services brauchen beide die Adresse des Kunden.“ Ein Service ist ihr Eigentümer; der andere fragt ihn oder hält eine Kopie, die über Events aktualisiert wird.

Software ausliefern und betreiben

Ein Release geht in der Produktion schief. Wie sieht dein Plan für den Rollback aus?

Worauf sie achten: dass du den Fehlerfall einplanst, bevor du auslieferst.

Kurze Antwort: „Jedes Release lässt sich in Minuten rückgängig machen: Die vorige Version steht bereit, Datenbankänderungen sind abwärtskompatibel, und riskante Features liegen hinter einem Schalter, den ich ohne Deployment umlegen kann. Direkt nach dem Release beobachten wir Fehler und Antwortzeiten und rollen bei einem klaren Signal zurück.“

Die ausführliche Antwort: Ein Rollback heißt, zur letzten funktionierenden Version zurückzukehren. Schnell geht das nur, wenn es vorbereitet ist: Die Pipeline kann den vorigen Build erneut ausrollen, und die Datenbank funktioniert noch mit ihm. Feature Flags (Schalter in der Konfiguration) lassen dich ein neues Feature ohne neues Deployment abschalten. Liefere zuerst an einen kleinen Teil der Nutzer aus, oft Canary Release genannt, und vergleiche ihre Fehlerrate mit der aller anderen. Schreib nach dem Vorfall eine kurze Nachbesprechung ohne Schuldzuweisung: was passiert ist, warum es nicht aufgefallen ist und was wir ändern.

Schwache Antwort: „Wir testen sorgfältig, also gehen Releases nicht schief.“

Nachfrage: „Das fehlerhafte Release hat schon Kundendaten verändert.“ Den Code zurückzurollen reicht nicht: Finde die betroffenen Datensätze, repariere sie und informiere, wenn nötig, die Betroffenen.

Was passiert zwischen deinem Merge und dem Moment, in dem der Code in der Produktion läuft?

Worauf sie achten: dass du die Pipeline verstehst und auch nach dem Merge für deinen Code einstehst.

Kurze Antwort: „Die CI/CDIn 29 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Jede Änderung wird automatisch gebaut und getestet; eine grüne Pipeline darf ausliefern, eine rote stoppt das Release.-Pipeline baut den Code, führt die Tests und Prüfungen aus, baut ein Image, rollt es in eine Testumgebung aus und dann in die Produktion, oft schrittweise. Danach beobachte ich Logs und Dashboards, um zu sehen, dass es funktioniert.“

Die ausführliche Antwort: CI, Continuous Integration, heißt: Jede Änderung wird oft gemergt und automatisch geprüft, mit Build, Unit-Tests und einem Scan der Bibliotheken auf bekannte Sicherheitslücken. CD, Continuous Delivery, heißt: Eine Änderung, die alle Prüfungen besteht, kann jederzeit ausgeliefert werden, per Knopfdruck oder automatisch. Das Ergebnis ist meist ein DockerIn 12 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Einen Dienst samt Abhängigkeiten in ein Image packen, das auf dem Laptop und in Produktion gleich läuft.-Image, das eine Plattform wie KubernetesIn 11 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Container im großen Stil betreiben: Deployments, Health Checks, Skalierung und Konfiguration; oft gemeinsam mit einem Plattform-Team. oder ein Cloud-Dienst ausrollt; sie prüft, ob die neuen Kopien gesund sind, bevor die alten gestoppt werden. Gute Teams liefern oft kleine Änderungen aus, denn eine kleine Änderung ist leicht zu prüfen und leicht rückgängig zu machen.

Schwache Antwort: „Nach dem Merge kümmert sich der Betrieb darum.“

Nachfrage: „Die Pipeline braucht vierzig Minuten.“ Tests parallel laufen lassen, den Build cachen und die langsamsten Tests in eine spätere Stufe verschieben, die nicht jede Änderung blockiert.

Sicherheit

Was ist SQL-Injection, und wie verhindert dein Code sie?

Worauf sie achten: dass du die häufigsten Angriffe und die üblichen Abwehrmaßnahmen kennst.

Kurze Antwort: „Bei SQL-Injection wird Nutzereingabe direkt in eine Datenbankabfrage geklebt, sodass ein Angreifer die Abfrage selbst verändern kann. Ich verhindere sie mit parametrisierten Abfragen, bei denen die Eingabe getrennt übergeben und nie als Teil der Abfrage gelesen wird, dazu mit Datenbankkonten, die nur die nötigsten Rechte haben.“

Die ausführliche Antwort: Die Regel dahinter ist breiter: Trau keiner Eingabe von außen. Für die Datenbank nutzt du parametrisierte Abfragen oder eine Bibliothek, die das für dich erledigt. Für Webseiten maskierst du die Ausgabe, damit Eingaben nicht zu einem Skript werden können (dieser Angriff heißt Cross-Site Scripting). Prüf Zugriffsrechte bei jeder Anfrage auf dem Server, nicht nur im Browser. Halte Secrets wie Passwörter und Schlüssel aus dem Code heraus. Halte Bibliotheken aktuell, denn viele Angriffe nutzen alte, bekannte Lücken. Die OWASP Top 10 sind die übliche Checkliste der Risiken im Web, und Fragen zur SicherheitIn 5 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Die häufigen Angriffe auf Websoftware und wie Code sie verhindert; die OWASP Top 10 sind die übliche Liste. folgen oft dieser Liste.

Schwache Antwort: „Wir entfernen Anführungszeichen aus der Eingabe.“ Filter übersehen Fälle; Parameter nicht.

Nachfrage: „Wo bewahrst du das Datenbankpasswort auf?“ In einem Secrets Store oder den Secret-Einstellungen der Plattform, nie im Code oder im Repository.

Arbeit im Team

Wie schätzt du eine Aufgabe, und was tust du, wenn du die Schätzung nicht halten wirst?

Worauf sie achten: Ehrlichkeit, Arbeit in Stücke zerlegen und andere früh informieren.

Kurze Antwort: „Ich zerlege die Aufgabe in kleine Stücke, die ich verstehe, schätze diese und plane Zeit für das Unbekannte ein. Merke ich, dass ich es nicht schaffe, sage ich das, sobald ich es weiß, mit dem, was fertig ist, was fehlt, und den Optionen: Umfang kürzen, Hilfe holen oder den Termin verschieben.“

Die ausführliche Antwort: Schätzungen gehen bei den Teilen schief, an die wir nicht gedacht haben; der erste Schritt ist also, sie aufzulisten: die Änderung selbst, Tests, das Review, die Migration, die Dokumentation. Unbekanntes bekommt zuerst eine kurze Untersuchung, oft Spike genannt. In agilenIn 10 % der Anzeigen für Softwareentwickler gefragt (Stand 05.11.2026).Kurze Zyklen aus Planen, Bauen und Zeigen; den Plan an das anpassen, was man lernt. Teams wird oft relativ geschätzt (das ist etwa doppelt so viel wie jenes) statt in Stunden, und das Team vergleicht Plan und Ergebnis, um besser zu werden. Das Schlimmste ist eine Überraschung am letzten Tag.

Schwache Antwort: „Ich werde immer rechtzeitig fertig.“ Das glaubt niemand.

Nachfrage: „Deine Führungskraft will heute einen Termin für etwas, das noch niemand gebaut hat.“ Nenn eine Spanne und sag, was sie enger machen würde, und aktualisiere sie nach der ersten Woche.

Du bist mit einer technischen Entscheidung deiner Teamleitung nicht einverstanden. Was tust du?

Worauf sie achten: dass du gut widersprechen und dich danach voll hinter die Entscheidung stellen kannst.

Kurze Antwort: „Ich frage zuerst nach den Gründen, um sie zu verstehen, und erkläre dann meine Bedenken mit Fakten, etwa einer Messung, einem Beispiel oder einem kleinen Test. Entscheidet die Teamleitung trotzdem anders, trage ich die Entscheidung mit, und wir vereinbaren, woran wir erkennen, ob sie funktioniert.“

Die ausführliche Antwort: Die meisten Meinungsverschiedenheiten kommen von unterschiedlichen Informationen, also fange ich mit Fragen an. Wenn es wichtig ist, schreibe ich meine Sicht auf: die Optionen, die Zielkonflikte, was ich empfehle und warum. Ein schneller Prototyp oder eine Messung klärt es oft besser als eine Debatte. Ist die Entscheidung gefallen, rolle ich sie nicht immer wieder auf, aber wir vereinbaren einen Zeitpunkt, an dem wir nachsehen, zum Beispiel nach dem ersten Release.

Schwache Antwort: „Ich würde es einfach auf meine Art machen.“

Nachfrage: „Es stellt sich heraus, dass du recht hattest.“ Sag, was du darüber gelernt hast, deine Argumente früher vorzubringen, und hilf ohne Schuldzuweisung beim Beheben.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon belegt, denn Interviewer fragen nach dem, was darin steht. Schreib zu jedem dieser Punkte eine Zeile unter jede Stelle, in den Wörtern der Anzeigen:

Bewerte deinen Lebenslauf dann an einem echten Job: Du siehst, welche dieser Punkte der Job verlangt und welche dein Lebenslauf noch nicht belegt.