Kontekst · JD 1:1
Co robi ta konkretna rola
Mały zespół platformowy. Każdy engineer w firmie zależy od tego, co utrzymujecie. To nie jest „DevOps od ticketów”.
Jedno zdanie z JD
Szukają kogoś, kto weźmie kawałek infrastruktury end-to-end: projekt, Terraform, CI/CD, on-call. Raportujesz do Head of Platform Infrastructure.
WHAT YOU’LL DO — przetłumaczone na zachowania
| Punkt JD | Co chcą usłyszeć |
|---|---|
| Own infra domains end to end | „Wziąłem domain X. Decyzje Y. On-call Z.” Nie „w zespole robiliśmy”. |
| Terraform modules across dev/staging/prod/PCI, Spacelift | Moduły z kontraktem, remote state, drift, plan review, apply z PR. Spacelift albo analog (Atlantis / TFC) — jeśli nie Spacelift, powiedz analogię: policy, concurrency, private workers. |
| GitHub Actions dla floty Java/Kotlin | Reusable workflows, matrix, cache Gradle/Maven, OIDC do AWS, promocja środowisk. |
| Lambda w Go i Python | Operational tooling: metryki, rotacja sekretów, IAM auth, event dispatch. Python jest twardym wymaganiem. |
| Observability | Monitory i SLO są częścią definition of done, nie biletem po incydencie. |
| Security i compliance bez ticket hell | Baseline IAM/KMS, self-service dla product teamów, wyjątki jako produkt z expiry, nie jako Slack. |
| On-call | Rotacja się formuje — możesz kształtować. Pytaj o load i co budzi w nocy. |
| AI assisted coding daily | Używasz do shippowania, nie do recenzowania cudzego promptu. Na live-coding mów wprost, co robisz AI-em. |
WHAT YOU’LL BRING — priorytety
- Musi być: 5+ lat platform/infra, produkcyjny AWS w skali, VPC, IAM, ECS i EKS, Lambda, RDS, Terraform z migracjami state, GitHub Actions w skali, Datadog albo odpowiednik, wysoki Python, komunikacja z product engineerami, IAM Roles Anywhere / cert-based auth, biegłość w AI tools.
- Szczególnie cenne: Kubernetes na produkcji, bo migrują ECS → EKS.
- Bonus: PCI/ISO/SOC2 awareness, Go na tyle żeby utrzymać Lambdy, operacje Kafki.
Nie mów tak
„Znam AWS, Terraform i K8s, szybko się uczę reszty.” To CV, nie rozmowa. Brzmi jak junior z listą narzędzi.
Mów tak
„Na produkcji prowadziłem N kont AWS, Terraform dla M zespołów, CI dla K serwisów. EKS znam z Y. Migrację ECS→EKS umiem zaplanować tak i tak. Spacelift nie robiłem — robiłem X, różnica to policy i concurrency.”
Dział, który dopiero powstaje
W ogłoszeniu Head of Platform Infrastructure (publiczne, 2026) widać plan rozbicia platformy na:
- Cloud / Kubernetes
- SRE
- Developer Productivity & Experience
- Security Engineering
- FinOps & Cost Management
- Data Platform Engineering
Wchodzisz w moment, gdy jeden szeroki zespół ma stać się działem. Szansa i bałagan jednocześnie. Stack w tamtym JD: Java, Spring Boot, PostgreSQL, Kafka, AWS, Docker, Terraform.
Pierwszy rok według nich
- Pierwsze tygodnie: orientacja — konta, IaC, pipeline’y, historia on-call. Małe zmiany infra.
- Do 3. miesiąca: własny domain. Ty robisz call, review PR, odpowiadasz na pager.
- Do roku: coś, co zmniejsza robotę zespołu — reliability, security control albo self-service, które obcięło ticket volume.
To jest ich definicja success: mniej tarcia, mniej ticketów, self-service. Traktuj product engineering jak klientów platformy.
Oferta (to, co jest w JD)
- „Attractive remuneration” — widełek w ogłoszeniu nie ma.
- Windows albo Mac.
- Remote EU/UK.
- Karta Pliant z miesięcznym kredytem.
O wynagrodzenie pytaj po rundzie tech, nie w pierwszej minucie z rekruterem, chyba że oni sami otworzą temat.
Ćwiczenie dnia 1
Weź 8 wymagań z tabeli „WHAT YOU’LL BRING”. Przy każdym zapisz:
- jedną historię z Twojego CV (albo szczerze: „nie robiłem, analogia to X”),
- jedną liczbę (konta, serwisy, MTTR, redukcja ticketów, czas apply),
- jedno zdanie trade-offu.
Potem otwórz Historie STAR i wpisz cztery najmocniejsze.