Interviewfragen zu technischen Entscheidungen mit Antworten

Beispielfragen

Ein paar Fragen aus jedem Level mit richtiger Antwort und Erklärung.

Technische Entscheidungen · Junior

1. Eine serverseitig gerenderte Seite lässt Gäste ein dunkles Theme wählen. Schon das allererste HTML muss das richtige Theme nutzen, ohne Aufblitzen. Wo speicherst du die Wahl?
   ▸Antwort zeigen

   Richtige Antwort: In einem Cookie, das der Server bei jeder Anfrage liest

   Nur ein Cookie erreicht den Server mit der Anfrage, das HTML lässt sich also sofort im richtigen Theme rendern. localStorage passt zu reinen Client-Apps oder wenn ein kleines Inline-Skript das Theme vor dem Paint setzen darf. Eine Datenbanktabelle passt zu angemeldeten Nutzern, die die Einstellung auf jedem Gerät wollen, aber Gäste haben kein Konto.

2. Ein Suchfeld ruft eine API auf, die pro Anfrage abgerechnet wird. Ergebnisse sollen beim Tippen erscheinen, aber nicht bei jedem Tastendruck. Was passt?
   ▸Antwort zeigen

   Richtige Antwort: Debounce: anfragen nach einer kurzen Tipppause

   Debounce sendet eine Anfrage, sobald das Tippen pausiert, eine Folge von Tastendrücken kostet also einen Aufruf, und Ergebnisse erscheinen trotzdem ohne zusätzliche Aktion. Throttle passt zu fortlaufenden Strömen wie Scrollen oder Größenänderung, wo regelmäßige Updates während der Aktivität zählen, würde aber halb getippte Wörter abrechnen. Suchen bei Enter ist am billigsten und passt zu teuren Suchen, bricht aber die Anforderung, Ergebnisse beim Tippen zu zeigen.

3. Ein beliebter Blog bekommt seine Artikel ein paar Mal am Tag bearbeitet. Suchmaschinen-Traffic ist wichtig, und bis zu einer Stunde alter Text ist in Ordnung. Wie renderst du die Seiten?
   ▸Antwort zeigen

   Richtige Antwort: Vorab rendern und etwa stündlich neu validieren

   Vorab-Rendern mit periodischer Revalidierung liefert Lesern und Crawlern schnelles gecachtes HTML, und eine Stunde Veraltung ist hier erlaubt. Rendern pro Anfrage passt zu personalisierten Seiten oder Daten, die bei jedem Besuch aktuell sein müssen, und würde hier nur Last erzeugen. Clientseitiges Rendern passt zu privaten Dashboards, macht aber das erste Paint langsamer und passt schlecht zu Seiten, die von der Suche abhängen.

4. Der Katalog eines Onlineshops hat 10.000 Produkte. Käufer vergleichen Artikel, teilen Links zu einer Position und brauchen den Footer. Wie zeigst du die Liste an?
   ▸Antwort zeigen

   Richtige Antwort: Nummerierte Seiten mit der Seitenzahl in der URL

   Nummerierte Seiten geben jeder Position eine teilbare URL und halten den Footer erreichbar, genau das braucht dieser Katalog. Infinite Scroll passt zu Feeds, die man ziellos durchstöbert und wo die Position egal ist. Eine virtualisierte Liste passt zu einem datenlastigen Werkzeug, in dem alle Zeilen im Client gebraucht werden, aber den ganzen Katalog herunterzuladen ist hier Verschwendung.

Technische Entscheidungen · Middle

1. Ein News-Feed bedient 1 Mio. Nutzer, darf eine Minute hinterherhinken, und jeder Aufruf der Upstream-API kostet Geld. Was ist der Hauptansatz?
   ▸Antwort zeigen

   Richtige Antwort: Ein geteilter Server-Cache mit einer TTL von etwa 60 Sekunden

   Ein geteilter Eintrag heißt, alle Nutzer kosten einen Upstream-Aufruf pro Minute, und die Minute Verzögerung ist erlaubt. Ein Browser-Cache passt zu persönlichen Daten und spart wiederholte Besuche, aber bei 1 Mio. Nutzern zahlt trotzdem jeder einen Upstream-Aufruf. Holen bei jedem Besuch passt zu Daten, die exakt sein müssen, etwa ein Kontostand, und würde hier die Rechnung ohne Nutzen vervielfachen.

2. Nach einer Überweisung öffnet der Nutzer seinen Kontostand. Die Zahl muss exakt sein, während der Rest der Banking-App aus Replicas liest. Wohin geht dieser Lesezugriff?
   ▸Antwort zeigen

   Richtige Antwort: An den Primary, ohne Cache dazwischen

   Geld, das direkt nach einem Schreibvorgang gezeigt wird, muss diesen widerspiegeln, und der Primary ist der einzige Ort, der das garantiert. Eine Replica passt zu Listen und Historie, wo eine Sekunde Verzögerung harmlos ist. Ein Cache mit Invalidierung passt zu oft gelesenen Daten mit seltenen Schreibvorgängen, aber eine verpasste Invalidierung zeigte hier einen falschen Kontostand, was mehr kostet als der zusätzliche Lesezugriff.

