Fragen für das Vorstellungsgespräch als Platform Engineer

Einstellungsverantwortliche in Unternehmen mit ausgereiften Plattform-Teams berichten, dass 60 % der Kandidaten technische Vorstellungsgespräche nicht wegen mangelndem Tool-spezifischem Wissen scheitern, sondern wegen fehlenden Denkens in Systemdesign und der Fähigkeit, Infrastrukturentscheidungen in geschäftlichen Begriffen zu erklären [1]. Vorstellungsgespräche im Platform Engineering unterscheiden sich in einem entscheidenden Punkt von allgemeinen DevOps-Gesprächen: Die Interviewer bewerten, ob Sie über Infrastruktur als internes Produkt nachdenken. Ein Kandidat, der erklären kann, wie er die Zufriedenheit der Entwickler mit seiner Kubernetes-Plattform gemessen hat, zeigt eine grundlegend andere Denkweise als jemand, der nur die Cluster-Konfiguration beschreibt.

Wichtigste Erkenntnisse

• Erwarten Sie ein dreistufiges Vorstellungsgespräch: Verhaltens-/Kulturfit, technische Vertiefung und Systemdesign
• Verhaltensfragen konzentrieren sich auf Plattform-als-Produkt-Denken: Entwicklerempathie, teamübergreifende Zusammenarbeit und Incident-Leadership
• Technische Fragen testen Kubernetes-Interna, IaC-Design und Observability-Architektur — nicht nur oberflächliche Tool-Nutzung
• Situative Szenarien bewerten, wie Sie konkurrierende Plattformanforderungen mehrerer Teams priorisieren
• Bereiten Sie 4–5 STAR-Geschichten vor, die Plattform-Impact, Incident Response und Verbesserungen der Developer Experience abdecken
• Halten Sie 3–5 Fragen bereit, die zeigen, dass Sie die Infrastrukturherausforderungen des Unternehmens recherchiert haben

Verhaltensfragen (STAR-Format)

1. Beschreiben Sie eine Situation, in der Sie ein Plattform-Feature entwickelt haben, das Entwickler zunächst ablehnten. Wie haben Sie die Akzeptanz vorangetrieben?

**Warum diese Frage gestellt wird:** Platform Engineers bauen interne Produkte. Akzeptanz ist die ultimative Kennzahl. Diese Frage prüft, ob Sie Change Management und Entwicklerempathie verstehen, nicht nur die technische Umsetzung.

**Starkes STAR-Antwortgerüst:**

• **Situation:** Entwickler erstellten wöchentlich über 50 Infrastruktur-Tickets für die Datenbankbereitstellung mit durchschnittlich 4 Stunden Wartezeit
• **Aufgabe:** Sie schlugen ein Self-Service-Datenbankbereitstellungssystem über das Plattformportal vor, aber die Engineering-Teams waren skeptisch bezüglich Sicherheit und Zuverlässigkeit
• **Aktion:** Sie führten Entwicklerinterviews durch, um Bedenken zu verstehen, erstellten einen Piloten mit einem willigen Team, demonstrierten, dass die bereitgestellten Datenbanken die gleichen Sicherheitsstandards erfüllten wie manuell erstellte, und veröffentlichten Akzeptanzkennzahlen nach dem Piloten
• **Ergebnis:** Die Akzeptanz wuchs in 3 Monaten von 1 Team auf 12 Teams. Infrastruktur-Tickets sanken um 67 %. Die Entwicklerzufriedenheit mit der Bereitstellung stieg von 3,2/10 auf 8,4/10

2. Erzählen Sie mir von dem komplexesten Produktionsvorfall, den Sie als Incident Commander geleitet haben. Was war die Ursache und welche Präventivmaßnahmen haben Sie implementiert?

**Warum diese Frage gestellt wird:** Platform Engineers verantworten die Produktionszuverlässigkeit. Dies testet Incident-Leadership, technische Diagnosetiefe und Durchhaltevermögen bei der Prävention.

**Starkes STAR-Antwortgerüst:**

