Booking.com DevOps Engineer: Lebenslauf-Keywords und Interviewvorbereitung

Du willst dich als DevOps Engineer bei Booking.com bewerben und weißt nicht, wie dein Lebenslauf und deine Vorbereitung aussehen sollen. Die Stellenanzeigen des Unternehmens erwarten ein breites Setup aus Cloud, Automatisierung und Betrieb. Ich zeige dir, wie du das passend machst, ohne dich zu verbiegen.

Kurz vorab: Ich kenne die internen Prozesse von Booking.com nicht aus erster Hand. Was folgt, basiert auf öffentlichen Stellenanzeigen, auf dem, was in Tech-Teams üblich ist, und auf dem, was Recruiter typischerweise hören wollen.

Wo die Stellen liegen und was das für dich heißt#

Der Hauptsitz ist Amsterdam. Dort sitzen die meisten Tech-Teams, und viele Anzeigen laufen über das dortige Büro. In Deutschland hat das Unternehmen weniger Präsenz. Remote-Regeln ändern sich, das steht meist direkt in der Anzeige.

Prüfe also vor jeder Bewerbung drei Dinge: Standort, Arbeitsmodell und Visum. Wenn du aus Deutschland kommst, kläre früh, ob eine Umzugsunterstützung oder Visahilfe vorgesehen ist. Details ändern sich, verlass dich nicht auf Blogbeiträge von vor zwei Jahren. Lies die aktuelle Stellenanzeige und frag im Erstkontakt nach.

Was Booking.com typischerweise erwartet#

Die Anzeigen zeigen ein klares Muster. Kubernetes und Container sind fast immer dabei. Terraform oder vergleichbare Infrastructure-as-Code-Werkzeuge tauchen regelmäßig auf. Dazu kommen CI/CD, Monitoring und ein Cloud-Anbieter, oft AWS.

Was du daneben brauchst: Skripterfahrung in Python, Go oder Bash. Ein Gefühl dafür, wie verteilte Systeme ausfallen. Und die Bereitschaft, im On-Call mitzulaufen. Das steht selten fett gedruckt, gehört aber zum Job.

Die Anzahl der Jahre variiert je nach Seniority. Manche Anzeigen sprechen von drei Jahren Erfahrung, andere von fünf oder mehr. Lies die konkrete Ausschreibung. Ein generischer Lebenslauf auf Senior-Niveau passt selten zu einer Mid-Level-Rolle.

Wie du deinen Lebenslauf zuschneidest#

Der Fehler, den ich am häufigsten sehe: Leute listen Technologien auf und hören dort auf. Kubernetes, Terraform, AWS, Punkt. Das sagt einem Recruiter nichts über deine Wirkung. Es sagt nur, dass du die Wörter kennst.

Was zählt, ist der Kontext. Welches Problem hast du gelöst. In welcher Größenordnung. Mit welchem Ergebnis. Zahlen helfen, aber erfinde keine. Wenn du die echte Zahl nicht kennst, beschreibe die Größenordnung.

Nimm diese Ausgangsform:

• Verantwortlich für Kubernetes-Cluster und CI/CD-Pipelines

Und schreib sie so um:

• Betrieb von 40-plus Kubernetes-Clustern über drei Umgebungen, Migration der Deployments von manuellen Skripten zu Terraform-Modulen, dadurch Ausfallzeit bei Releases von Stunden auf Minuten gesenkt

Der Unterschied ist die Handlung, der Umfang und der Effekt. Die Zahlen hier sind ein Beispiel. Nimm deine echten.

So gehst du vor, wenn du deinen Lebenslauf anpasst:

• Lies die Stellenanzeige und markiere jede Technologie, die du wirklich kannst
• Sortiere die Anforderungen nach Gewichtung, meist steht das Wichtigste oben
• Bring pro Anforderung einen Beleg in deinem Lebenslauf, entweder als Bullet oder im Projektblock
• Streiche alles, was nicht zur Anzeige passt, auch wenn du stolz darauf bist
• Prüfe am Ende, ob dein Lebenslauf die Begriffe enthält, nach denen ein ATS sucht

Zum letzten Punkt: Viele Bewerbungen laufen durch ein Applicant Tracking System. Das gleicht deine Angaben mit der Anzeige ab. Ein kostenloses Werkzeug wie der ATS-Prüfer hilft dir, Lücken zu finden. Und wenn du eine Anzeige nicht entschlüsseln kannst, hilft ein Tool zum Zerlegen von Stellenbeschreibungen, um die echten Anforderungen herauszufiltern.

Keywords, die in der Anzeige vorkommen#

Baue diese Begriffe nur ein, wenn sie zu dir passen. Erfinden steht sich selbst im Weg, spätestens im Technikgespräch.

• Kubernetes, Container, Docker
• Terraform, Infrastructure as Code
• AWS oder der in der Anzeige genannte Anbieter
• CI/CD, GitLab CI, Jenkins oder vergleichbar
• Monitoring, Prometheus, Grafana, Observability
• Python, Go, Bash
• Incident Response, On-Call, Postmortem
• Linux, Netzwerkgrundlagen, Security Basics

Wenn du eine Lücke hast, etwa kein Go, dann lass es weg. Sag im Gespräch, dass du eine andere Sprache auf dem Niveau kannst und Go gerade lernst. Ehrlichkeit hält länger als ein Keyword.

Interviewvorbereitung: was dich erwartet#

Üblicherweise läuft es so: Erstgespräch mit Recruiting, dann ein technisches Gespräch, oft mit einem Coding- oder System-Design-Teil, dann ein Gespräch über Zusammenarbeit und Motivation. Manche Teams hängen ein Take-Home an. Die genaue Reihenfolge kenne ich nicht, frag beim Erstkontakt nach dem Ablauf.

