Leitfaden für Softwareentwickler-Interviews

Vorgehensweise — Komplement in einer Hash-Tabelle speichern

Durchlaufe das Array einmal. Für jeden Wert x prüfst du, ob target − x bereits in einer Hash-Tabelle liegt. Falls ja, gib den gespeicherten Index und den aktuellen Index zurück; andernfalls speicherst du x mit seinem Index. So wird jedes Element genau einmal verarbeitet. Die Laufzeit beträgt O(n), der zusätzliche Speicher O(n). Kläre vorher, ob genau eine Lösung existiert und ob derselbe Index zweimal verwendet werden darf.

Vorgehensweise — Sliding Window mit zuletzt gesehenem Index

Halte ein Fenster [left, right] ohne Duplikate und speichere für jedes Zeichen seinen letzten Index. Taucht ein Zeichen erneut innerhalb des Fensters auf, verschiebst du left auf lastSeen + 1. Danach aktualisierst du den Index und die maximale Fensterlänge. Wichtig ist, left niemals zurückzusetzen. Laufzeit O(n), Speicher O(k) für den Zeichensatz.

Vorgehensweise — Kanonischen Schlüssel je Wort bilden

Bilde für jedes Wort einen kanonischen Schlüssel und gruppiere Wörter mit gleichem Schlüssel in einer Hash-Tabelle. Der Schlüssel kann die sortierte Zeichenfolge sein; bei festem Alphabet ist ein Vektor der Zeichenhäufigkeiten effizienter. Mit Sortierung beträgt die Laufzeit O(n · m log m), mit Häufigkeitsvektor O(n · m), wobei m die Wortlänge ist.

Vorgehensweise — Drei Zeiger: vorheriger, aktueller und nächster Knoten

Initialisiere prev mit null und current mit dem Kopf. Sichere in jeder Iteration current.next, setze current.next auf prev und verschiebe beide Zeiger. Am Ende ist prev der neue Kopf. Die Schleifeninvariante lautet: prev zeigt stets auf die bereits umgekehrte Teilliste. Laufzeit O(n), Speicher O(1).

Vorgehensweise — Für jeden Knoten gültige Unter- und Obergrenze weitergeben

Ein lokaler Vergleich mit den Kindern reicht nicht. Durchlaufe den Baum rekursiv und übergib für jeden Knoten den zulässigen Wertebereich. Links wird die Obergrenze zum aktuellen Wert, rechts die Untergrenze. Verletzt ein Knoten seine Grenzen, ist der Baum ungültig. Kläre die Regel für Duplikate. Laufzeit O(n), Speicher O(h) für die Rekursion.

Vorgehensweise — Breitensuche nach Entfernungsebenen

Behandle jede begehbare Zelle als Knoten und führe ab dem Start eine BFS aus. Markiere Zellen beim Einreihen als besucht, damit sie nicht mehrfach in der Warteschlange landen. Die erste erreichte Zielzelle liefert wegen der Ebenenreihenfolge den kürzesten Weg. Für den tatsächlichen Pfad speicherst du Vorgänger. Laufzeit und Speicher sind O(Zeilen · Spalten).

Vorgehensweise — Abbildung vom Originalknoten auf seinen Klon

Nutze DFS oder BFS und eine Hash-Tabelle, die jeden Originalknoten seinem Klon zuordnet. Erzeuge den Klon beim ersten Besuch, speichere ihn sofort und klone anschließend die Nachbarn. Das frühe Speichern verhindert Endlosschleifen bei Zyklen und bewahrt gemeinsam genutzte Nachbarn. Laufzeit und Speicher sind O(V + E).

Vorgehensweise — Bottom-up-DP über alle Beträge

Definiere dp[a] als kleinste Münzanzahl für Betrag a. Setze dp[0] = 0 und alle anderen Werte auf unendlich. Für jeden Betrag prüfst du jede Münze c mit c ≤ a und aktualisierst dp[a] = min(dp[a], dp[a − c] + 1). Bleibt der Zielwert unendlich, ist er nicht darstellbar. Laufzeit O(Betrag · Münzanzahl), Speicher O(Betrag).

Vorgehensweise — DP nach Endposition, anschließend mit binärer Suche optimieren

