Was Backend-Interviews tatsächlich prüfen

Du hast nach einer Fragenliste gesucht. Davon gibt es viele, und die meisten sind nutzlos, weil ein Backend-Interview nicht ein Test ist, der viermal wiederholt wird. Es sind drei oder vier verschiedene Tests, durchgeführt von verschiedenen Personen, die verschiedene Dinge bewerten, und eine Liste reduziert sie zu Trivialitäten. Jemand, der das CAP-Theorem aufsagen kann, fällt trotzdem in der Design-Runde durch. Jemand, der das Array-Problem in fünfzehn Minuten löst, fällt trotzdem im Deep Dive zur eigenen Arbeit durch.

Was folgt, ist die Struktur der Sache und wonach die Person auf der anderen Seite tatsächlich hört.

Die Struktur des Interviews

Für eine mittlere oder Senior-Backend-Rolle in einem Unternehmen mit mehr als etwa fünfzig Entwicklern besteht das Interview üblicherweise aus einer Teilmenge von:

1. Recruiter-Screening, 20–30 Minuten. Stack, Level, Kündigungsfrist, Standort und Visum, Gehaltsvorstellungen, ob du jetzt im Bereitschaftsdienst bist und ob du bereit wärst.
2. Gespräch mit dem Hiring Manager, 30–45 Minuten. Wofür du verantwortlich bist, was du ausgeliefert hast, warum du gehst. Manchmal eine leichte technische Prüfung.
3. Eine Coding-Aufgabe. Live in einem gemeinsamen Editor, live in deinem eigenen Repo im Pairing mit einem Entwickler oder ein Take-home, das du einreichst und dann durchgehst.
4. Eine System-Design-Runde, 45–60 Minuten, Whiteboard oder eine leere Excalidraw-Canvas.
5. Ein Deep Dive zu etwas, das du gebaut hast, manchmal mit der Design-Runde zusammengelegt, manchmal separat.
6. Eine Verhaltens- oder funktionsübergreifende Runde, oft mit einem Entwickler aus einem anderen Team oder einem Product Manager.

Kleinere Unternehmen komprimieren das: ein Gründergespräch, ein Take-home, ein finales Onsite, das alles auf einmal macht. Big-Tech-Interviews fügen eine dedizierte Runde für das eigene Wertesystem hinzu und gewichten das algorithmische Coding möglicherweise viel stärker. Ob ein umfangreiches algorithmisches Screening die Arbeitsleistung vorhersagt, ist ernsthaft umstritten — du findest Entwickler mit starken Meinungen in beide Richtungen und sehr wenig öffentliche Evidenz in die eine oder andere. Es ist trotzdem die Hürde an vielen Orten, also ist die praktische Frage nicht, ob es fair ist, sondern ob dieser bestimmte Arbeitgeber es verwendet. Frag den Recruiter. Er wird es dir sagen, und das Format, das er nennt, sagt dir, was du vorbereiten sollst.

Wer tatsächlich im Raum ist

Die Coding-Runde wird üblicherweise von einem Senior Engineer im oder nahe am Team durchgeführt, manchmal mit einer zweiten Person, die schweigend Notizen macht. Sie haben eine Bewertungsmatrix. Sie versuchen nicht, dich auszutricksen, und in Runde drei sind sie meistens gelangweilt, was schlimmer ist.

Die Design-Runde wird häufiger von einem Staff oder Principal Engineer durchgeführt oder einem erfahrenen Senior, der das häufig macht. Diese Person hat Meinungen über Queues, und sie wurde um 04:00 Uhr von etwas geweckt, das du gleich beiläufig beschreiben wirst.

Der Deep Dive kann der Hiring Manager oder ein Tech Lead sein. Ihre Aufgabe ist es festzustellen, ob die Entscheidungen in deinen Geschichten deine waren oder dir übergeben wurden.

Das ist wichtig, weil dieselbe Antwort je nachdem, wer fragt, unterschiedlich bewertet wird. "Wir haben Kafka verwendet" ist eine Tatsache für einen Recruiter, ein Ausgangspunkt für einen Manager, und für den Staff Engineer ist es eine Einladung zu fragen, warum nicht SQS, was dein Partition-Key war und was mit der Reihenfolge passierte, als du neu verarbeiten mussstest.

Die Coding-Aufgabe und was sie wirklich bewertet

Drei Formate dominieren, und sie bewerten verschiedene Dinge.

Algorithmisches Screening. Üblicherweise 45 Minuten, ein oder zwei Probleme, Hash Maps und Two Pointers und gelegentlich Graph Traversal. Die Bewertung ist hauptsächlich: bist du zu einer funktionierenden Lösung gekommen, hast du dabei gesprochen, hast du die Komplexität bemerkt, hast du sie getestet. Schweigen ist der häufige Fehlermodus, nicht Falschheit.