• **Situation:** Multi-Cluster-Netzwerkausfall, der intermittierende Service-zu-Service-Kommunikationsfehler über 3 EKS-Cluster während Spitzenlastzeiten verursachte
• **Aufgabe:** Incident Commander verantwortlich für Diagnose, Behebung und Kommunikation an über 200 betroffene Entwickler
• **Aktion:** Korrelation von Istio-Proxy-Fehlerprotokollen mit Calico-NetworkPolicy-Änderungen, die 2 Stunden zuvor bereitgestellt wurden, Identifizierung einer Richtlinie, die Cross-Namespace-Traffic blockierte, Rollback der Richtlinienänderung und Implementierung eines Frameworks zum Testen von Netzwerkrichtlinien vor der Bereitstellung
• **Ergebnis:** MTTR von 23 Minuten (innerhalb des SLO). Post-Incident: Implementierung einer OPA-Richtlinie, die NetworkPolicy-Änderungen gegen eine Testmatrix validiert, bevor sie bereitgestellt werden — Reduzierung netzwerkrichtlinienbezogener Vorfälle von 4 pro Quartal auf 0 über 6 Monate

3. Beschreiben Sie eine Situation, in der zwei Produktteams widersprüchliche Anforderungen an die Plattform hatten. Wie haben Sie das gelöst?

**Warum diese Frage gestellt wird:** Platform Engineers bedienen gleichzeitig mehrere interne Kunden. Dies testet Priorisierung, Stakeholder-Management und Produktdenken.

**Starkes Antwortgerüst:** Ein Team benötigte GPU-Knotenpools für ML-Workloads; ein anderes benötigte das gleiche Budget für zusätzliche allgemeine Rechenkapazität. Sie analysierten Nutzungsmuster, schlugen einen gemeinsamen GPU-Knotenpool mit Preemptible Instances und warteschlangenbasierter Planung vor, der beide Bedürfnisse zu 60 % der kombinierten Kosten bediente, und etablierten ein Ressourcen-Governance-Framework für zukünftige Konflikte.

4. Erzählen Sie von einer Situation, in der Sie die Ingenieurleitung davon überzeugen mussten, in Plattforminfrastruktur statt in Feature-Entwicklung zu investieren.

**Warum diese Frage gestellt wird:** Plattformarbeit konkurriert mit Produktfeatures um Investitionen in das Engineering. Dies testet Ihre Fähigkeit, den Wert von Infrastruktur in geschäftlichen Begriffen zu kommunizieren.

**Starkes Antwortgerüst:** Quantifizieren Sie die Kosten des Nichtinvestierens: verlorene Entwicklerstunden durch manuelle Bereitstellung, Häufigkeit von Vorfällen durch Konfigurationsabweichungen, Einarbeitungszeit für neue Ingenieure. Präsentieren Sie die Plattforminvestition als Kraftmultiplikator: „Eine Plattforminvestition von 400.000 $ eliminiert jährlich 8.000 Entwicklerstunden an Infrastruktur-Routinearbeit, was 4 Vollzeitingenieuren entspricht."

5. Beschreiben Sie, wie Sie den Erfolg einer von Ihnen gebauten Plattform gemessen haben. Welche Kennzahlen haben Sie verfolgt?

**Warum diese Frage gestellt wird:** Produktdenken erfordert Messung. Diese Frage zeigt, ob Sie Plattformen als Produkte mit KPIs behandeln oder nur als Infrastruktur, die läuft.

**Starkes Antwortgerüst:** Verfolgen Sie DORA-Metriken (Bereitstellungshäufigkeit, Vorlaufzeit, Change Failure Rate, MTTR), Entwicklerzufriedenheitsumfragen (vierteljährlicher NPS oder CSAT), Self-Service-Akzeptanzraten, Zeit bis zur ersten Bereitstellung für neue Ingenieure, Plattformverfügbarkeits-SLOs und Infrastrukturkosten pro Bereitstellung.

6. Erzählen Sie von einer technischen Entscheidung, die Sie für die Plattform getroffen haben und die sich später als falsch herausstellte. Was haben Sie getan?

