Softwareentwickler Interviewfragen & Antworten

Beispielantwort

Bei meinem vorherigen Arbeitgeber wollte das Team eine neue NoSQL-Datenbank für ein Feature mit komplexen relationalen Abfragen einsetzen. Ich war überzeugt, dass eine relationale Datenbank die bessere Wahl war. Ich bereitete ein kurzes technisches Dokument vor, das beide Ansätze anhand unserer konkreten Zugriffsmuster verglich, und brachte es in das nächste Design-Review ein. Wir führten einen kleinen Spike mit beiden Optionen durch, und die Daten bestätigten meine Empfehlung. Das Team wechselte den Ansatz. Entscheidend war, mit Daten statt mit Meinungen zu argumentieren und es den Kollegen leicht zu machen, ihre Position zu ändern, ohne das Gesicht zu verlieren. In deutschen Teams zahlt sich diese Sachlichkeit besonders aus: Eine gut dokumentierte Analyse überzeugt oft schneller als eine überzeugende Präsentation.

Beispielantwort

Wir hatten drei Wochen Zeit, um eine Echtzeitfunktion mit WebSockets auszuliefern, etwas, das ich zuvor noch nie produktiv eingesetzt hatte. Ich blockierte mir die Vormittage für konzentriertes Lernen: Zuerst baute ich einen Wegwerf-Prototyp, dann las ich die RFC und untersuchte, wie größere Open-Source-Projekte Randfälle wie Reconnects und Nachrichtenreihenfolge handhaben. Zusätzlich ließ ich meine Code-Reviews von einem Kollegen mit WebSocket-Erfahrung begleiten. Wir lieferten pünktlich aus, und die Funktion hatte im ersten Quartal keine Produktionsvorfälle. Ich kommunizierte früh, welche Nebenaufgaben ich zurückstellte, um die Deadline zu halten, statt stillschweigend Überstunden anzuhäufen.

Beispielantwort

Unsere kundenseitige API hatte eine 95.-Perzentil-Latenz von 800 Millisekunden. Ich profilierte die langsamsten Endpunkte und fand drei N+1-Abfragemuster in unserer ORM-Schicht. Ich schrieb diese Abfragen mit expliziten Joins neu und fügte einen Redis-Cache für eine stark gelesene Nutzerrechte-Abfrage hinzu. Die Latenz sank auf 120 Millisekunden im 95. Perzentil. Der schwierigere Teil war, das Team davon zu überzeugen, die Zeit zu investieren. Ich baute ein einfaches Dashboard, das Latenz direkt mit der Konversionsrate verknüpfte, was das Business-Argument offensichtlich machte.

Beispielantwort

Wir hatten über zwei Monate hinweg ein Empfehlungsfeature entwickelt, das nahezu keine Nutzung fand. Wir hatten auf Klickrate optimiert, aber die Nutzer empfanden die Vorschläge als irrelevant. Ich leitete eine Retrospektive, und wir identifizierten die Ursache: Wir hatten vor dem Bau nie mit Nutzern gesprochen. Ich fasste die Erkenntnisse in einem einseitigen Dokument zusammen und schlug vor, eine Discovery-Phase in unseren Entwicklungsprozess aufzunehmen. Diese Prozessänderung überdauerte das eigentliche Feature. Wir führen seitdem vor jedem größeren Vorhaben einen festen Schritt mit Nutzerinterviews durch.

Beispielantwort

Im Kern braucht man zwei Operationen: Schreiben, also aus einer langen URL einen kurzen Code erzeugen, und Lesen, also anhand des kurzen Codes zur ursprünglichen URL weiterleiten. Für den kurzen Code würde ich eine Base62-Kodierung einer automatisch inkrementierten ID verwenden, das ergibt bei sechs Zeichen etwa 3,5 Milliarden mögliche Codes. Der Schreibpfad schreibt in eine Datenbank und cached die Zuordnung. Der Lesepfad arbeitet konsequent Cache-first mit Fallback auf die Datenbank. Bei Skalierung überwiegen Lesevorgänge die Schreibvorgänge deutlich, daher ist die Cache-Trefferquote entscheidend. Ich würde Rate-Limiting auf Schreibvorgänge legen, um Missbrauch zu verhindern, und Erstellungszeitpunkt, Nutzer-ID und Klick-Analytics getrennt speichern, damit der heiße Lesepfad schlank bleibt.

Beispielantwort

Ein Prozess ist ein eigenständiges Programm in Ausführung mit eigenem Speicherbereich. Ein Thread ist eine leichtgewichtige Ausführungseinheit innerhalb eines Prozesses, die sich Speicher mit anderen Threads desselben Prozesses teilt. Threads eignen sich, wenn Aufgaben häufig kommunizieren und Zustand teilen müssen, sie sind günstiger zu erzeugen und zwischen ihnen umzuschalten. Prozesse eignen sich für Isolation: Stürzt einer ab, laufen die anderen weiter. In der Praxis greife ich zu Threads für CPU-gebundene Parallelität innerhalb eines einzelnen Dienstes und zu Prozessen, wenn ich Speicherisolation brauche oder separate Dienste betreiben muss. In Python sorgt der GIL dafür, dass Threads keine echte CPU-Parallelität bieten, weshalb Multiprocessing dort für CPU-intensive Arbeit oft die richtige Wahl ist.

Beispielantwort