Für den technischen Teil bereitest du dich auf drei Dinge vor. Erstens: Skripten und Debugging unter Zeitdruck. Zweitens: Systemdenken, also wie du ein verteiltes System stabilisierst. Drittens: Deine eigene Arbeit, in der Tiefe. Du wirst gefragt, warum du eine Entscheidung getroffen hast. „Weil das Team das so wollte" ist keine Antwort.

Übe, deine Projekte laut zu erklären. Nimm zwei bis drei Fälle aus deinem Alltag, in denen etwas schiefging oder knapp gutging. Beschreibe Ausgangslage, deine Entscheidung, das Ergebnis. Halte es unter zwei Minuten.

Beispiel für eine Interviewantwort#

Frage: Erzähl mir von einem Incident, das du gelöst hast.

Antwort: „Wir hatten einen Ausfall unseres Deployment-Systems am Freitagabend. Die Ursache war ein fehlerhaftes Terraform-Modul, das eine Ressource gelöscht hat, statt sie zu aktualisieren. Ich habe zuerst den Rollback der letzten funktionierenden Version gemacht, damit der Betrieb weiterläuft. Danach habe ich mit dem Team das Modul gefixt und einen zusätzlichen Check in die Pipeline eingebaut, der vor dem Anwenden einen Plan erzwingt. Der Fehler kam danach nicht mehr vor. Was ich gelernt habe: Ich hätte den Check schon früher einbauen sollen, nicht erst nach dem Vorfall."

Diese Antwort funktioniert, weil sie eine Handlung zeigt, eine Entscheidung und eine Lektion. Sie klingt nicht wie eine Erfolgsgeschichte, und genau das glaubt dir jemand.

Motivation und Passung#

Erwarte Fragen, warum Booking.com. Sei konkret. Das Unternehmen betreibt eine der meistfrequentierten Reiseplattformen Europas, das heißt hohe Last und hohe Ausfallsicherheit. Wenn dich genau das reizt, sag das. Vermeide Sätze wie „innovatives Unternehmen mit toller Kultur", die sagen nichts.

Frag deinerseits nach dem On-Call-Turnus, nach der Teamgröße, nach der Art der Postmortems. Das zeigt Interesse und hilft dir zu entscheiden, ob du dort arbeiten willst.

Gehalt und Vertrag#

Zahlen für DevOps-Rollen in den Niederlanden liegen oft höher als in Deutschland, die Lebenshaltung in Amsterdam auch. Typische Spannen werden online berichtet, aber sie ändern sich und hängen von Seniority und Verhandlung ab. Verlass dich nicht auf eine einzelne Quelle. Frag im Erstgespräch nach dem Rahmen und prüfe die aktuellen Angaben des Unternehmens.

Bei einem Umzug kläre Zusatzleistungen: Umzugskosten, vorübergehende Unterkunft, Visabegleitung für dich und Familie. Das steht selten in der Anzeige, ist aber verhandelbar.

Wo du passende Rollen findest#

Neben der Karriereseite des Unternehmens lohnt ein Blick auf aggregierte Stellenangebote. Dort siehst du, welche Rollen aktuell offen sind und wie die Anforderungen im Vergleich aussehen. Mehr Hintergrund zu Bewerbungsstrategien und Tech-Rollen findest du in unseren Artikeln.

Checkliste vor dem Absenden#

• Standort, Arbeitsmodell und Visathema in der Anzeige geprüft
• Jede Kernanforderung hat einen Beleg im Lebenslauf
• Keine Technologie aufgelistet, die du nicht erklären kannst
• Zahlen im Lebenslauf sind echt oder als Größenordnung formuliert
• Lebenslauf durch den ATS-Prüfer geschickt
• Zwei bis drei Incident-Beispiele für das Gespräch vorbereitet
• Antworten auf „Warum dieses Unternehmen" schriftlich ausformuliert
• Fragen an das Team notiert, mindestens drei

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie lang sollte mein Lebenslauf für eine DevOps-Rolle bei Booking.com sein?

Zwei Seiten sind für erfahrene Leute in Ordnung, eine Seite reicht bis etwa fünf Jahre Erfahrung. Wichtiger als die Länge ist die Dichte: Jede Zeile sollte eine Anforderung aus der Anzeige abdecken. Alles andere ist Ballast.

Brauche ich Zertifikate wie CKA oder AWS, um ernst genommen zu werden?

Zertifikate helfen bei der ersten Sichtung, ersetzen aber keine Projekterfahrung. Wenn du ein Zertifikat hast, nenne es kurz. Wenn nicht, betone stattdessen, was du im Betrieb gebaut und stabilisiert hast.

Soll ich meine Bewerbung auf Englisch oder Deutsch schreiben?

Auf Englisch. Die Unternehmenssprache in den Tech-Teams ist Englisch, die Ansprechpartner meist auch. Deutsch wäre im besten Fall ungewöhnlich und im schlimmsten Fall ein Zeichen, dass du die Anzeige nicht gelesen hast.

Was, wenn ich eine Kernanforderung nicht erfülle?

Bewirb dich trotzdem, wenn du den Großteil abdeckst. Beschreibe im Anschreiben oder im Gespräch, wie du die Lücke schließt und welche verwandte Erfahrung du mitbringst. Drei von fünf Anforderungen reichen oft, um ins Gespräch zu kommen.

Wie bereite ich mich auf System-Design-Fragen vor?

Übe, ein System mündlich zu zerlegen: Datenfluss, Engpässe, Ausfallverhalten, Monitoring. Nimm ein System, das du selbst betrieben hast, und erkläre, wo es brechen könnte. Konkrete Fälle wirken überzeugender als auswendig gelernte Architekturmuster.