Pytania na rozmowie na stanowisko Inżyniera Platformy

Menedżerowie w firmach z dojrzałymi zespołami platformowymi raportują, że 60% kandydatów nie przechodzi rozmów technicznych nie z powodu braku wiedzy o narzędziach, ale z powodu myślenia o projektowaniu systemów i umiejętności wyjaśniania decyzji infrastrukturalnych w języku biznesowym [1]. Rozmowy na inżyniera platformy różnią się od ogólnych rozmów DevOps jedną kluczową rzeczą: rekruterzy oceniają, czy myślisz o infrastrukturze jako produkcie wewnętrznym.

Kluczowe wnioski

• Spodziewaj się 3 etapów: behawioralny/dopasowanie kulturowe, pogłębienie techniczne, projektowanie systemów
• Pytania behawioralne skupiają się na myśleniu platformowym: empatia dla developerów, współpraca międzyzespołowa, prowadzenie incydentów
• Pytania techniczne testują Kubernetes, IaC i architekturę obserwowalności
• Scenariusze sytuacyjne oceniają priorytetyzację konkurencyjnych wymagań platform od wielu zespołów
• Przygotuj 4-5 historii STAR o wpływie platformy, reagowaniu na incydenty i poprawie developer experience

Pytania behawioralne (STAR)

1. Opisz budowę funkcji platformowej, której developerzy początkowo się opierali.

**Dlaczego pytają**: Inżynierowie platform budują produkty wewnętrzne. Adopcja to kluczowa metryka.

2. Opowiedz o najsłożniejszym incydencie produkcyjnym, którym zarządzałeś.

**Dlaczego pytają**: Testuje przywództwo incydentowe, głębokość debugowania i zapobieganie.

3. Dwa zespoły produktowe miały sprzeczne wymagania wobec platformy. Jak rozwiązałeś?

**Dlaczego pytają**: Testuje priorytetyzację, zarządzanie interesariuszami i myślenie produktowe.

4. Jak przekonałeś kierownictwo do inwestycji w platformę zamiast funkcji produktowych?

**Dlaczego pytają**: Testuje komunikowanie wartości infrastruktury w języku biznesowym.

5. Jak mierzyłeś sukces zbudowanej platformy?

**Dlaczego pytają**: Myślenie produktowe wymaga pomiaru — metryki DORA, satysfakcja developerów, wskaźniki adopcji self-service.

Pytania techniczne

1. Co się dzieje, gdy pod jest planowany w Kubernetes, od momentu zastosowania manifestu Deployment?

**Co oceniają**: kubectl → serwer API (autentykacja, autoryzacja, kontrolery admisji) → zapis etcd → scheduler (filtrowanie, scoring, binding) → kubelet → CRI → CNI → readiness probe → rejestracja endpointu.

2. Zaprojektuj strategię modułów Terraform dla 15 zespołów produktowych.

**Co oceniają**: Kompozycja modułów, izolacja stanu, konfiguracja remote backendu, RBAC, wersjonowanie modułów, wykrywanie dryfu.

3. Wdrożenie bezprzestojowych aktualizacji Kubernetes dla klastra z 500+ podami.

**Co oceniają**: PodDisruptionBudgets, rolling update puli węzłów, polityka skew wersji, walidacja pre-upgrade, strategia canary, monitorowanie, procedury rollback.

4. Zaprojektuj stos obserwowalności dla 50 mikroserwisów.

**Co oceniają**: Metryki (Prometheus + Thanos), logi (Fluent Bit → Loki), trace'y (OpenTelemetry → Tempo/Jaeger), korelacja, alerty oparte na SLO, self-service Grafana.

5. Developer zgłasza, że deploy zajmuje 45 minut. Jak diagnozujesz?

**Co oceniają**: Systematyczne podejście. Prześledź pipeline: checkout, zależności, build, testy, push obrazu, sync ArgoCD, planowanie poda. Zidentyfikuj wąskie gardło przed optymalizacją.

