Fragen im Vorstellungsgespräch für Programmierer / Softwareentwickler – und wie Sie sie beantworten

Häufige Fragen für Programmierer / Softwareentwickler

1. 01

   Erzählen Sie mir vom schwierigsten Bug, den Sie je debuggt haben. Wie haben Sie ihn gefunden und warum hat er Sie so viel Zeit gekostet?

   Beschreiben Sie nicht den Bug, sondern Ihre Methode: wie Sie ihn reproduziert haben, welche Hypothesen Sie verworfen haben und wie Sie die Ursache eingegrenzt haben. Bewertet wird Ihr Debugging-Prozess, nicht die Anekdote.

   „Wir hatten einen Zahlungsfehler, der nur in Produktion auftrat, bei einer von tausend Transaktionen. Zuerst habe ich ihn reproduzierbar gemacht: Ich habe die echten Payloads der fehlgeschlagenen Fälle mitgeschnitten und einen Test gebaut, der sie lokal nachspielte. Das Payment-Gateway habe ich ausgeschlossen, indem ich dessen Logs mit unseren verglichen habe, und korrupte Daten durch eine Schema-Validierung. Am Ende war es eine Race Condition: Zwei Webhooks derselben Zahlung kamen mit Millisekunden Abstand an, und der zweite überschrieb den ersten. Es hat mich eine Woche gekostet, weil das aggregierte Log die tatsächliche Ankunftsreihenfolge verschleierte. Gelöst habe ich es mit einem Lock pro Zahlungs-ID und einem Concurrency-Test, damit es nicht wieder passiert.“

2. 02

   Sie sind in einem Code-Review und ein Kollege merkt an, dass Ihre Lösung nicht skaliert. Was tun Sie?

   Zeigen Sie, dass Sie Ihr Ego vom Code trennen. Erzählen Sie, wie Sie nach dem konkreten Fall fragen, der Ihren Ansatz bricht, was Sie fragen, um die tatsächliche Grenze zu verstehen, und wann Sie zustimmen bzw. wann Sie mit Daten dagegenhalten.

   „Als Erstes bitte ich um den konkreten Fall: Ab welchem Volumen funktioniert mein Ansatz nicht mehr? Sagt er mir, dass meine Schleife bei 10.000 Elementen pro Request explodiert, prüfe ich das mit echten Produktionsdaten. Uns ist das mit einer Liste passiert, die ich im Speicher gelöst hatte: Er hatte recht für die 5 % der großen Konten, also habe ich die Abfrage paginiert. Wenn der Fall, den er anführt, aber weder in unseren Daten noch in der Roadmap existiert, sage ich das mit Zahlen: Wir bleiben heute beim Einfachen und halten die Grenze schriftlich fest. Ich stimme zu, wenn es Belege gibt, ich verteidige, wenn die Belege auf meiner Seite sind, und ich mache es nie persönlich.“

3. 03

   Entwerfen Sie mir grob ein System, das URLs kürzt (oder einen Feed, einen Warenkorb …). Wo fangen Sie an?

   Beginnen Sie mit den Fragen, nicht mit der Lösung: Volumen, Lese- vs. Schreibzugriffe, akzeptable Latenz. Wägen Sie die Trade-offs laut ab (Konsistenz vs. Verfügbarkeit, wo cachen), statt eine fertige Architektur aus dem Gedächtnis abzuspulen.

   „Bevor ich irgendetwas skizziere, würde ich drei Dinge fragen: Wie viele neue URLs pro Tag und wie viele Redirects? Können Links ablaufen? Ist Klick-Analytics wichtig? Nehmen wir tausend Schreib- und eine Million Lesezugriffe täglich: Das ist ein Lese-System, also optimiere ich dort. Ich würde 7-stellige Codes in Base62 aus einem Zähler mit pro Instanz vorreservierten Blöcken generieren, um Kollisionen ohne Koordination bei jedem Request zu vermeiden. Das Mapping käme in eine Key-Value-Datenbank, davor ein Cache für die 20 % der URLs, die 80 % des Traffics ausmachen. Der Redirect darf eventual consistent sein: Wenn ein Link eine Sekunde braucht, um sich zu verbreiten, ist das egal; das erlaubt mir, zu replizieren, ohne Schreibzugriffe zu blockieren.“