Die einfache Lösung definiert dp[i] als Länge der längsten wachsenden Teilfolge, die bei i endet. Für alle j < i mit nums[j] < nums[i] aktualisierst du dp[i]. Das kostet O(n²). Die optimierte Variante hält für jede Länge den kleinsten möglichen Endwert und ersetzt ihn per binärer Suche; so sinkt die Laufzeit auf O(n log n).

Vorgehensweise — Nur gültige Präfixe erzeugen

Baue den String schrittweise auf. Eine öffnende Klammer darf hinzugefügt werden, solange open < n. Eine schließende Klammer ist nur erlaubt, wenn close < open. Sobald die Länge 2n erreicht, ist eine gültige Kombination vollständig. Weil ungültige Präfixe nie entstehen, wird der Suchraum früh beschnitten.

Vorgehensweise — Anforderungen → API → ID-Erzeugung → Speicher → Weiterleitung → Skalierung

Nutzer senden eine lange URL und erhalten einen kurzen Code; Aufrufe müssen schnell weiterleiten. Zentrale APIs sind createShortUrl und redirect. Der Datensatz enthält Code, Ziel-URL, Nutzer, Erstellungs- und Ablaufzeit sowie Status. Codes können aus fortlaufenden IDs in Base62 oder zufällig mit Kollisionsprüfung entstehen. Der Leseweg nutzt einen Cache vor der Datenbank, prüft Status und Ablauf und antwortet mit 301 oder 302. Analytik läuft asynchron über eine Queue. Für Skalierung kommen Edge-Caches, Sharding nach Code, Rate Limits und Missbrauchsprüfungen hinzu.

Vorgehensweise — Nutzer → Beiträge → Fanout → Ranking → Lesen → Konsistenz

Ich nehme einen Feed abonnierter Konten an. Kernobjekte sind Nutzer, Follow-Beziehungen, Beiträge, Medien, Feed-Einträge und Interaktionen. Dienste für Beiträge, Graph, Feed und Ranking arbeiten mit Cache, Objektspeicher und Queue zusammen. Fanout beim Schreiben erzeugt schnelle Lesezugriffe, wird aber bei Konten mit Millionen Followern teuer. Fanout beim Lesen spart Schreibarbeit, erhöht jedoch die Leselatenz. Ein hybrides Modell verteilt normale Konten beim Schreiben und behandelt sehr große Konten beim Lesen. Wichtige Themen sind Aktualität, Datenschutzregeln, Queue-Ausfälle, Cache-Invalidierung und Spam.

Vorgehensweise — Verbindungen → Nachrichtenfluss → Speicherung → Zustellung → Zuverlässigkeit

Clients halten WebSocket-Verbindungen zu Gateways. Beim Senden authentifiziert das Gateway, verwendet einen Idempotenzschlüssel, speichert die Nachricht dauerhaft, veröffentlicht ein Ereignis und stellt sie an aktive Empfänger zu. Offline-Nutzer erhalten Push-Nachrichten und synchronisieren später ab dem zuletzt gesehenen Stand. Das Datenmodell umfasst Unterhaltung, Teilnehmer, Nachricht, Zustell- und Lesestatus sowie Geräte. Idempotenzschlüssel verhindern Duplikate, Sequenznummern je Unterhaltung ordnen Nachrichten, Bestätigungen und Wiederholungen sichern die Zustellung. Anhänge gehören in Objektspeicher. Zu überwachen sind Sendelatenz, Zustellrate, Verbindungen, Wiederverbindungen, Queue-Rückstand und Schreibfehler.

Vorgehensweise — Signal prüfen → Umfang eingrenzen → Änderungen prüfen → Abhängigkeiten zerlegen → Auswirkung mindern

Zuerst bestätige ich das Signal in mehreren Monitoren und prüfe p50, p95, p99 sowie betroffene Endpunkte. Danach segmentiere ich nach Region, Zone, Version, Host, Kunde, Anfrageart und Abhängigkeit. Ich untersuche Deployments, Konfiguration, Migrationen, Verkehrsspitzen, Feature Flags, Cache-Verhalten und nachgelagerte Störungen. Traces zerlegen die Latenz; ergänzend prüfe ich Datenbankzeiten, Trefferquote, Queue-Rückstand, CPU, Speicher, Garbage Collection und Verbindungspools. Bei Nutzerauswirkung kommt Minderung vor perfekter Ursachenanalyse: Rollback, Flag deaktivieren, skalieren oder eine langsame Abhängigkeit umgehen.