**Warum diese Frage gestellt wird:** Testet intellektuelle Ehrlichkeit, Lernbereitschaft und die Fähigkeit, auf Infrastrukturebene den Kurs zu korrigieren.

**Starkes Antwortgerüst:** Beispiel: Helm für das gesamte Konfigurationsmanagement gewählt, später erkannt, dass Kustomize besser für Umgebungs-Overlays geeignet war. Quantifizieren Sie die Auswirkungen des Fehlers, beschreiben Sie den Migrationsplan, erklären Sie, was Sie über Bewertungskriterien gelernt haben, und beschreiben Sie, wie Sie Ihren Entscheidungsprozess geändert haben (z. B. Implementierung von ADRs mit expliziten Bewertungskriterien).

Technische Fragen

1. Führen Sie mich durch den Ablauf, wenn ein Pod in Kubernetes geplant wird, vom Moment, in dem Sie ein Deployment-Manifest anwenden, bis der Container läuft.

**Was bewertet wird:** Tiefe des Wissens über Kubernetes-Interna. Oberflächliche Antwort: „kubectl sendet es an den API-Server und es läuft." Tiefe Antwort verfolgt: kubectl → API-Server (Authentifizierung, Autorisierung, Admission Controllers) → etcd-Persistenz → Scheduler (Filtern, Bewerten, Binden) → Kubelet auf dem ausgewählten Knoten → CRI-Aufruf an die Container-Runtime (containerd) → CNI-Plugin für Netzwerk → Readiness-Probe bestanden → Endpunkt-Registrierung. Erwähnen Sie Preemption, Auswirkungen von Resource Requests/Limits auf die Planung und Topology Spread Constraints für Bonuspunkte.

2. Sie müssen eine Terraform-Modulstrategie für eine Organisation mit 15 Produktteams entwerfen. Wie strukturieren Sie die Module, den State und die Berechtigungen?

**Was bewertet wird:** IaC-Architekturdenken, nicht nur Syntaxwissen. Behandeln Sie: Modulkomposition (Basismodule für Primitive, zusammengesetzte Module für Muster), State-Isolation (pro Team, pro Umgebung oder pro Service State-Dateien), Remote-Backend-Konfiguration (S3 + DynamoDB-Locking), RBAC über IAM und Terraform Cloud/Spacelift Workspaces, Modul-Versionierung und Release-Workflow sowie Drift-Erkennungsstrategie.

3. Erklären Sie, wie Sie Zero-Downtime-Kubernetes-Upgrades für einen Cluster mit über 500 Pods in 30 Namespaces implementieren würden.

**Was bewertet wird:** Betriebliche Reife. Behandeln Sie: PodDisruptionBudgets für alle kritischen Workloads, rollierende Knotenpool-Updates (Cordoning, Draining, Ersetzen), API-Server-Versionsabweichungsrichtlinie (Kubelet kann eine Minor-Version zurückliegen), Pre-Upgrade-Validierung (veraltete API-Prüfungen mit kubent oder pluto), Canary-Cluster-Strategie (zuerst Non-Prod upgraden, dann einen Produktionscluster vor flottenweit), Monitoring während des Upgrades (Pod-Neustartraten, Fehlerquoten, Scheduling-Latenz) und Rollback-Verfahren.

4. Wie würden Sie einen Observability-Stack für eine Plattform entwerfen, die 50 Microservices bedient? Führen Sie mich durch Metriken, Logs und Traces.

**Was bewertet wird:** Observability-Architektur. Behandeln Sie: Metrik-Schicht (Prometheus mit Federation oder Thanos für Langzeitspeicherung, Recording Rules für SLOs), Logs (Fluent Bit DaemonSet → Loki mit angemessenen Aufbewahrungsrichtlinien, Standards für strukturiertes Logging), Traces (OpenTelemetry SDK-Instrumentierung → Collector → Tempo/Jaeger), Korrelation (Exemplare, die Metriken mit Traces verknüpfen, Trace-IDs in Logs), Alerting (SLO-basierte Error-Budget-Alarme statt Schwellenwert-Alarme) und Self-Service (Grafana mit teamspezifischen Dashboards und Variablenvorlagen).

