System Design Interview in Deutschland: Was Unternehmen wirklich fragen

Ein System Design Interview ist ein 45- bis 60-minütiges Gespräch, in dem du die Architektur eines verteilten Systems entwirfst, während der Interviewer deine Denkweise, Kommunikation und technische Tiefe bewertet. Es geht nicht um die perfekte Lösung, sondern darum, wie du ein offenes Problem strukturierst, welche Trade-offs du erkennst und wie du deine Entscheidungen begründest.

Dieser Guide erklärt, wie System Design Interviews in der deutschen Tech-Branche ablaufen, welche Aufgaben typisch sind, welche Bewertungskriterien Interviewer verwenden und wie du dich systematisch vorbereitest.

Was ist ein System Design Interview?🔗

Architektur statt Code🔗

Im System Design Interview schreibst du keinen Code. Stattdessen entwirfst du die Architektur eines Systems auf einer Whiteboard-Oberfläche oder in einem gemeinsamen Dokument. Du zeichnest Komponenten, definierst Schnittstellen, diskutierst Datenmodelle und erklärst, wie das System unter Last skaliert.

Die Aufgabenstellung ist bewusst offen: „Entwirf ein System, das Kurz-URLs generiert und auflöst” oder „Entwirf eine Chat-Anwendung für 10 Millionen Nutzer”. Es gibt keine einzige richtige Antwort. Was zählt, ist dein Vorgehen, deine Fähigkeit, die richtigen Fragen zu stellen, und dein Verständnis für die Zusammenhänge zwischen den Komponenten.

Warum Unternehmen System Design testen🔗

System Design Interviews simulieren die tägliche Arbeit von Senior-Developern. In der Praxis verbringst du einen großen Teil deiner Zeit damit, Architekturentscheidungen zu treffen, bestehende Systeme zu erweitern und Trade-offs zwischen verschiedenen Ansätzen abzuwägen. Kein LeetCode-Problem testet diese Fähigkeit. Deshalb ist System Design bei den meisten Unternehmen ab Mid-Level-Positionen ein fester Bestandteil des Interviewprozesses.

In Deutschland kommt eine zusätzliche Dimension hinzu: Datenschutz und DSGVO-Konformität sind reale Anforderungen, die in jede Architekturentscheidung einfließen. Interviewer bei deutschen Unternehmen achten darauf, ob du diese Aspekte von dir aus ansprichst, besonders bei Systemen, die Nutzerdaten verarbeiten.

Wann kommt System Design im Prozess?🔗

Bei den meisten deutschen Tech-Unternehmen findet das System Design Interview nach dem HR-Screening und dem Coding-Interview statt. In einem typischen vierstufigen Prozess sieht die Reihenfolge so aus:

1. HR-Screening (30-45 Minuten): Motivation, Gehaltsvorstellungen, Cultural Fit
2. Technisches Coding-Interview (60-90 Minuten): Algorithmen, Datenstrukturen, Live Coding
3. System Design Interview (45-60 Minuten): Architektur und technische Tiefe
4. Culture Fit / Team Interview (30-60 Minuten): Zusammenarbeit, Werte, Fragen

Bei einigen Unternehmen, besonders bei Senior- und Staff-Positionen, gibt es zwei System-Design-Runden: eine mit einem breiteren Architekturproblem und eine mit einem tieferen Fokus auf einen spezifischen Bereich wie Datenbanken, Messaging oder Infrastruktur.

Startups in Berlin oder München kombinieren manchmal Coding und System Design in einer einzigen längeren Session. Bei größeren Unternehmen wie SAP, Zalando oder Delivery Hero sind die Runden klar getrennt und folgen einem standardisierten Bewertungsbogen.

Der typische Ablauf🔗

Ein System Design Interview folgt einem vorhersehbaren Muster. Wenn du dieses Muster kennst, kannst du deine Zeit effektiv einteilen und vermeidest die häufigsten Fehler.

Schritt 1: Anforderungen klären (5-10 Minuten)🔗

Der Interviewer gibt dir eine offene Aufgabe. Dein erster Schritt ist nicht, sofort zu zeichnen, sondern Fragen zu stellen. Kläre die funktionalen Anforderungen: Was soll das System tun? Welche Use Cases sind am wichtigsten? Kläre dann die nicht-funktionalen Anforderungen: Wie viele Nutzer? Welche Latenzanforderungen? Welche Verfügbarkeit?

Gute Klärungsfragen für ein URL-Shortener-System wären: „Wie viele URLs werden pro Tag erstellt? Wie hoch ist das Lese-zu-Schreib-Verhältnis? Brauchen wir Analytics für die Kurz-URLs? Sollen URLs ablaufen können?”

Dieser Schritt ist entscheidend. Interviewer bewerten, ob du das Problem verstehst, bevor du es löst. Kandidaten, die sofort mit dem Design beginnen, lösen oft das falsche Problem.