4. 04

   Warum haben Sie in Ihrem letzten Projekt [Ihre wichtigste Sprache / Ihr Framework] gewählt, und wann wäre das eine schlechte Idee gewesen?

   Sprechen Sie über echte Kriterien: Ökosystem, Performance, das Team, das es warten wird. Dass Sie erkennen, wann es NICHT die richtige Wahl war, zählt mehr, als es zu verteidigen, als wäre es für alles perfekt.

   „In meinem letzten Projekt habe ich TypeScript mit Node gewählt, weil das Team JavaScript bereits beherrschte, das Produkt eine API mit vielen Drittanbieter-Integrationen war und die Typisierung uns die dummen Vertragsfehler zwischen Services ersparte. Das war keine Mode-Entscheidung: Ich habe berücksichtigt, dass sich passende Leute leicht einstellen lassen und das Ökosystem ausgereifte Bibliotheken für unseren Bedarf hat. Wann wäre es eine schlechte Idee gewesen? Wenn der Kern rechenintensive CPU-Last, Bildverarbeitung oder harte Speicheranforderungen gewesen wäre: Da geht Node die Luft aus, und ich wäre zu Go oder Python mit nativen Erweiterungen gegangen. Tatsächlich haben wir einen PDF-Generierungs-Job am Ende in einen separaten Worker ausgelagert, weil er den Event Loop blockierte.“

5. 05

   Sie müssen ein Feature in einen Teil des Codes einbauen, den Sie nicht verstehen und den niemand dokumentiert hat. Wie gehen Sie vor?

   Zeigen Sie eine Strategie für Legacy-Code: Tests lesen, Ein- und Ausgaben nachverfolgen, kleine, überprüfbare Änderungen machen. Erwähnen Sie, was Sie ohne Sicherheitsnetz nicht anfassen würden.

   „Zuerst lese ich die Tests, falls es welche gibt: Sie sind die einzige Dokumentation, die nicht lügt. Gibt es keine, verfolge ich den Ablauf mit einem echten Fall: Ich setze Logs oder einen Debugger am Eingang und folge den Daten bis zum Ausgang, und daraus zeichne ich mir eine Karte, was was berührt. Bevor ich mein Feature einbaue, schreibe ich zwei, drei Charakterisierungstests, die das aktuelle Verhalten festnageln, auch wenn es mir seltsam vorkommt: Dieses Verhalten kann ein Vertrag sein, auf den sich jemand verlässt. Dann mache ich die kleinstmögliche Änderung und prüfe, dass die Tests grün bleiben. Was ich nicht tun würde: gleichzeitig refactoren und das Feature einbauen, oder ohne Netz etwas anfassen, das Geld oder Nutzerdaten bewegt – da kommen erst Tests, dann Änderungen.“

6. 06

   Erzählen Sie mir von einem Mal, als Sie bewusst eine technische Abkürzung (technische Schuld) genommen haben. Wie haben Sie das begründet?

   Machen Sie klar, dass es eine bewusste Entscheidung mit bekannten Kosten war, keine Nachlässigkeit. Erklären Sie, was Sie gewonnen haben (Deadline, eine Hypothese validieren), wie Sie es dokumentiert haben und welchen Plan es gab, die Schuld zurückzuzahlen.

   „Um eine Integration mit einem Großkunden zu validieren, habe ich seine Konfiguration hartkodiert, statt das eigentlich fällige kundenspezifische Konfigurationssystem zu bauen. Ich habe das gemeinsam mit meinem Vorgesetzten entschieden: Das Generische hätte drei Wochen gedauert, und der Kunde entschied in einer. Die Abkürzung habe ich sichtbar markiert: ein Kommentar mit dem Warum, ein Ticket im Backlog mit der geschätzten richtigen Lösung und ein Alert, falls ein anderer Kunde diesen Code erreicht. Der Kunde unterschrieb, und im folgenden Quartal haben wir die Schuld mit dem generischen System beglichen. Für mich ist das der Unterschied zwischen guter und schlechter Schuld: Die gute hat ein Datum, einen Verantwortlichen und Kosten, die jemand ausdrücklich akzeptiert hat; die schlechte ist die, die sechs Monate später als Überraschung auftaucht.“