Eventual Consistency bedeutet, dass ein verteiltes System für einen gegebenen Schlüssel auf allen Knoten irgendwann denselben Wert zurückgibt, aber nicht zwingend sofort. Schreibvorgänge propagieren asynchron, daher können Lesevorgänge im Zeitfenster nach einem Schreibvorgang veraltete Daten liefern. Ich würde Eventual Consistency akzeptieren bei Dingen wie Like-Zählern in sozialen Netzwerken, der Synchronisierung von Nutzereinstellungen über Geräte hinweg oder Lagerbestandsaktualisierungen in einem Katalog, wo eine Verzögerung von ein bis zwei Sekunden keinen Schaden anrichtet. Ich würde sie nicht akzeptieren bei Finanztransaktionen, Authentifizierungs-Tokens oder personenbezogenen Daten im Sinne der DSGVO, wo veraltete oder inkonsistente Daten zu falschen Geschäftsergebnissen oder Compliance-Problemen führen könnten.

Beispielantwort

In Java verwendet die JVM einen generationellen Garbage Collector. Der Heap ist basierend auf der Objektlebensdauer in eine junge und eine alte Generation aufgeteilt. Die meisten Objekte sterben jung, daher führt der Collector häufige, günstige Minor-GCs auf der jungen Generation aus. Objekte, die mehrere Sammlungen überleben, werden in die alte Generation befördert, die seltener, dafür aufwendiger gesammelt wird. Die Collectoren G1 und ZGC minimieren Stop-the-World-Pausen, indem sie den Großteil der Arbeit nebenläufig erledigen. Der Kompromiss ist Speicher-Overhead und unvorhersehbare Pausenlatenz: Garbage Collection tauscht Durchsatz gegen automatische Speicherverwaltung. In latenzkritischen Systemen habe ich Heap-Größen und GC-Einstellungen angepasst und in Extremfällen Allokationen im heißen Pfad außerhalb des Heaps verlagert, um GC-Druck vollständig zu vermeiden.

Beispielantwort

Zuerst bewerte ich Schweregrad und Ausnutzbarkeit: Wird die Lücke bereits aktiv ausgenutzt, und setzt unser Nutzungsmuster uns dem Risiko aus? Wenn ja, eskaliere ich sofort an Teamleitung und Security-Kontakt und behandle es als Vorfall statt als normale Aufgabe. Zuerst suche ich nach einer gepatchten Version der Bibliothek. Existiert keine, prüfe ich, ob wir im eigenen Code eine Umgehung einbauen können, während wir auf einen Patch warten oder die Bibliothek wechseln. Ich kommuniziere den Status klar: wer betroffen ist, wie hoch das Risiko ist, was wir tun und welcher Zeitplan gilt. Der Sprint-Umfang ändert sich dadurch, die Sicherheitskorrektur landet zuerst. Sind personenbezogene Daten betroffen, prüfe ich zusätzlich, ob eine Meldepflicht nach DSGVO entsteht, und beziehe den Datenschutzbeauftragten frühzeitig ein.

Beispielantwort

Ich fasse nichts an, ohne es zuvor verstanden zu haben. Den ersten Tag verbringe ich damit, Einstiegspunkte, Datenfluss und wichtige Abhängigkeiten des Codes zu kartieren, ihn lokal auszuführen und Anfragen durch das System zu verfolgen. Bevor ich Feature-Code schreibe, ergänze ich Charakterisierungstests für die Bereiche, die ich ändern muss: Tests, die das aktuelle Verhalten festhalten, nicht das ideale. Das ist mein Sicherheitsnetz. Danach nehme ich die kleinstmöglichen Änderungen vor, um die Funktion hinzuzufügen, und ergänze saubere Unit-Tests für den neuen Code. Dem Drang, alles zu refaktorieren, was mir missfällt, widerstehe ich. Das ist ein eigenes Gespräch mit dem Team, mit eigenem Zeitplan und eigener Risikoabwägung.

Beispielantwort

Ich stelle zuerst sicher, dass ich den Ansatz vollständig verstehe, bevor ich widerspreche. Manchmal steckt hinter Komplexität ein Grund, den ich noch nicht sehe. Ich frage nach den Randbedingungen, die optimiert werden sollen. Halte ich meinen Ansatz weiterhin für besser, schreibe ich einen kurzen Vergleich: die Kompromisse jeder Option, was man gewinnt und aufgibt, und meine Empfehlung mit Begründung. Ich präsentiere es als 'Das sehe ich so, übersehe ich etwas?' statt als 'Ich habe recht.' Bevorzugt der Senior-Entwickler nach der Diskussion weiterhin seinen Ansatz, trage ich ihn mit und setze ihn gut um. Architektonische Meinungsverschiedenheiten sind eine gute Debatte wert, keinen andauernden Streit. In flacheren Teamstrukturen, wie sie bei vielen deutschen Scale-ups üblich sind, hilft es zusätzlich, die Entscheidung schriftlich in einem Architecture Decision Record festzuhalten, damit sie später nachvollziehbar bleibt.

Beispielantwort

Ich nenne keine einzelne Zahl für einen unklaren Umfang, diese Zahl wäre falsch, und ich würde später daran gemessen. Stattdessen stelle ich Klärungsfragen, um die Kernanforderung zu verstehen und die riskantesten Unbekannten zu identifizieren. Dann gebe ich eine Spanne an: 'Nach aktuellem Kenntnisstand sind das 3 bis 5 Tage, aber diese drei offenen Fragen könnten es auf 2 Wochen treiben.' Ich benenne, was ich brauche, um die Schätzung zu präzisieren: eine Entscheidung zum Verhalten in Randfällen, Zugriff auf ein bestimmtes System oder einen Tag, um den unbekannten Teil in einem Spike zu untersuchen. Gute Schätzungen sind ein Gespräch, kein aus der Luft gegriffener Termin.