Mock Interview: Kompletter Durchlauf

Lernziele

Nach dieser Lektion hast du einen kompletten 45-Minuten-Mock-Durchlauf für ein Platform-System-Design-Interview absolviert — mit Zeitplan, Beispieldialog, Bewertungsraster und typischen Fehlern. Du weißt, wie du Anforderungen klärst, Architektur schichtweise aufbaust und unter Zeitdruck Prioritäten setzt, ohne in Tool-Details zu versinken.

Das Szenario: 45 Minuten, ein Whiteboard, eine Aufgabe

Du betrittst das Interview. Der Interviewer sagt:

„Wir sind ein reguliertes Fintech mit 30 Entwicklern, wachsen auf 80 in zwei Jahren. Heute deployen Teams manuell auf VMs, CI ist Jenkins pro Team, kein zentrales Monitoring. Ihr habt sechs Monate für eine interne Kubernetes-Plattform auf AWS mit GitOps. Designe die Lösung.”

Kein Helm-Deep-Dive. Kein „Erkläre etcd”. System Design — Anforderungen, Architektur, Trade-offs, Phasen. Diese Lektion ist der komplette Durchlauf.

Zeitplan — halte dich daran

Phase	Minuten	Was du tust
Klären	0–8	Rückfragen, Annahmen aufschreiben, NFRs
High-Level	8–18	Boxen-Diagramm: Teams → Portal → Cluster → GitOps → Observability
Deep Dive	18–35	Interviewer wählt Schicht — du gehst in die Tiefe
Trade-offs	35–42	Was du bewusst NICHT baust, Risiken, Phasen
Fragen	42–45	Du fragst den Interviewer

Wenn du nach 8 Minuten noch nicht skizzierst, bist du zu langsam. Wenn du nach 15 Minuten noch klärst, hast du zu viele Rückfragen gestellt.

Phase 1: Klären (Beispieldialog)

Du: „Bevor ich skizziere — darf ich Annahmen festhalten? Reguliert heißt für mich: Audit-Trail, Encryption, keine Public Endpoints. Stimmt das ungefähr?”

Interviewer: „Ja, PCI-Nähe, aber kein Full PCI Scope für die Plattform selbst.”

Du: „Wie viele Teams deployen heute parallel — und gibt es Shared Services, die alle brauchen?”

Interviewer: „5 Teams produktiv, 25 in dev. PostgreSQL und Kafka als Shared Services.”

Du: „Sechs Monate — was muss in Monat 3 stehen? Erstes Team in prod, oder nur dev-ready?”

Interviewer: „Monat 3: zwei Pilot-Teams in staging auf K8s. Monat 6: prod für alle fünf.”

Du: „Identität — Okta vorhanden?”

Interviewer: „Ja, SAML/OIDC.”

Notiere auf dem Whiteboard:

• 30 → 80 Devs, 5 prod Teams heute
• AWS, 6 Monate, staging M3, prod M6
• Reguliert: Audit, Encryption, Private Networking
• Shared: Postgres, Kafka
• SSO: Okta

Phase 2: High-Level-Architektur

Skizziere (sprechen while drawing):

[Devs] → [Backstage Portal] → [GitHub + Actions CI]
                ↓
         [Argo CD] → [EKS: staging / prod]
                ↓
    [Prometheus/Grafana] [Vault/ESO] [Shared PG/Kafka]

Du: „Entwickler interagieren primär mit einem Portal — Backstage oder schlankes Equivalent. Golden Path: Template erzeugt Repo, CI-Pipeline, Argo CD Application. GitOps als einziger Deploy-Weg — kein kubectl prod. Cluster auf EKS, Namespace pro Team, NetworkPolicy Default-Deny. Observability und Secrets als Plattform-Services, nicht pro Team neu erfunden.”

Pause. Lass den Interviewer wählen, wohin er will.

Phase 3: Deep Dive — typische Interviewer-Wahl

Interviewer: „Wie onboardest du ein neues Team?”

Du: „Template im Portal: Team-Name, Cost-Center. Pipeline parallel: Okta-Gruppe, Namespace mit Quota und NetworkPolicy, Git-Repo mit CI, Argo App für staging. Secrets via External Secrets aus Vault. Ziel: Time-to-First-Deploy staging unter einer Stunde — nicht 15 Tage Tickets.”

Interviewer: „Was ist mit den Shared Services Postgres und Kafka?”

Du: „Plattform betreibt managed Instanzen — RDS für Postgres, MSK oder self-hosted Kafka im Shared-Services-Namespace. Teams bekommen Credentials via Vault, Connection über PrivateLink — kein Public Endpoint. Alternative wäre DB-as-a-Service pro Team — teurer, einfacher zu isolieren. Bei Fintech-Regulierung würde ich Shared mit strikter ACL und Audit starten, pro Team DB erst bei Bedarf.”

Interviewer: „GitOps — Argo oder Flux?”