Realistische Aufgabe. Zunehmend verbreitet bei mittelgroßen Unternehmen. Parse diese Datei und stelle sie über HTTP bereit. Implementiere einen Rate Limiter. Füge einen Endpoint zu diesem bestehenden Repo hinzu. Hier liegt die Bewertung näher an einem tatsächlichen Code Review: behandelst du Fehler oder verschluckst du sie, validierst du Input, sind deine Namen sinnvoll, hast du einen Test geschrieben, hast du die Mehrdeutigkeit in der Spec bemerkt und gefragt statt zu raten.

Pairing an einer echten Codebase. Du wirst in ein unbekanntes Repo mit einem Bug oder einem kleinen Feature gesetzt. Das testet Navigation mehr als Autorschaft: kannst du finden, wo das Ding liegt, liest du zuerst die Tests, führst du es aus, bevor du es änderst.

In allen dreien kommt die Sprachfrage auf. Wenn du Go wählst, erwarte, dass jemand nach Context Cancellation, Goroutine Leaks oder warum du einen Channel verwendet hast, wo ein Mutex einfacher gewesen wäre, fragt. Wenn du Java wählst, erwarte die JVM: Heap versus Off-Heap, was eine Full-GC-Pause mit deinem p99 macht, Thread-Pool-Sizing und etwas Spring-förmiges über Bean Scopes oder Transaction Boundaries. Python lädt zum GIL ein und ob dein blockierender Call gerade die Event Loop zum Stehen gebracht hat. Node lädt zur gleichen Frage in anderer Verkleidung ein. Wähle die Sprache, die du tatsächlich schreibst, nicht die, von der du denkst, dass sie senior klingt.

System Design: die Fragen innerhalb der Frage

Die Aufgabenstellung wird breit sein — entwirf einen URL-Shortener, einen Notification-Service, ein Ticket-Buchungssystem, was auch immer der Interviewer vierzigmal durchgeführt hat. Die Aufgabenstellung ist nicht der Test. Der Test ist die Reihe der Nachfragen, und die sind ziemlich vorhersagbar, weil es die Dinge sind, die tatsächlich in Production kaputtgehen.

Idempotenz. "Der Client ruft POST /payments auf, läuft in ein Timeout und versucht es erneut. Was jetzt?" Eine gute Antwort greift zu einem vom Client gelieferten Idempotency-Key, einem Unique Constraint in der Datenbank und einer Entscheidung, was bei einem Duplikat zurückgegeben wird. Eine sehr gute Antwort erwähnt die Transactional Outbox, weil du gleich ein Event über diese Zahlung publizieren wirst und das Schreiben und das Publizieren nicht atomar sind.

Delivery-Semantik. Nahezu jede Queue, die du nennst, ist At-Least-Once. Also: wie belastest du den Kunden nicht zweimal, und was ist dein Deduplizierungsfenster, und wo liegt der Dedup-State, und was passiert, wenn er abläuft. Wenn du "Exactly-Once" sagst, ohne sofort zu qualifizieren, was du meinst, hast du dem Interviewer seine nächste Frage geliefert.

Fehlerpropagierung. "Dein Service ruft einen Downstream-Service auf, der gerade langsam geworden ist — nicht down, langsam." Die Antwort, die sie wollen, geht die Kette durch: Requests halten Connections länger, der Pool sättigt, deine eigene Queue wächst, deine Latenz steigt, deine Caller laufen ins Timeout und versuchen es erneut, und die Retries verstärken die Last auf das Ding, das schon zu kämpfen hatte. Dann die Mitigationen: Timeouts, die tatsächlich gesetzt sind, Budgets statt Per-Call-Timeouts, Exponential Backoff mit Jitter, Circuit Breakers, Bulkheads, Load Shedding. Die Phrase "Retry Storm" bringt dir Punkte, weil es zeigt, dass du einen gesehen hast.

Daten. Erwarte Index-Fragen, die als Symptome statt als Theorie formuliert sind: eine Query, die letzten Monat schnell war und jetzt ohne Code-Änderung langsam ist. Plan Flips, veraltete Statistiken, eine Selektivitätsannahme, die nicht mehr hielt, als die Tabelle wuchs, Lock Contention, Bloat und Vacuum-Verhalten in Postgres. Erwarte eine Schema-Migration-Frage — Umbenennen oder Aufteilen einer Spalte ohne Downtime — wo die erwartete Antwort Expand and Contract ist: füge die neue Spalte hinzu, schreibe dual, backfille in Batches, verschiebe Reads, höre auf, die alte zu schreiben, droppe sie später.

Caching. "Füge einen Cache hinzu" ist der Beginn der Konversation. Die Nachfragen sind Invalidierungsstrategie, TTL versus explizite Eviction, was mit der Origin passiert, wenn ein Hot Key abläuft und tausend Requests auf einmal ankommen, und ob du bereit bist, stale Daten zu liefern und wie lange.