Schritt 2: High-Level Design (10-15 Minuten)🔗

Zeichne die Hauptkomponenten des Systems und wie sie miteinander kommunizieren. Beginne mit dem einfachsten Design, das die Anforderungen erfüllt. Für einen URL-Shortener wäre das: ein Client, ein API-Gateway, ein Application Server und eine Datenbank.

Beschreibe die APIs: Welche Endpoints gibt es? Welche Daten fließen wohin? Skizziere das Datenmodell: Welche Tabellen oder Collections brauchst du? Welche Felder haben sie?

Halte diesen Schritt bewusst einfach. Du baust das Fundament, auf dem du im nächsten Schritt aufbaust. Wenn du hier schon über Caching, Sharding und Message Queues sprichst, überspringst du wichtige Grundlagen.

Schritt 3: Deep Dive (15-20 Minuten)🔗

Jetzt wird es interessant. Der Interviewer wird dich bitten, bestimmte Aspekte zu vertiefen, oder du schlägst selbst vor, wo du tiefer einsteigen möchtest. Hier zeigst du technische Tiefe.

Typische Deep-Dive-Themen: Wie generierst du eindeutige Kurz-IDs? (Hashing vs. Counter vs. UUID) Wie skalierst du die Datenbank? (Replikation, Sharding, Partitionierungsstrategien) Wie gehst du mit Hot Keys um? Wie implementierst du Caching? Welche Konsistenzgarantien brauchst du?

In diesem Schritt ist es wichtig, dass du nicht nur eine Lösung nennst, sondern erklärst, warum du sie wählst und welche Alternativen du bewusst verwirfst.

Schritt 4: Trade-offs diskutieren (5-10 Minuten)🔗

Jede Architekturentscheidung hat Konsequenzen. Der Interviewer will sehen, dass du diese Konsequenzen verstehst. Wenn du eine relationale Datenbank wählst, was sind die Implikationen für horizontale Skalierung? Wenn du eventual consistency akzeptierst, in welchen Szenarien könnte das problematisch sein?

Die besten Kandidaten bringen Trade-offs proaktiv ein: „Ich habe mich für Redis als Cache entschieden, weil wir niedrige Latenz bei Lesezugriffen brauchen. Der Trade-off ist, dass wir eine Cache-Invalidierungsstrategie brauchen und bei einem Cache-Ausfall die Datenbank kurzzeitig höher belastet wird.”

Schritt 5: Fragen und Abschluss (5 Minuten)🔗

Am Ende hast du die Gelegenheit, Fragen zu stellen. Nutze sie, um mehr über die tatsächliche Architektur des Unternehmens zu erfahren: „Wie löst ihr bei euch das Problem der Datenkonsistenz zwischen Microservices?” oder „Welche Messaging-Infrastruktur nutzt ihr?” Diese Fragen zeigen echtes Interesse und geben dir wertvolle Einblicke für deine Entscheidung.

Bewertungskriterien🔗

Interviewer bei deutschen Tech-Unternehmen nutzen typischerweise vier Hauptkategorien, um deine Leistung zu bewerten. Das Verständnis dieser Kriterien hilft dir, deine Zeit und Energie richtig zu verteilen.

Requirements Gathering🔗

Hast du die richtigen Fragen gestellt? Hast du funktionale und nicht-funktionale Anforderungen unterschieden? Hast du Annahmen klar benannt, statt sie stillschweigend zu treffen? Kandidaten, die diesen Schritt überspringen, verlieren Punkte, selbst wenn ihr finales Design solide ist.

Kommunikation🔗

System Design ist ein Dialog, kein Monolog. Hast du deine Gedanken klar strukturiert? Hast du den Interviewer einbezogen? Hast du erklärt, warum du bestimmte Entscheidungen triffst? Hast du auf Hinweise und Rückfragen reagiert?

Besonders in Deutschland wird Klarheit geschätzt. Interviewer wollen verstehen, wie du denkst, nicht nur, was du weißt. Strukturierte Kommunikation, die komplexe Zusammenhänge verständlich macht, ist eine der wichtigsten Fähigkeiten, die getestet werden.

Skalierbarkeitsdenken🔗

Kannst du ein System von einem einzelnen Server zu einer verteilten Architektur weiterentwickeln? Verstehst du, wann und warum du Caching, Load Balancing, Sharding oder Message Queues einführst? Kannst du Engpässe identifizieren und adressieren?

Wichtig: In Deutschland ist Over-Engineering genauso negativ wie Under-Engineering. Ein URL-Shortener für ein Startup braucht kein Global-Scale-Design mit 50 Microservices. Zeige, dass du die richtige Lösung für den richtigen Kontext findest.

Trade-off-Diskussion🔗