Du: „Beides geht. Argo CD wenn UI und ApplicationSet für Multi-Team-Onboarding wichtig — passt hier. Flux wenn wir Git-native ohne UI bevorzugen. Ich würde Argo nehmen wegen Pilot-Team-Sichtbarkeit und ApplicationSet-Templates — Trade-off: mehr Ressourcenverbrauch im Cluster.”

Phase 4: Trade-offs und Phasen

Du: „Was ich bewusst nicht in Monat 1 baue: Multi-Region, Service Mesh, Chargeback-FinOps. Risiken: EKS-Lernkurve für Teams — deshalb Golden Path und Schulung. Rollout: M1 Landing Zone + SSO + ein Cluster staging. M2 zwei Pilot-Teams. M3 staging stabil. M4–5 prod Migration VM → K8s. M6 alle fünf Teams, Guardrails enforce.”

Interviewer: „Was wenn ein Team kubectl prod will?”

Du: „Escape Hatch dokumentiert — Architecture Review, zeitlich begrenzt, Audit-Log. Default bleibt GitOps. Platform ist Enabler, nicht Gefängnis — aber prod ohne Pipeline ist in reguliertem Umfeld nicht vertretbar.”

Bewertungsraster — so denkt der Interviewer

Kriterium	Stark	Schwach
Anforderungen	Rückfragen zu NFR, Timeline, Compliance	Sofort Architektur ohne Klärung
Struktur	Schichten, klare Boxen, Datenfluss	Tool-Liste ohne Zusammenhang
Tiefe	Ein Bereich überzeugend vertieft	Alles oberflächlich
Trade-offs	Sagt was er weglässt und warum	Nur Upsides
Praxis	Golden Path, GitOps, messbare Milestones	Theorie ohne Rollout
Kommunikation	Denkt laut, checkt Annahmen	Monolog oder Stille

Du musst nicht alles perfekt — strukturiert und ehrlich schlägt auswendig gelerntes Buzzword-Bingo.

Praxis

Simuliere allein oder mit Partner — 45 Minuten, Timer.

Aufgabe (Variation): „SaaS-Startup, 50 Devs, drei Cluster (dev/staging/prod), Multi-Tenant — designe Observability-as-a-Service.”

Pflichtpunkte in deiner Antwort:

1. Mindestens 5 Rückfragen in den ersten 8 Minuten
2. High-Level-Diagramm mit ≤7 Boxen
3. Ein Deep-Dive-Bereich (Observability: Metrics/Logs/Traces, Retention, Kosten)
4. Explizit zwei Trade-offs und zwei Dinge, die du weglässt
5. Phasenplan mit Monats-Meilensteinen

Nach dem Durchlauf: 5 Minuten Retro — wo bist du über Zeit? Wo hast du zu tief gebohrt?

Typische Stolperfallen im Mock

Zu früh in Tools. „Wir nehmen Istio, Karpenter, Crossplane…” — ohne Problem und Anforderung.

Keine Zahlen. „Viele Teams”, „skalierbar” — nenne 30 Devs, 5 prod Teams, 6 Monate.

Klärung vergessen. Architektur steht, Interviewer sagt „Aber wir sind On-Prem” — Reset.

Kein Deep Dive anbieten. Whiteboard voll, Interviewer gelangweilt — „Wohin soll ich tiefer gehen?”

Keine eigenen Fragen am Ende. Zeigt mangelndes Interesse — frag nach Team-Größe, größter Schmerz, Erfolgsmetrik.

Interview-Vorbereitung

Kernbotschaft für jeden Platform-Design-Case: „Erst Anforderungen und Timeline — dann Schichten-Architektur mit Golden Path und GitOps — ein Deep Dive — Trade-offs und Phasen — Fragen.”

Follow-ups, die du in Mocks trainieren solltest:

• „Skaliere auf 200 Teams.” — Namespace/Account-Tiers, Multi-Cluster, zentrales GitOps mit AppProjects.
• „Compliance-Audit in 4 Wochen.” — Audit-Logs, Policy-as-Code im Audit-Modus, Encryption-Nachweis — priorisieren.
• „Budget halbiert.” — Managed Services, weniger Cluster, Shared statt Dedicated — was fällt weg?

Zusammenfassung

Du hast den System-Design-Pfad durchgespielt: Framework, Checkliste, Kommunikation, neun Cases von Multi-Tenant über GitOps bis Onboarding — und jetzt einen kompletten 45-Minuten-Mock. Wiederhole die Cases mit Timer, variiere die Aufgabenstellung, und nutze das Bewertungsraster ehrlich gegen dich selbst. Der Lernpfad System Design Cases ist damit abgeschlossen — als Nächstes lohnt sich der Pfad Platform Engineer für die konzeptionelle Tiefe oder konkrete Tool-Pfade wie Argo CD und Terraform, je nachdem, wo deine Lücken liegen.