Messung. Wenn du sagst, ein System ist schnell, wird jemand fragen, woher du das weißt, und die richtige Währung sind Percentiles und Error Rates, nicht Durchschnitte. Zu wissen, warum der Mittelwert das Problem verbirgt — und dass der User, der das p99 erfährt, oft dein wertvollster User ist, weil er die meisten Daten hat — ist eine kleine Sache, die als Erfahrung gelesen wird.

Der Deep Dive zur eigenen Arbeit

Diese Runde entscheidet über Seniority häufiger als die Coding-Runde. Die Aufforderung ist eine Version von "erzähl mir von einem System, das du entworfen oder wesentlich verändert hast." Dann:

• Was waren die Alternativen, und warum hast du sie verworfen?
• Was hast du falsch gemacht?
• Was ist kaputtgegangen, nachdem es ausgeliefert wurde?
• Woher wusstest du, dass es funktioniert?
• Was würdest du jetzt anders machen?
• Wer war anderer Meinung als du, und was ist passiert?

Der Interviewer testet, ob du derjenige warst, der Entscheidungen getroffen hat. Kandidaten, die ein Design geerbt haben, beschreiben es wunderschön und haben dann nichts, wenn nach den Alternativen gefragt wird, weil es aus ihrer Sicht nie welche gab. Das ist in Ordnung — sag es so, und beschreibe eine Entscheidung, die wirklich deine war, auch wenn sie kleiner war. Eine gut begründete Wahl darüber, wie man zweihundert Millionen Zeilen backfilled, ist bessere Evidenz als ein vager Bericht über eine Architektur, die jemand anders gezeichnet hat.

Halte Rollout-Details bereit. Feature Flag oder prozentualer Rollout, was der Kill Switch war, welche Metrik du beobachtet hast, was der Rollback-Plan war und ob du ihn verwenden musstest. Halte einen Incident bereit, in dem du die Ursache warst. Blameless ist die Kultur; den Fehler ohne Theatralik zu besitzen ist das Signal.

Wie eine oberflächliche Antwort klingt

Von der anderen Seite des Tisches sind das die Anzeichen:

• "Wir haben Kafka verwendet, weil es skaliert." Kein Partition-Key, keine Consumer Group, keine Erwähnung, welche Reihenfolgengarantie du brauchtest oder verloren hast.
• "Wir würden Redis hinzufügen." Cache als Lösung genannt, ohne Invalidierungsgeschichte, ohne TTL, ohne Gedanken über die Stampede.
• "Microservices." Als Architektur angeboten statt als Trade-off — keine Erwähnung der Transaktion, die du gerade verloren hast, des Netzwerk-Calls, den du gerade hinzugefügt hast, oder wie du sie jetzt sowieso zusammen deployst.
• "Wir würden diese Spalte indizieren." Ohne Sinn für Kardinalität, Schreibkosten oder ob die Query ihn überhaupt verwenden würde.
• "Es ist eventually consistent." Als Antwort verwendet statt als Beschreibung eines Problems, das du dann im UI oder im Reconciliation-Job handhaben musst.
• "Es war schnell, so 50 Millisekunden." Durchschnitt, bei welcher Last, wo gemessen.
• "Wir haben hundert Prozent Test-Coverage." Freiwillig genannt ohne jeden Bericht darüber, was die Tests tatsächlich assertieren, ob sie gegen eine echte Datenbank laufen oder wie Flakes behandelt werden.
• "Das müsste ich nachschlagen." In Ordnung für ein Syntax-Detail. Nicht in Ordnung als Antwort darauf, was passiert, wenn der Downstream deines Service langsam wird.

Der gemeinsame Nenner ist ein Substantiv, wo ein Trade-off sein sollte. Eine Technologie zu nennen ist keine Antwort; zu beschreiben, was sie dich kostet und warum du diese Kosten akzeptiert hast, ist eine.

Was als Nächstes zu tun ist

Vier Dinge, in der Reihenfolge, wie sehr sie den Ausschlag geben.

Schreibe zwei deiner eigenen Systeme ordentlich auf. Ein Diagramm, die drei Entscheidungen, die du tatsächlich getroffen hast, die Alternativen, was kaputtging, was du gemessen hast. Eine Stunde jeweils. Das ist die Runde, die am häufigsten verloren und am seltensten vorbereitet wird.

Probe die Fehlerkette laut. Langsamer Downstream, Pool-Sättigung, Retry-Verstärkung und die vier Mitigationen. Wenn du es fließend sagen kannst, wird ein großer Teil der Design-Nachfragen zur gleichen Antwort in anderem Kostüm.

Wähle eine Sprache und sei bereit für ihre scharfen Kanten. Ein Absatz jeweils zum Memory Model oder Concurrency Model, wie du ein Leak finden würdest und wie du einen langsamen Endpoint profilieren würdest.

Frag den Recruiter, wie die Coding-Runde ist. Algorithmisch, realistisch oder Pairing. Er wird es dir sagen, und die drei verlangen unterschiedliche Vorbereitung. Sich auf die falsche vorzubereiten ist der häufigste vermeidbare Verlust in diesem Prozess.