3. Du veröffentlichst eine API für externe Partner, die viele Sprachen nutzen. Antworten sollen mit CDNs funktionieren, und der erste Aufruf eines Partners soll Minuten dauern. Welcher Stil?
   ▸Antwort zeigen

   Richtige Antwort: REST über HTTP mit einer OpenAPI-Beschreibung

   REST braucht nur einen HTTP-Client, und GET-Antworten funktionieren von Haus aus mit CDNs. GraphQL passt zu Clients mit sehr unterschiedlichem Datenbedarf, Caching kostet aber meist mehr Arbeit, weil Abfragen oft per POST gehen. gRPC passt zu schnellen internen Aufrufen zwischen eigenen Diensten, braucht aber erzeugte Clients und funktioniert nicht direkt aus dem Browser.

4. Web- und Mobile-Apps brauchen von denselben Diensten sehr unterschiedliche Daten. Jeder Client hat sein eigenes Team, und Mobile leidet unter großen Nutzlasten. Was ergänzt du?
   ▸Antwort zeigen

   Richtige Antwort: Ein eigenes BFF, das jedem Client-Team gehört

   Ein BFF lässt jedes Team Antworten für seine Bildschirme formen und releasen, ohne auf andere zu warten. Ein Parameter ?fields= passt zu kleinen Unterschieden in einer Ressource, aggregiert aber nicht mehrere Dienste für einen Bildschirm. Direkte Aufrufe passen zu einem sehr kleinen System, würden hier aber auf Mobile Roundtrips hinzufügen und den internen Aufbau der Dienste offenlegen.

Technische Entscheidungen · Senior

1. Ein sozialer Feed bedient vor allem Nutzer mit ein paar hundert Followern, dazu einige Konten mit 50 Mio. Lesen muss schnell sein. Wie baust du Timelines?
   ▸Antwort zeigen

   Richtige Antwort: Hybrid: Fan-out beim Schreiben, außer bei riesigen Konten

   Vorberechnete Timelines machen das Lesen für die meisten Konten schnell, und riesige Konten beim Lesen einzumischen vermeidet Millionen Schreibvorgänge pro Post. Reines Fan-out beim Schreiben passt zu einem Netzwerk ohne extreme Konten, aber ein Post eines Promis würde den Schreibpfad fluten. Reines Fan-out beim Lesen passt zu Systemen mit wenig Lesezugriffen und bleibt einfach, aber jeden Feed bei jedem Öffnen zusammenzusetzen wird in dieser Größe zu langsam.

2. Ein Shop liefert Produktseiten über ein globales CDN aus. Beschreibungen ändern sich selten, aber ein korrigierter Preis muss innerhalb von Sekunden erscheinen. Was ist die Caching-Strategie?
   ▸Antwort zeigen

   Richtige Antwort: Eine lange CDN-TTL plus Purges nach Tag bei Änderungen

   Eine lange TTL hält die Trefferquote hoch, und Purgen nach Tag bringt eine Preiskorrektur in Sekunden überallhin. Eine kurze TTL passt zu Inhalten ohne Änderungs-Events, an die man sich hängen kann, schickt aber viel mehr Traffic zum Ursprung. Auf das CDN zu verzichten passt zu vollständig personalisierten Seiten und würde hier Tempo für Besucher weltweit opfern.

3. Ein Startup mit sechs Leuten sucht noch den Product-Market-Fit, und die Domänengrenzen verschieben sich ständig. Mit welcher Architektur startest du?
   ▸Antwort zeigen

   Richtige Antwort: Ein modularer Monolith mit klaren internen Grenzen

   Ein modularer Monolith hält Refactoring billig, während sich Grenzen verschieben, und saubere Module können später Dienste werden. Microservices passen zu vielen Teams, die unabhängige Releases brauchen, aber sechs Leute verbrächten ihre Zeit mit Netzwerk- und Deployment-Fragen. Funktionen pro Endpunkt passen zu sprunghaften, isolierten Lasten, während eine sich ändernde Domäne verteilt über sie gemeinsame Logik schwer weiterentwickelbar macht.

4. Nach dem Speichern einer Bestellung muss der Dienst ein Event an einen Broker veröffentlichen. Events dürfen nicht verloren gehen, und der Broker kann an keiner Datenbanktransaktion teilnehmen. Was tust du?
   ▸Antwort zeigen

   Richtige Antwort: Eine transaktionale Outbox, veröffentlicht von einem Relay

   Das Event in derselben Transaktion wie die Bestellung zu schreiben heißt, beide existieren oder keines, und ein Relay stellt es später zu. Nach dem Commit zu veröffentlichen passt zu Events, deren Verlust verkraftbar ist, aber ein Absturz zwischen den Schritten verliert das Event. Erst zu veröffentlichen passt zu nichts, was konsistent bleiben muss, denn ein gescheiterter Commit lässt Verbraucher auf eine Bestellung reagieren, die es nicht gibt.