Platform Engineering Interview: So bereitest du dich strukturiert vor

Platform-Interviews fühlen sich oft an wie normale Kubernetes-Runden — bis die zweite Frage kommt. Dann geht es plötzlich um Multi-Tenancy, Developer Experience und warum euer GitOps so aufgebaut ist, wie es ist. Wer nur Befehle und Tool-Namen parat hat, merkt schnell, dass das nicht reicht.

Gefragt ist meistens: Verstehst du das Problem? Kannst du Trade-offs benennen? Würde ich dich auf ein Platform-Team loslassen?

Was wirklich zählt

Drei Ebenen mischen sich in fast jeder Runde:

Mindset — Platform as Product, weniger Cognitive Load für Entwickler, Team Topologies. Nicht „wir installieren Tools”, sondern „wir verkürzen den Weg von Idee zu Production”. Eine gute Testfrage an dich selbst: Kannst du erklären, was ein Platform Engineer eigentlich macht, ohne ein einziges Tool zu nennen?

System Design — IDP skizzieren, Fleet-GitOps, Observability als Shared Service. Hier zeigt sich, ob du strukturiert denkst oder in Pod-Specs versinkst.

Betrieb — Was passiert bei Ausfall? Wie isolierst du Teams? Wer zahlt den Cluster? SLOs, Security, Kosten — kurz ansprechen, nicht ignorieren.

Der häufigste Unterschied zwischen einer mittelmäßigen und einer starken Antwort ist nicht Wissen, sondern Begründung. „Wir nutzen ArgoCD” ist eine Tool-Nennung. „Wir haben ArgoCD gewählt, weil die Teams eine UI für Sync-Status wollten und wir App-of-Apps für die Fleet-Struktur brauchten — Flux wäre schlanker gewesen, aber die Self-Service-Sichtbarkeit war uns wichtiger” ist eine Architektur-Entscheidung. Interviewende hören den Unterschied sofort.

STAR-Stories, die passen

STAR (Situation, Task, Action, Result) funktioniert, wenn die Story zur Rolle passt. Gut: Time-to-Production von zwei Wochen auf zwei Tage, weil Self-Service-Templates und GitOps zusammenpassen. Incident-Rate runter durch Policy-as-Code und zentrale Observability. Cloud-Kosten pro Team sichtbar gemacht, Teams haben selbst rightsized — 30 % weniger Spend ohne zentrale Vorgabe.

Schlecht: „Ich habe Kubernetes installiert” ohne Nutzer und ohne Outcome. Oder eine reine Tool-Migration, bei der am Ende niemand das neue System adoptiert hat.

Schreib drei bis fünf Stories vorher auf. Jede braucht eine Zahl und einen Trade-off, den du bewusst eingegangen bist — und mindestens eine sollte ein Scheitern enthalten. „Wir haben Backstage eingeführt und die Adoption blieb bei 20 %, weil wir die Templates vor den Catalog gestellt haben — beim zweiten Anlauf haben wir mit dem größten Pain Point angefangen” ist glaubwürdiger als drei makellose Erfolgsgeschichten.

System Design in 45 Minuten

So würde ich die Zeit aufteilen: rund fünf Minuten Rückfragen — wie viele Teams, welche Compliance, welche SLAs, Brownfield oder Greenfield? Annahmen laut aussprechen. Zehn Minuten High-Level: Control Plane, Tenant-Isolation, Golden Path skizzieren. Fünfzehn Minuten Deep Dive in einen Bereich — Secrets, GitOps oder Observability, je nachdem, wohin das Interview steuert. Zehn Minuten Trade-offs: Namespace vs. vCluster, Build vs. Buy, zentrale vs. dezentrale Pipelines. Zum Schluss Rollout: Pilot-Team, Docs, Adoption-Metriken — nicht Big Bang.

Denk laut. Wer nur schweigt und zeichnet, verliert Punkte bei denen, die den Prozess bewerten. Und wenn der Interviewer dich unterbricht und in eine Richtung schiebt: das ist kein Angriff, sondern ein Hinweis, wo die Punkte liegen. Folge ihm.

Typische Fallen: zu früh Tools nennen, kein Failure-Mode („was passiert, wenn eure zentrale Registry ausfällt?”), keine Adoption-Strategie, zu tief in ein Detail ohne Rückfrage, ob das gewollt ist. Wie der IDP-Case konkret aussieht, haben wir in System Design: Internal Developer Platform durchgespielt.

Neben System Design taucht zunehmend eine Troubleshooting-Runde auf: ein präpariertes Szenario („Deployments hängen in Pending”, „die Error-Rate steigt nach dem letzten Rollout”), und du sollst laut diagnostizieren. Hier zählt Methode mehr als der richtige Befehl: erst Symptom eingrenzen (welche Ebene — Scheduling, Netzwerk, App?), dann Hypothese, dann gezielter Check. Wer wild kubectl get all tippt, wirkt planlos; wer sagt „Pending heißt Scheduling — ich prüfe Events, Quotas und Node-Kapazität, in der Reihenfolge”, zeigt Betriebserfahrung, selbst wenn die Lösung am Ende woanders liegt.

Vier Wochen reichen — wenn du fokussierst

Woche 1: Rolle und Mindset (Platform Engineer, Soft Skills). Woche 2: zwei System-Design-Cases laut durchsprechen, Timer auf 45 Minuten — nicht lesen, sprechen. Woche 3: technische Lücken schließen — K8s, GitOps, Observability, Security, jeweils ein Tag, nur dort wo du wackelst. Woche 4: Schwachstellen wiederholen, Stories verdichten, drei gute Fragen an den Interviewer vorbereiten (echte Fragen, keine Pseudo-Fragen — „wie misst euer Platform-Team Erfolg?” verrät, dass du das Produkt-Mindset hast).

Nicht alles lesen — üben. Laut erklären, Whiteboard oder Papier, mit Peer oder allein. Die Erklärung, die im Kopf rund klingt, stolpert beim ersten lauten Versuch fast immer.

Am Tag selbst: lieber bekannte Stories sauber erzählen als in der Nacht davor neue Tools cramming.

Mehr Cases findest du unter System Design Cases.