Viele Cloud-Stellenanzeigen lesen sich wie eine Einkaufsliste für Infrastruktur-Tools.
AWS. Terraform. Kubernetes. Docker. Prometheus. Grafana. Helm.
Je länger die Liste, desto besser scheint das Profil definiert zu sein.
Doch genau hier beginnt eines der größten Probleme im Cloud-Recruiting.
Cloud-Architekturen bestehen nicht aus Tools. Sie bestehen aus Entscheidungen. Entscheidungen darüber, wie Systeme skaliert werden, wie Services miteinander kommunizieren, wie Ausfallsicherheit gewährleistet wird oder wie Infrastruktur automatisiert wird.
Tools sind lediglich die Umsetzung dieser Architekturentscheidungen.
Wenn Recruiting ausschließlich auf Tool-Checklisten basiert, sucht man nicht nach Architekt:innen oder Engineers. Man sucht nach Menschen, die bestimmte Software einmal benutzt haben.
Und das führt fast immer zu den falschen Kandidaten.
Warum Cloud-Stellenanzeigen oft wie Tool-Listen aussehen
Viele Hiring Manager definieren Cloud-Rollen über Technologien, die im aktuellen Stack verwendet werden.
Typische Anforderungen sehen dann so aus:
AWS
Kubernetes
Terraform
Docker
CI/CD
Monitoring Tools
Diese Liste wirkt zunächst logisch. Schließlich arbeitet das Team tatsächlich mit diesen Tools.
Das Problem ist jedoch, dass diese Technologien nur ein sehr kleiner Teil der eigentlichen Rolle sind.
Ein Cloud Engineer oder Cloud Architect beschäftigt sich in der Praxis mit Fragen wie:
Wie wird eine hochverfügbare Architektur aufgebaut?
Wie werden Workloads über mehrere Availability Zones verteilt?
Wie lassen sich Deployments automatisieren?
Wie werden Systeme beobachtbar (Observability)?
Diese Fragen haben oft mehrere mögliche Lösungen – und können mit unterschiedlichen Toolkombinationen umgesetzt werden.
Recruiting, das ausschließlich nach Tools sucht, übersieht daher Kandidaten mit starkem Architekturverständnis.
Warum Tool-Checklisten schlechte Kandidaten liefern
Tool-Listen führen häufig zu einem klassischen Recruiting-Effekt: Kandidaten optimieren ihre Profile auf Keywords.
Ein Profil kann beispielsweise folgende Begriffe enthalten:
AWS
Kubernetes
Terraform
Docker
Damit erfüllt es formal alle Anforderungen einer typischen Cloud-Stellenanzeige.
Das sagt jedoch wenig über die tatsächliche Kompetenz aus.
Hat diese Person Kubernetes-Cluster designed oder nur genutzt?
Hat sie Terraform-Module entwickelt oder lediglich bestehende Skripte angepasst?
Hat sie Multi-Region-Architekturen gebaut oder einfache Deployments betreut?
Cloud-Engineering unterscheidet sich stark in der Tiefe der Erfahrung.
Ein Recruiting-Modell, das ausschließlich auf Keywords basiert, kann diese Unterschiede kaum erkennen.
Was gutes Architekturverständnis im Cloud-Umfeld wirklich bedeutet
Cloud-Architektur beschreibt die Struktur eines Systems in der Cloud.
Dazu gehören unter anderem:
Service-Strukturen
Netzwerkdesign
Skalierungsmodelle
Deployment-Strategien
Observability
Ein erfahrener Cloud Engineer denkt daher häufig in Architekturmustern statt in Tools.
Ein Beispiel für typische Architekturentscheidungen könnte so aussehen:
compute:
type: containerized
orchestrator: kubernetes
networking:
load_balancing: aws_alb
service_mesh: istio
deployment:
strategy: blue_green
observability:
metrics: prometheus
tracing: opentelmetry
Die Tools sind hier nur eine Implementierungsebene.
Das eigentliche Wissen liegt in den Entscheidungen über Skalierung, Deployment oder Netzwerkdesign.
Recruiting sollte daher stärker auf diese Architekturkompetenzen achten.
Warum Cloud-Rollen extrem unterschiedlich sein können
Der Begriff „Cloud Engineer“ ist einer der unscharfsten Jobtitel im Tech-Markt.
Unter diesem Titel können sehr unterschiedliche Rollen verborgen sein.
Beispiele:
Infrastructure Engineer
Platform Engineer
Site Reliability Engineer
Cloud Architect
DevOps Engineer
Diese Rollen überschneiden sich teilweise stark – haben aber unterschiedliche Schwerpunkte.
Ein Site Reliability Engineer konzentriert sich häufig auf:
Systemstabilität
Observability
Incident Response
Ein Platform Engineer dagegen eher auf:
Developer Platforms
Self-Service Infrastructure
Internal Tooling
Wenn Recruiting diese Unterschiede nicht erkennt, entstehen unklare Rollenprofile.
Das führt zu langen Suchprozessen und vielen ungeeigneten Kandidatenvorschlägen.
Warum Cloud-Recruiting stärker technisch werden muss
Der Cloud-Markt wächst weiter rasant. Gleichzeitig steigen die technischen Anforderungen an viele Rollen.
Recruiting kann deshalb nicht mehr ausschließlich administrativ funktionieren.
Erfolgreiche Cloud-Suchen erfordern zunehmend ein grundlegendes Verständnis von:
Cloud-Architektur
Container-Orchestrierung
Infrastructure as Code
Microservice-Architekturen
Das bedeutet nicht, dass Recruiter selbst Cloud-Architekt:innen sein müssen.
Aber sie müssen verstehen, wie diese Systeme aufgebaut sind.
Nur so lassen sich Suchstrategien entwickeln, die tatsächlich relevante Kandidaten identifizieren.
So hat indivHR einen Cloud Architect gefunden, der zuvor übersehen wurde
Ein Unternehmen suchte einen AWS Cloud Architect mit Kubernetes-Erfahrung.
Mehrere Suchläufe konzentrierten sich auf Profile mit dem Titel „Cloud Architect“.
Die Ergebnisse waren begrenzt.
Eine Analyse des Talentmarktes zeigte jedoch mehrere Kandidaten mit anderen Titeln, darunter „Platform Engineer“.
Ein Kandidat hatte umfangreiche Erfahrung mit:
Multi-Account AWS Architekturen
Infrastructure as Code mit Terraform
Kubernetes Cluster Design
Der Titel war generisch. Die Architekturkompetenz war exakt passend.
Der Kandidat wurde eingestellt – nachdem er zuvor in keiner klassischen Titelsuche aufgetaucht war.
Viele Cloud-Suchen scheitern nicht daran, dass es keine passenden Kandidaten gibt.
Sie scheitern daran, dass Recruiting nach Tools sucht – während die eigentliche Kompetenz in Architekturentscheidungen liegt.
Wer Cloud-Rollen erfolgreich besetzen will, muss verstehen, wie moderne Cloud-Systeme aufgebaut sind und welche Fähigkeiten dafür tatsächlich relevant sind.
Wenn interne Teams bei komplexen Cloud- oder DevOps-Rollen regelmäßig zu wenige passende Profile finden, übernimmt indivHR die gezielte Suche nach erfahrenen Spezialist:innen – und liefert erste vorqualifizierte Kandidat:innen in durchschnittlich 14 Tagen.