Vorgehensweise — Normalfälle → Grenzen → Ungültige Eingaben → Invarianten

Zuerst kläre ich Rabattarten, Kombinationen, Ablauf, Mindestwert, Berechtigung, Rundung und die Behandlung von Steuern und Versand. Unit-Tests decken keinen Rabatt, Prozent- und Festbetrag, Mindestwert exakt und knapp darunter, abgelaufene Angebote, unberechtigte Nutzer und Kombinationen ab. Invarianten: Der Endpreis ist nie negativ, der Rabatt übersteigt nicht den berechtigten Betrag, abgelaufene Aktionen gelten nicht und dieselbe Eingabe liefert dasselbe Ergebnis. Bei Zahlungsbezug ergänze ich Integrationstests und protokolliere Entscheidungen mit Grundcodes.

Vorgehensweise — Korrektheit → Wartbarkeit → Risiko → Klarheit

Ich prüfe schrittweise: Löst die Änderung das beabsichtigte Problem korrekt? Ist sie mit klaren Namen und Grenzen wartbar? Welche Risiken entstehen bei Migration, Nebenläufigkeit, Sicherheit, Leistung, Kompatibilität und Beobachtbarkeit? Decken Tests das geänderte Verhalten ab? Ich trenne blockierende Fehler von Vorschlägen. Korrektheits-, Sicherheits- oder Migrationsprobleme blockieren; Geschmacksfragen nicht. Ein Review soll Code und Teamgeschwindigkeit verbessern, nicht Überlegenheit demonstrieren.

Vorgehensweise — Kontext → Optionen → Zielkonflikte → Entscheidung → Ergebnis

Wähle eine Entscheidung mit echten Alternativen, etwa selbst entwickeln gegen einkaufen, SQL gegen NoSQL, schneller Patch gegen grundlegende Überarbeitung oder starke Konsistenz gegen Verfügbarkeit. Erkläre Kontext, Einschränkungen und die geprüften Optionen. Benenne den Zielkonflikt ausdrücklich und zeige, welche Belege entschieden haben: Verkehr, Kundenfrist, Vorfälle, Teamkapazität oder Roadmap. Schließe mit dem Ergebnis und dem, was du gelernt hast. Eine reife Antwort darf auch erklären, was du heute anders machen würdest.

Vorgehensweise — Vorfall → Auswirkung → Reaktion → Ursache → Vorbeugung

Beginne mit der Auswirkung auf Nutzer: Was fiel aus, wer war betroffen und wie schwer war der Vorfall? Beschreibe dann deinen Beitrag zu Erkennung, Eingrenzung, Rollback, Minderung, Kommunikation oder Ursachenanalyse. Während eines Vorfalls hat die Wiederherstellung Vorrang vor dem Beweis einer Theorie. Zeige, wie du Logs, Kennzahlen, Traces, Feature Flags, Rollbacks oder Abhängigkeitsprüfungen genutzt hast. Erkläre nach der Minderung die Ursache und konkrete Vorbeugung, etwa bessere Tests, sicherere Einführungen, Monitoring oder Runbooks. Vermeide persönliche Schuldzuweisung.

Vorgehensweise — Gemeinsames Ziel → Einschränkungen → Optionen → Zielkonflikte → Entscheidung

Zuerst gleiche ich Nutzer- und Geschäftsziel ab. Viele Konflikte beruhen auf unterschiedlichen Annahmen. Ich erläutere die technische Einschränkung präzise, etwa Komplexität, Zuverlässigkeit, Zeit, Wartbarkeit, Sicherheit oder Leistung. Statt nur Nein zu sagen, biete ich Optionen an: kleineres MVP, vorübergehend manueller Ablauf, Feature Flag, gestaffelte technische Arbeit oder einfacheres Design. Bei bedeutenden Risiken dokumentiere ich Optionen, Folgen und Empfehlung. Ziel ist nicht, dass Engineering gewinnt, sondern eine bewusste und transparente Teamentscheidung.