5. Ein Entwickler berichtet, dass seine Bereitstellung 45 Minuten dauert. Wie diagnostizieren und optimieren Sie das?

**Was bewertet wird:** Systematische Fehlersuche und Optimierung. Verfolgen Sie die Pipeline: Code-Checkout-Zeit, Abhängigkeitsinstallation (Caching-Strategien), Build-Zeit (mehrstufige Docker-Builds, Build-Caching, Schicht-Optimierung), Testausführung (parallele Test-Runner, Test-Splitting), Image-Push-Zeit (Registry-Nähe, Schicht-Deduplizierung), ArgoCD-Sync-Zeit (Sync Waves, Resource Hooks) und Pod-Scheduling-Zeit (Image-Pull, Init Containers, Readiness Probes). Identifizieren Sie den Engpass, bevor Sie optimieren — fragen Sie nach der aktuellen Aufschlüsselung.

6. Erklären Sie den Unterschied zwischen Kyverno und OPA/Gatekeeper. Wann würden Sie welches Tool wählen?

**Was bewertet wird:** Tiefe bei Security-Tooling. OPA/Gatekeeper verwendet die Rego-Richtliniensprache (leistungsstark, aber steile Lernkurve), läuft als Admission Webhook und eignet sich hervorragend für komplexe ressourcenübergreifende Richtlinien. Kyverno verwendet Kubernetes-native YAML-Richtlinien (niedrigere Einstiegshürde), unterstützt Validierungs-, Mutations- und Generierungsrichtlinien und integriert sich natürlicher in Kubernetes-Konzepte. Wählen Sie Gatekeeper für Organisationen mit vorhandener Rego-Expertise oder komplexen Richtlinienanforderungen. Wählen Sie Kyverno für Teams, die Kubernetes-natives Richtlinienmanagement mit geringerer Einführungshürde wünschen.

7. Wie funktioniert die ArgoCD-Reconciliation, und wie würden Sie sie für eine Multi-Cluster-Umgebung mit über 200 Anwendungen konfigurieren?

**Was bewertet wird:** GitOps-Tiefe. Behandeln Sie: ArgoCD pollt Git-Repos in konfigurierbaren Intervallen (Standard 3 Minuten), vergleicht den gewünschten Zustand (Git) mit dem Live-Zustand (Cluster) und gleicht Unterschiede ab. Für Skalierung: ApplicationSets mit Generatoren (Git, Cluster, Matrix), App-of-Apps-Muster für hierarchisches Management, RBAC auf Projektebene für mandantenfähige Zugriffskontrolle, Ressourcenausschluss für stark wechselnde Ressourcen und Sync-Fenster für Produktions-Änderungskontrolle. Besprechen Sie Webhook-basierte Sync-Trigger für schnellere Abgleiche bei Bedarf.

Situative Fragen

1. Ihr Plattform-Team von 5 Personen erhält gleichzeitig Anfragen von 8 Produktteams. Wie priorisieren Sie?

**Was bewertet wird:** Produktmanagement- und Stakeholder-Fähigkeiten. Rahmenwerk: Kategorisieren Sie nach Auswirkung (Anzahl betroffener Entwickler × Schwere des Problems), Dringlichkeit (blockiert Bereitstellungen vs. nice-to-have) und strategischer Ausrichtung (unterstützt unternehmensweite Initiativen vs. Einzelteam-Bedürfnisse). Etablieren Sie einen transparenten Aufnahmeprozess: wöchentliches Priorisierungsmeeting mit Teamleitern, veröffentlichte Plattform-Roadmap, klare SLAs für verschiedene Anfragetypen (P0-Blockaden: am selben Tag; Feature-Anfragen: Sprint-Planung).

2. Ein neuer CTO möchte die gesamte Infrastruktur innerhalb von 6 Monaten von AWS zu GCP migrieren. Wie bewerten und planen Sie das?