7. 07

   Der Unterschied zwischen zwei ähnlich wirkenden Dingen in Ihrem Stack (z. B. Liste vs. Dictionary, SQL vs. NoSQL, synchron vs. asynchron): Wann setzen Sie was ein?

   Antworten Sie mit dem Wann, nicht mit der Lehrbuchdefinition. Verankern Sie jede Option in einem Anwendungsfall und den Kosten, die Sie in Kauf nehmen (Speicher, Latenz, Komplexität). Nennen Sie, wenn möglich, ein Mal, als Sie falsch gewählt und umgesteuert haben.

   „SQL gegen NoSQL zum Beispiel: Das ist kein Glaubenskrieg, sondern eine Frage an Ihre Daten. Wenn es Beziehungen gibt, die zählen (Bestellungen, Kunden, Rechnungen), und Sie Transaktionen brauchen: SQL, weil die Datenbank Ihnen die Garantien gibt und Sie sie nicht im Code nachbauen müssen. NoSQL nehme ich, wenn das Schema volatil ist oder das Volumen einfacher Lesezugriffe riesig: Sessions, denormalisierte Kataloge, Events. Der Preis bei NoSQL ist, dass die Fragen, die Sie nicht vorhergesehen haben, teuer werden. Ist mir passiert: Wir haben Analytics auf einer Dokumentendatenbank aufgebaut, und nach sechs Monaten war jeder neue Report eine Qual; wir haben diesen Teil zu Postgres migriert, und die Abfragen schrumpften von Stunden Arbeit auf einen JOIN.“

8. 08

   Ihr Code läuft lokal, schlägt aber in Produktion fehl. Was prüfen Sie zuerst?

   Listen Sie Verdächtige nach Wahrscheinlichkeit auf: Umgebungsvariablen, Dependency-Versionen, echte vs. Testdaten, Nebenläufigkeit, Zeitzone. Wichtig ist die Reihenfolge Ihres Denkens, nicht, die genaue Ursache zu erraten.

   „Ich gehe nach Wahrscheinlichkeit vor. Erstens Konfiguration: Umgebungsvariablen, die fehlen oder woandershin zeigen – die häufigste und am billigsten zu prüfende Ursache. Zweitens Daten: Lokal teste ich mit sauberen Daten, und Produktion hat die Sonderfälle (Nulls, Umlaute, Datensätze von 2015). Drittens Versionen: Wurde das Lockfile beim Deployment respektiert? Ist die Node- oder Datenbankversion dieselbe? Viertens alles, was es lokal nicht gibt: echte Nebenläufigkeit, Netzwerklatenz, Berechtigungen, die Zeitzone des Servers. Und während ich prüfe, schaue ich mir die Logs des echten Fehlers in Produktion an, statt zu vermuten: In der Hälfte der Fälle verrät der Stacktrace schon, in welcher dieser vier Familien man steckt.“

Viele dieser Fragen sind vom Typ „Erzählen Sie mir von einer Situation, in der…“. Um solche Antworten mit einer klaren Geschichte zu strukturieren, nutzen Sie die STAR-Methode.

Tipps, mit denen Sie sich abheben

• Denken Sie beim Coding laut. Schweigen kostet Sie mehr Punkte als ein Fehler: Der Interviewer muss Ihr Denken sehen, nicht nur das Ergebnis.
• Wiederholen Sie vor dem Coden das Problem und fragen Sie nach den Randfällen. Loszutippen, ohne die Anforderungen zu klären, ist das Alarmsignal Nummer eins.
• Wenn Sie eine technische Entscheidung verteidigen, benennen Sie den Trade-off, den Sie akzeptiert haben. „Ich habe X gewählt, obwohl ich wusste, dass Y“ klingt nach Senior; „X ist besser“ klingt nach Junior.
• Halten Sie zwei, drei Projekte bereit, die Sie im Detail erzählen können: welches Problem sie lösten, Ihre schwierigste Entscheidung und was Sie anders machen würden. Daraus entsteht die Hälfte der Nachfragen.

Fragen für andere Positionen

• Vorstellungsgespräch für Marketing-Spezialist
• Vorstellungsgespräch für Bürokaufmann/-frau
• Vorstellungsgespräch für Buchhalter/in