Jede Entscheidung hat Vor- und Nachteile. Konsistenz vs. Verfügbarkeit, Latenz vs. Durchsatz, Komplexität vs. Wartbarkeit. Die Fähigkeit, diese Trade-offs zu erkennen, zu benennen und bewusst eine Entscheidung zu treffen, unterscheidet gute von großartigen Kandidaten.

Häufige Aufgaben in Deutschland🔗

Die System-Design-Aufgaben bei deutschen Unternehmen unterscheiden sich von den typischen FAANG-Problemen. Der Fokus liegt stärker auf praxisnahen Szenarien und weniger auf Hyperscale-Problemen für Milliarden von Nutzern.

URL Shortener🔗

Der Klassiker, auch in Deutschland häufig. Du entwirfst ein System wie bit.ly: URLs kürzen, URLs auflösen, optional mit Analytics. Diese Aufgabe ist beliebt, weil sie einfach genug ist, um in 45 Minuten behandelt zu werden, aber genug Tiefe bietet für Diskussionen über Hashing, Datenbanken, Caching und Skalierung.

Chat-System🔗

Entwirf ein Echtzeit-Messaging-System. In Deutschland kommt oft der Zusatz, dass das System DSGVO-konform sein muss: Nachrichten müssen löschbar sein, Daten dürfen nur in der EU gespeichert werden, und End-to-End-Verschlüsselung ist ein Thema. Diese Anforderungen machen die Aufgabe interessanter als die Standardversion.

Notification System🔗

Entwirf ein System, das Push-Benachrichtigungen, E-Mails und SMS an Millionen von Nutzern senden kann. Bei deutschen Unternehmen kommt oft die Anforderung, dass Nutzer granulare Kontrolle über ihre Benachrichtigungseinstellungen haben müssen (Opt-in statt Opt-out, wie es die DSGVO vorschreibt).

Payment System🔗

Besonders relevant für den deutschen Markt, wo Zahlungssysteme wie SEPA, Sofortüberweisung und PayPal dominieren und Kreditkarten weniger verbreitet sind als in den USA. Du entwirfst ein System, das verschiedene Zahlungsmethoden unterstützt, Transaktionskonsistenz garantiert und regulatorische Anforderungen (PSD2, Strong Customer Authentication) erfüllt.

Bei Fintech-Unternehmen wie N26, Trade Republic oder Scalable Capital sind Payment-Design-Aufgaben besonders häufig und werden mit hohem Detailgrad erwartet.

Vorbereitung: Der strukturierte Ansatz🔗

Das Framework🔗

Verwende ein konsistentes Framework für jedes System-Design-Problem. Das reduziert kognitive Belastung und stellt sicher, dass du keinen wichtigen Aspekt vergisst.

1. Anforderungen klären: Funktionale und nicht-funktionale Anforderungen, Skalierungsparameter
2. API-Design: Endpoints, Request/Response-Formate
3. Datenmodell: Schema, Beziehungen, Zugriffspatterns
4. High-Level Design: Hauptkomponenten und ihre Interaktion
5. Deep Dive: Skalierung, Zuverlässigkeit, Konsistenz
6. Trade-offs: Bewusste Entscheidungen mit Begründung

Ressourcen🔗

Die effektivsten Ressourcen für System Design Vorbereitung sind:

• „Designing Data-Intensive Applications” von Martin Kleppmann: Das Standardwerk, geschrieben von einem Developer, der in Berlin gearbeitet hat. Es behandelt verteilte Systeme mit Tiefe und Praxisbezug.
• System Design Interview von Alex Xu: Strukturierte Durcharbeitung der häufigsten Aufgaben mit klaren Diagrammen.
• ByteByteGo (YouTube und Newsletter): Visuelle Erklärungen von System-Design-Konzepten, ideal als Ergänzung.
• Eigene Systeme analysieren: Die beste Vorbereitung ist, die Architektur deines aktuellen Systems zu verstehen und erklären zu können. Warum wurde eine bestimmte Datenbank gewählt? Wie funktioniert das Deployment? Wo sind die Engpässe?

Übungsmuster🔗

Übe mindestens zehn verschiedene Aufgaben, bevor du in ein echtes Interview gehst. Für jede Aufgabe:

1. Setze einen Timer auf 45 Minuten
2. Sprich laut, als ob ein Interviewer zuhört
3. Zeichne auf Papier oder in einem Whiteboard-Tool
4. Überprüfe danach, welche Aspekte du vergessen hast
5. Wiederhole die Aufgabe eine Woche später und vergleiche

Alleine zu üben ist gut. Mit einer anderen Person zu üben ist besser. CodingCareers Mock System Design Interviews simulieren das echte Format mit einem erfahrenen Developer als Interviewer, der dir direktes Feedback zu deiner Struktur, Kommunikation und technischen Tiefe gibt.