6. Kyverno vs OPA/Gatekeeper — kiedy które?

**Co oceniają**: OPA/Gatekeeper — język Rego, stroma krzywa uczenia, złożone polityki cross-resource. Kyverno — natywne YAML, niższy próg wejścia, walidacja/mutacja/generacja.

Pytania sytuacyjne

1. Zespół 5 osób, 8 zespołów produktowych z jednoczesnym zapotrzebowaniem. Jak priorytetyzujesz?

**Podejście**: Kategoryzuj wg wpływu × powagi, pilności, strategicznego dopasowania. Transparentny proces intake: cotygodniowe spotkanie priorytetyzacyjne, publiczny roadmap, SLA wg typu żądania.

2. Nowy CTO chce migracji z AWS do GCP w 6 miesięcy.

**Podejście**: Ocena wpływu, identyfikacja ryzyk, podejście fazowe — najpierw abstrakcja przez Terraform, POC na non-prod, migracja produkcji z rollbackiem. Kwestionuj timeline z dowodami jeśli nierealistyczny.

3. Intermitentne eviction podów w godzinach pracy.

**Podejście**: Sprawdź presję zasobów na węzłach, requests vs actual usage, efekty noisy neighbor, logi autoscalera. Wdróż ResourceQuota i LimitRange.

4. 40% plików stanu Terraform nie było stosowane od 6 miesięcy — narastający dryf.

**Podejście**: Nie stosuj ślepo terraform apply. Plan dla każdego pliku, klasyfikuj dryf, wdróż ciągłe wykrywanie dryfu, ustanów politykę governance.

5. VP inżynierii chce bezpośredniego dostępu zespołu do produkcyjnego Kubernetes.

**Podejście**: Alternatywy: read-only kubectl przez RBAC, dashboardy Grafana, ephemeral containers, agregacja logów. Jeśli nalegają — czasowo ograniczony dostęp z logowaniem audytowym.

Kryteria oceny

**Głębokość techniczna (40%)**: Czy potrafisz wyjaśnić jak systemy działają na poziomie komponentów? **Projektowanie systemów (25%)**: Czy potrafisz projektować komponenty platformy dla wielu zespołów w skali? **Produkt i komunikacja (20%)**: Czy potrafisz wyjaśnić decyzje infrastrukturalne w kategoriach biznesowych? **Incydenty i operacje (15%)**: Czy systematycznie diagnozujesz problemy produkcyjne?

Pytania do rekrutera

1. "Jak zespół platformowy mierzy sukces?"
2. "Jaki jest aktualny priorytetowy problem developer experience?"
3. "Jak zespół jest zorganizowany względem zespołów produktowych?"
4. "Jaka jest aktualna częstotliwość deploymentów i gdzie leży wąskie gardło?"
5. "Jaka była ostatnia kontrowersyjna decyzja infrastrukturalna?"
6. "Jak wygląda on-call dla zespołu platformowego?"
7. "Czy istnieje proces przeglądu architektury lub RFC?"

Końcowe wnioski

Rozmowy oceniają trzy wymiary: głębokość techniczna, myślenie produktowe o developer experience i dojrzałość operacyjna. Przygotuj STAR stories z mierzalnymi wynikami platformowymi.

FAQ

Ile rund rozmów?

Zazwyczaj 4-5: screening, behawioralna, techniczna, system design, panel kulturowy. 2-4 tygodnie łącznie.

Startup vs duża firma?

Startupy podkreślają szerokość, duże firmy — głębokość w specyficznych domenach.

Jak ważny jest Go?

Coraz ważniejszy na mid+ poziomie. Jeśli firma buduje operatory Kubernetes — praktycznie wymagany.

Brak doświadczenia z konkretnymi narzędziami firmy?

Skup się na przenoszalnych konceptach. ArgoCD vs Flux — zasady GitOps są identyczne.

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