**Was bewertet wird:** Strategisches Denken unter Druck. Beginnen Sie mit der Auswirkungsbewertung: Inventarisierung aller genutzten AWS-Services, Identifizierung von GCP-Äquivalenten, Schätzung von Datentransferkosten und Zeitplan. Risikobewertung: Identifizierung von Services ohne sauberes GCP-Äquivalent (z. B. spezifische Managed Services). Schlagen Sie einen phasenweisen Ansatz vor: Zunächst Infrastruktur durch Terraform-Module abstrahieren (Reduzierung cloudspezifischer Kopplung), dann nicht-kritische Services als Proof of Concept migrieren, dann Produktionsservices mit Rollback-Fähigkeit. Widersprechen Sie dem 6-Monats-Zeitplan mit Belegen, wenn unrealistisch.

3. Ihr Kubernetes-Cluster erlebt intermittierende Pod-Evictions während der Geschäftszeiten. Führen Sie mich durch Ihre Untersuchung.

**Was bewertet wird:** Systematische Fehlersuche. Prüfen Sie Ressourcendruck auf Knotenebene (Speicher, Festplatte, PID-Limits) über kubectl describe node und suchen Sie nach Kubelet-Eviction-Events. Untersuchen Sie Resource Requests vs. tatsächliche Nutzung — Pods ohne Requests werden zuerst evicted. Prüfen Sie Noisy-Neighbor-Effekte (ein Pod, der übermäßig Ressourcen auf gemeinsamen Knoten verbraucht). Überprüfen Sie Karpenter/Cluster-Autoscaler-Logs auf Skalierungsverzögerungen. Prüfen Sie DaemonSet-Ressourcenkonflikte. Implementieren Sie Resource Quotas und LimitRanges, um zukünftige Überprovisionierung zu verhindern.

4. Sie entdecken, dass 40 % Ihrer Terraform-State-Dateien seit 6 Monaten nicht angewendet wurden und sich Drift angesammelt hat. Was ist Ihr Sanierungsplan?

**Was bewertet wird:** IaC-Betriebsdisziplin. Führen Sie nicht blind terraform apply aus — das zerstört Ressourcen, von denen Menschen abhängen könnten. Beginnen Sie mit terraform plan für jede State-Datei, kategorisieren Sie den Drift in: (1) beabsichtigte Änderungen außerhalb von Terraform (müssen importiert oder Code aktualisiert werden), (2) unbeabsichtigter Drift (muss angewendet werden), (3) aufgegebene Ressourcen (müssen bereinigt werden). Implementieren Sie kontinuierliche Drift-Erkennung (Spacelift, Atlantis oder geplante Plan-Ausführungen), um Wiederholungen zu verhindern. Etablieren Sie eine Governance-Richtlinie: Alle Infrastrukturänderungen müssen über Terraform-PRs erfolgen.

5. Ein Engineering-VP bittet Sie, seinem Team direkten Zugriff auf Produktions-Kubernetes-Cluster zur Fehlersuche zu geben. Wie gehen Sie damit um?

**Was bewertet wird:** Sicherheitsurteil und Stakeholder-Kommunikation. Direkter Clusterzugriff birgt Sicherheits- und Auditrisiken. Schlagen Sie Alternativen vor: schreibgeschützter kubectl-Zugriff, auf ihren Namespace beschränkt via RBAC, Grafana-Dashboards mit Observability auf Pod-Ebene, ein Debug-Container-Workflow (Ephemeral Containers), der Shell-Zugriff ohne Modifikation laufender Pods bietet, und Log-Aggregation, die Einblick ohne Cluster-Anmeldedaten gewährt. Falls sie bestehen, implementieren Sie zeitbegrenzten Zugriff mit Audit-Logging (Teleport, Boundary) und automatischem Entzug.

Bewertungskriterien, die Interviewer verwenden

**Technische Tiefe (40 %):** Können Sie erklären, wie Systeme auf Komponentenebene funktionieren, nicht nur sie konfigurieren? Die Fragen zur Pod-Planung und Terraform-Architektur testen dies.

**Systemdesign (25 %):** Können Sie Plattformkomponenten entwerfen, die mehrere Teams im großen Maßstab bedienen? Die Fragen zum Observability-Stack und Multi-Cluster-ArgoCD testen dies.