Häufige Fehler🔗

Sofort mit der Lösung beginnen🔗

Der häufigste und schwerwiegendste Fehler. Kandidaten hören die Aufgabe und fangen sofort an, Boxen und Pfeile zu zeichnen. Ohne die Anforderungen zu klären, entwirfst du ein System, das möglicherweise das falsche Problem löst. Nimm dir fünf Minuten für Fragen. Der Interviewer erwartet das.

Anforderungen ignorieren🔗

Wenn der Interviewer sagt „Das System muss 99.9% Verfügbarkeit haben”, dann ist das eine Kernanforderung, die dein Design beeinflussen muss. Kandidaten, die Anforderungen zur Kenntnis nehmen, aber in ihrem Design nicht darauf eingehen, zeigen dem Interviewer, dass sie in der Praxis genauso arbeiten würden.

Over-Engineering🔗

Ein System für 10.000 Nutzer braucht kein Kubernetes-Cluster mit 50 Microservices, globalem CDN und dreifacher Datenbank-Replikation. Zeige, dass du die richtige Lösung für den richtigen Kontext findest. Beginne einfach und skaliere nur dort, wo die Anforderungen es verlangen.

Dieser Fehler ist bei Kandidaten, die sich ausschließlich mit FAANG-Style-Problemen vorbereitet haben, besonders häufig. Deutsche Mittelständler und Startups suchen pragmatische Developer, nicht Architekten für Milliardennutzer-Systeme.

Trade-offs nicht diskutieren🔗

Jede Entscheidung, die du triffst, hat eine Kehrseite. Wenn du nur Vorteile nennst, wirkt es, als hättest du die Konsequenzen nicht durchdacht. „Ich wähle MongoDB” ohne zu erklären, warum nicht PostgreSQL, zeigt dem Interviewer, dass du die Entscheidung nicht bewusst triffst.

System Design für verschiedene Level🔗

Mid-Level (3-5 Jahre)🔗

Von Mid-Level-Kandidaten wird erwartet, dass sie ein funktionierendes System entwerfen können, die Grundlagen verteilter Systeme kennen (Caching, Load Balancing, Replikation) und über ihre Entscheidungen sprechen können. Die Aufgaben sind typischerweise weniger komplex, und der Interviewer gibt mehr Hinweise.

Du musst nicht jedes Detail kennen. Aber du musst zeigen, dass du systematisch denkst und die richtigen Fragen stellst. „Ich bin mir nicht sicher, wie genau Consistent Hashing funktioniert, aber ich weiß, dass wir eine Strategie brauchen, um Daten gleichmäßig auf mehrere Shards zu verteilen” ist eine akzeptable Antwort auf Mid-Level.

Senior (5-10 Jahre)🔗

Senior-Kandidaten müssen eigenständig ein vollständiges System entwerfen können, ohne viele Hinweise vom Interviewer. Du solltest verschiedene Datenbank-Technologien vergleichen können, Konsistenzmodelle verstehen (strong vs. eventual consistency), Ausfallszenarien durchdenken und konkrete Zahlen nennen können (Latenz, Durchsatz, Speicherverbrauch).

Von Senior-Developern in Deutschland wird zusätzlich erwartet, dass sie DSGVO-Implikationen berücksichtigen, Multi-Region-Deployments in der EU diskutieren können und ein Gespür dafür haben, wann eine einfachere Lösung die bessere ist.

Staff (10+ Jahre)🔗

Auf Staff-Level wird System Design zum strategischen Gespräch. Du diskutierst nicht nur, wie ein System gebaut wird, sondern warum bestimmte Architekturentscheidungen langfristig die richtigen sind. Themen wie organisatorische Auswirkungen (Conway’s Law), Build vs. Buy, Migration von Legacy-Systemen und evolutionäre Architektur stehen im Vordergrund.

Staff-Interviews dauern oft länger und können mehrere Runden umfassen. Der Interviewer erwartet, dass du das Gespräch führst, nicht nur auf Fragen reagierst.

Nächster Schritt🔗

System Design Interviews sind eine erlernbare Fähigkeit. Die Kombination aus theoretischem Wissen und strukturierter Übung bringt dich weiter als jede Menge passives Lernen. Beginne mit dem Framework aus diesem Guide, arbeite dich durch die Standardaufgaben und übe laut, mit Timer und Whiteboard.

Wenn du gezieltes Feedback zu deinem System-Design-Ansatz willst, bietet CodingCareer Mock System Design Interviews mit erfahrenen Developern an, die den Prozess aus eigener Erfahrung kennen. Du bekommst eine realistische Simulation und konkretes Feedback, das du sofort umsetzen kannst.

Buche dein kostenloses 15-Minuten-Diagnosegespräch und finde heraus, wo du in deiner System-Design-Vorbereitung stehst.