**Produkt und Kommunikation (20 %):** Können Sie Infrastrukturentscheidungen in geschäftlichen Begriffen erklären? Können Sie konkurrierende Anforderungen priorisieren? Die Verhaltensfragen und das Priorisierungsszenario testen dies.

**Incident und Betrieb (15 %):** Können Sie Produktionsprobleme systematisch diagnostizieren und Wiederholungen verhindern? Die Frage zum Incident Commander und das Pod-Eviction-Szenario testen dies.

STAR-Methode-Beispiele für Platform Engineering

**Vorlage:**

• **Situation:** Setzen Sie den Kontext mit konkreten Zahlen (Unternehmensgröße, Teamgröße, Infrastrukturumfang)
• **Aufgabe:** Definieren Sie Ihre spezifische Verantwortung (nicht die des Teams)
• **Aktion:** Beschreiben Sie konkrete Schritte, die Sie unternommen haben (Tools, Entscheidungen, Kommunikation)
• **Ergebnis:** Quantifizieren Sie das Resultat (Metriken, Akzeptanzraten, Kosteneinsparungen, Zeiteinsparungen)

**Beispiel: Aufbau einer Self-Service-Plattform**

• **S:** Bei [Unternehmen] (300 Ingenieure, 40 Microservices) warteten Entwickler durchschnittlich 3 Tage auf Infrastrukturbereitstellung und erstellten monatlich über 200 Tickets
• **A:** Ich wurde beauftragt, einen Self-Service-Infrastrukturkatalog zu entwerfen, um Bereitstellungsengpässe zu beseitigen
• **Ak:** Erstellung eines Crossplane-basierten Katalogs mit 12 verwalteten Ressourcenvorlagen (Datenbanken, Caches, Warteschlangen, Speicher-Buckets), Integration mit Backstage für eine entwicklerfreundliche Oberfläche, Implementierung von Genehmigungsworkflows für Produktionsressourcen und Erstellung umfassender Dokumentation mit Video-Anleitungen
• **E:** Die Bereitstellungszeit sank von 3 Tagen auf 15 Minuten. Monatliche Infrastruktur-Tickets gingen um 78 % zurück. Die Entwicklerzufriedenheit mit der Bereitstellung stieg von 2,8/10 auf 8,6/10. Der Katalog bearbeitete im ersten Quartal über 150 Bereitstellungsanfragen ohne Fehlkonfigurationen

Fragen an den Interviewer

1. **„Wie misst das Plattform-Team den Erfolg? Welche KPIs oder SLOs verfolgen Sie?"** — Testet, ob sie eine Produktmentalität haben oder als reaktive Supportfunktion arbeiten.
2. **„Was ist der aktuelle Developer-Experience-Schmerzpunkt, den das Plattform-Team priorisiert?"** — Zeigt, dass Sie über Entwicklerbedürfnisse nachdenken, und enthüllt die tatsächliche Arbeit, die Sie leisten würden.
3. **„Wie ist das Plattform-Team im Verhältnis zu den Produktteams strukturiert? Folgen Sie einem Team-Topologies-Modell?"** — Demonstriert organisatorisches Bewusstsein und hilft Ihnen, die Teamautonomie einzuschätzen.
4. **„Wie hoch ist Ihre aktuelle Bereitstellungshäufigkeit und wo liegt der Engpass?"** — Signalisiert, dass Sie in DORA-Metriken denken und auf messbare Verbesserung fokussiert sind.
5. **„Was ist die kontroverseste Infrastrukturentscheidung, die das Team kürzlich getroffen hat?"** — Zeigt Entscheidungskultur, Bewusstsein für technische Schulden und Offenheit für Diskussionen.
6. **„Wie sieht die Rufbereitschaft für das Plattform-Team aus? Wie häufig werden Ingenieure alarmiert, und wie hoch ist die durchschnittliche Vorfallschwere?"** — Praktische Frage, die betriebliche Reife und Work-Life-Balance aufzeigt.
7. **„Gibt es einen Architektur-Review- oder RFC-Prozess für bedeutende Plattformänderungen?"** — Zeigt, dass Sie bewusste Entscheidungsfindung und Dokumentationskultur schätzen.

Abschließende Erkenntnisse

Vorstellungsgespräche im Platform Engineering bewerten drei Dimensionen: technische Tiefe in Kubernetes, IaC und Cloud-Infrastruktur; Produktdenken bezüglich Developer Experience und Plattformakzeptanz; und betriebliche Reife bei Incident Response und Systemdiagnose. Bereiten Sie sich vor, indem Sie STAR-Geschichten rund um messbare Plattformergebnisse entwickeln (nicht nur Tool-Nutzung), Systemdesign-Fragen üben, die mehrere Infrastrukturkomponenten umfassen, und die spezifischen Infrastrukturherausforderungen des Unternehmens durch deren Engineering-Blog, Open-Source-Repos und Konferenzvorträge recherchieren. Die Kandidaten, die herausstechen, erklären nicht nur, was sie gebaut haben, sondern warum sie es gebaut haben, wie sie den Erfolg gemessen haben und was sie beim nächsten Mal anders machen würden.

Häufig gestellte Fragen

Wie viele Gesprächsrunden sollte ich für eine Platform-Engineer-Stelle erwarten?

In der Regel 4–5 Runden: Recruiter-Screening (30 Min.), Verhaltensgespräch mit dem Einstellungsmanager (45–60 Min.), technische Vertiefung mit einem Senior Engineer (60–90 Min.), Systemdesign mit einem Staff+-Ingenieur (60 Min.) und Team-/Kulturfit-Panel (45–60 Min.). Einige Unternehmen ergänzen eine Hausaufgabe (Terraform-Moduldesign, Kubernetes-Fehlerbehebungsszenario) als Vorauswahl oder Alternative zur Live-Technikrunde. Gesamtdauer des Prozesses: 2–4 Wochen vom Erstkontakt bis zum Angebot.

Sollte ich mich für ein Startup anders vorbereiten als für ein Großunternehmen?

Ja. Startups betonen Breite und Geschwindigkeit — sie wollen Ingenieure, die eine Plattform von Grund auf über mehrere Domänen aufbauen können (CI/CD, Observability, Kubernetes, Security), ohne auf spezialisierte Teammitglieder zu warten. Großunternehmen betonen Tiefe in spezifischen Domänen und die Fähigkeit, innerhalb etablierter Muster im großen Maßstab zu arbeiten. Startup-Interviews beinhalten oft praktische Übungen (etwas bauen/reparieren); Interviews in Großunternehmen tendieren zu Systemdesign-Whiteboard-Sitzungen.

Wie wichtig sind Go-Programmierkenntnisse in Platform-Engineering-Vorstellungsgesprächen?

Zunehmend wichtig ab dem mittleren Level. Wenn das Unternehmen eigene Kubernetes-Operatoren, Terraform-Provider oder CLI-Tools entwickelt, ist Go praktisch Pflicht. Junior-Kandidaten können Python- und Bash-Kenntnisse als Ausgangspunkt demonstrieren. Wenn Go-Fragen auftauchen, konzentrieren sie sich typischerweise auf das Verständnis der Kubernetes client-go-Bibliothek, das Schreiben von Reconciliation-Loops und das Verständnis von Go-Concurrency-Mustern, die für Infrastructure-Tooling relevant sind.

Was, wenn ich keine Erfahrung mit den spezifischen Tools des Unternehmens habe?

Konzentrieren Sie sich auf übertragbare Konzepte. Wenn Sie ArgoCD kennen, aber das Unternehmen Flux verwendet, erklären Sie GitOps-Prinzipien und Reconciliation-Muster — die Konzepte sind identisch. Wenn Sie AWS kennen, aber das Unternehmen GCP nutzt, besprechen Sie Kubernetes (plattformunabhängig) und Terraform-Moduldesign-Muster. Interviewer in gut geführten Unternehmen bewerten konzeptionelles Verständnis über tool-spezifische Erfahrung, da sich Tools schneller ändern als Prinzipien.

**Quellenangaben:** [1] DORA / Google Cloud, "2024 Accelerate State of DevOps Report," dora.dev, 2024.