Wie schreibe ich einen Lebenslauf für eine Backend-Engineer-Stelle?

Sie haben Services ausgeliefert, die echten Traffic verarbeiten, Sie wurden um 3 Uhr morgens von einem Pager geweckt, und Sie bekommen nichts auf Ihre Bewerbungen zurück. Der wahrscheinlichste Grund ist nicht, dass Ihr Lebenslauf schlecht geschrieben ist. Es ist, dass die erste Person, die ihn liest, ein Recruiter ist, der Engineering nicht bewerten kann, mit einer Anforderungsliste arbeitet, und Ihr Lebenslauf diese Liste nicht in den ersten dreißig Sekunden beantwortet. Der zweitwahrscheinlichste Grund ist, dass er, wenn er einen Engineering Manager erreicht, wie eine Liste von Tickets klingt und nicht wie eine Dokumentation von Systemen, die Sie betrieben haben.

Beide Probleme lassen sich beheben, und die Lösungen sind spezifisch für diesen Job.

Es gibt keine Qualifikationen, Registrierungen oder Lizenzen – sagen Sie stattdessen das Wahre

Backend-Engineering im Vereinigten Königreich hat keinen geschützten Titel, keine Registrierungsstelle, von der die Einstellung abhängt, und keine Lizenz. BCS-Chartership und CEng existieren und sind fast nie ein Faktor beim Erhalten eines Backend-Interviews außerhalb einiger Defense-, Bahn- und Nuklear-Auftragnehmer. Ein Informatikstudium ist üblich und nicht erforderlich; der Level 6 Digital and Technology Solutions Professional Apprenticeship und Bootcamp-zu-Industrie-Routen sind beide gut vertreten in Teams, die gut einstellen. Wenn Sie fünf oder mehr Jahre Produktionserfahrung haben, ist die Studienzeile eine Zeile ganz unten, ohne die Module.

Die Dinge, die in diesem Bereich tatsächlich wie Credentials funktionieren, sind anders:

Sicherheitsfreigabe. SC- oder DV-Freigabe ist ein echtes Tor für Backend-Arbeit beim Home Office, MoD, GCHQ-Lieferanten und vielen Crown Commercial Framework-Beratungen. Wenn Sie sie besitzen, setzen Sie sie in den Header mit dem Level und ob sie aktuell oder abgelaufen ist. Wenn Sie sie besessen haben und sie abgelaufen ist, sagen Sie das auch – abgelaufene Freigaben sind weitaus günstiger wiederherzustellen als von Grund auf neu zu beginnen, und Hiring Manager in diesem Sektor wissen das.

Arbeitsberechtigung. Wenn Sie unbefristeten Aufenthalt, Settled Status oder einen Reisepass haben, der kein Sponsoring benötigt, schreiben Sie es in einer Zeile. Sponsoring-fähige Arbeitgeber sind eine Minderheit, und diejenigen, die es nicht sind, werden Sie stillschweigend herausfiltern, anstatt zu fragen.

Domain-Compliance-Erfahrung. PCI DSS Scope, FCA-regulierte Produktionssysteme, NHS DSP Toolkit, HIPAA, ISO 27001-Controls, die Sie tatsächlich implementiert haben. Das sind keine Zertifizierungen, die Sie erworben haben, sondern Einschränkungen, unter denen Sie gearbeitet haben, und bei Fintech- und Gesundheitseinstellungen wiegen sie mehr als jedes Zertifikat. "Services innerhalb des PCI DSS Cardholder Data Environment Scope gebaut und betrieben" ist eine Zeile, die zweimal gelesen wird.

Was ein Backend Hiring Manager zuerst scannt

In etwa dieser Reihenfolge, und schnell:

1. Primäre Sprache und Runtime, mit Version. Java 8 und Java 21 sind verschiedene Jobs. Python 2 Wartung und modernes async Python sind verschiedene Jobs. Go, Kotlin, C#/.NET, Node/TypeScript, Ruby, Rust, Elixir, Scala – was auch immer es ist, es muss im ersten Drittel von Seite eins lesbar sein, nicht in einem Skills-Block am Ende vergraben.
2. Datastores. Postgres, MySQL, MongoDB, DynamoDB, Cassandra, und was Sie damit gemacht haben. "PostgreSQL" allein sagt einem Manager nichts. "Postgres: Schema-Design, Index-Tuning, Partitionierung einer Tabelle, die die Single-Node-Query-Performance überwachsen hatte, Zero-Downtime-Migrationen mit Dual-Write und Backfill" sagt ihnen alles.
3. Ob Sie Dinge in Production betrieben haben. On-Call-Rotation, Incident Response, SLOs, Error Budgets, Post-Incident-Reviews, die Sie geschrieben haben. Ein Engineer, der Code nur an ein Ops-Team übergeben hat, ist eine andere Einstellung als einer, der für seinen eigenen Service gerufen wurde, und das wird früh geprüft.
4. Größenordnung und Form des Traffics. Nicht um irgendjemanden zu beeindrucken – um herauszufinden, ob Ihre Instinkte übertragbar sind. Request-Raten, Datenvolumen, Latency-Ziele, Batch-Größen, Anzahl der Tenants. Verwenden Sie Ihre echten Zahlen. Wenn Sie sie nicht haben, beschreiben Sie stattdessen die Form: "low-volume, high-value Finanztransaktionen, bei denen Korrektheit wichtiger war als Durchsatz" ist ein wirklich informativer Satz und keine Zahl, die Sie erfinden mussten.
5. Messaging und Integration. Kafka, RabbitMQ, SQS/SNS, Pub/Sub, gRPC, REST, GraphQL, Webhooks. Ob Sie die Contracts entworfen oder die von jemand anderem konsumiert haben.

Alles andere – Kubernetes, Terraform, CI-Pipelines, Cloud-Provider – ist wichtig, aber es ist der zweite Durchgang. Engineers, die mit einer Wand von AWS-Service-Namen führen und die Sprache vergraben, sortieren sich selbst in den falschen Stapel.

Evidence in diesem Bereich bedeutet Systeme, nicht Verantwortlichkeiten

Der größte einzelne Unterschied zwischen einem Backend-Lebenslauf, der ein Telefoninterview bekommt, und einem, der keines bekommt, ist der Unterschied zwischen der Beschreibung einer Rolle und der Beschreibung eines Systems.

Eine Rolle klingt wie: "Verantwortlich für die Entwicklung und Wartung von Microservices in einer Java/Spring Boot-Umgebung mit agilen Methoden."

Ein System klingt wie: "Habe den Order-Fulfilment-Service betrieben: Kotlin/Spring Boot, Postgres, Kafka Consumer Group, die Events vom Checkout-Service verarbeitet. Habe den Consumer neu gestaltet, um idempotent zu sein, nachdem doppelte Lieferungen doppelt berechnete Bestellungen produzierten; habe eine Outbox-Tabelle eingeführt, sodass Write und Publish eine Transaktion teilten."

Das zweite ist kaum länger. Es sagt einem Manager, was Sie über exactly-once delivery als Lüge wissen, transaktionale Outboxes und den Fehlermodus, den Sie getroffen haben. Es gibt dem Interviewer eine Frage, die er Ihnen stellen kann, was der eigentliche Zweck des Dokuments ist.

Schreiben Sie zwei oder drei davon pro aktueller Rolle. Nicht acht. Wählen Sie diejenigen, bei denen etwas schwierig war und Sie den Trade-off erklären können.

Was Backend-Engineers routinemäßig weglassen

Das ist der Teil, der Leute Interviews kostet, und er ist konsistent.

Migrationen. Monolith-Dekomposition, Python 2 zu 3, selbst verwaltetes Postgres zu RDS oder Aurora, On-Prem zu Cloud, REST zu gRPC, ein Message Broker zu einem anderen, ein Major-Framework-Versions-Bump über Dutzende Services. Engineers lassen diese weg, weil sie keine Features waren und sich wie Wartung anfühlten. Hiring Manager bewerten sie sehr hoch, weil Migrationsarbeit der Ort ist, an dem Urteilsvermögen, Rückwärtskompatibilität, Feature Flags, Dual-Writes, Backfills und Rollback-Pläne alle auf einmal auftauchen. Wenn Sie eine geleitet haben, gehört sie ganz oben in diese Rolle.

Datenmodellierung. "Habe das Schema entworfen" ist ein Satz, den die meisten Backend-Engineers wahrheitsgemäß schreiben können und die meisten tun es nicht. Sagen Sie, was die Entities waren, was die knifflige Einschränkung war und was Sie falsch gemacht und ändern mussten.

Operative Arbeit mit Kosten. Cloud-Ausgaben senken, ein Redis-Cluster entfernen, das niemand brauchte, Instances richtig dimensionieren, ein N+1 töten, das ein Read Replica hämmerte. Engineers denken, das sei unspektakulär. Jeder mit einem Budget denkt das nicht.

Incidents. Nicht um Schuld zuzugeben – um zu demonstrieren, dass Sie in der Nähe von Production waren, als es kaputt ging. "Habe Connection-Pool-Exhaustion unter einem Traffic-Spike diagnostiziert; habe PgBouncer und einen Circuit Breaker beim Downstream-Call eingeführt" ist eine starke Zeile.

Testing über das Wort 'Tests' hinaus. Contract-Testing zwischen Services, Testcontainers, Property-Based Tests, Load-Testing mit k6 oder Gatling, wie Sie eine Migration getestet haben. "Habe Unit-Tests geschrieben" ist Rauschen. "Habe Contract-Tests zwischen unserem Service und drei Consumern gebaut, damit wir unabhängig deployen konnten" ist ein Hiring-Signal.

Die Team- und Codebase-Form. Wie viele Engineers, wie viele Services Sie betrieben haben, wie alt die Codebase war, ob Sie der einzige Backend-Engineer waren. Allein an einem Legacy-Rails-Monolithen zu arbeiten und in einem Platform-Team von zwölf zu arbeiten, sind beide respektabel und keines ist aus einem Job-Titel ableitbar.

Design-Dokumente und RFCs. Wenn Sie sich auf Senior-, Staff- oder Principal-Level bewerben, wird der Scope der technischen Entscheidungsfindung bewertet. Design Docs zu verfassen, gegen die andere Teams gebaut haben, ist der klarste Beweis dafür. Sagen Sie wie viele, worüber und wer die Zielgruppe war.

Die Skills-Sektion, und wie sie normalerweise scheitert

Das häufige Scheitern ist eine Liste von sechzig Technologien in einem Absatz, einschließlich jedes AWS-Service, für den Sie jemals die Konsole geöffnet haben. Es liest sich wie Padding und macht eine echte Stärke unsichtbar.

Gruppieren Sie nach Funktion und halten Sie jede Gruppe kurz: Sprachen, Datastores, Messaging, Infrastruktur, Observability. Lassen Sie alles weg, worüber Sie nicht zehn Minuten lang gefragt werden möchten. Setzen Sie keine Jahre neben jeden Punkt und setzen Sie keine Proficiency-Balken oder Sternebewertungen auf irgendetwas – ein Engineering Manager, der "Kafka ★★★☆☆" liest, lernt nichts und bildet sich eine Meinung über den Autor.

Wenn Sie ein Full-Stack-Engineer sind, der sich auf Backend-Rollen bewirbt, ist der Skills-Block der Ort, an dem Sie entscheiden, worum es im Lebenslauf geht. React, Tailwind und Figma ganz oben werden Sie als Front-End-Engineer lesen lassen, der eine Veränderung möchte. Behalten Sie die Front-End-Erfahrung – sie ist wirklich nützlicher Kontext – aber setzen Sie sie nach dem Backend-Material und beschreiben Sie sie als das, was sie war.

Dinge, die ehrlich umstritten sind

Cloud-Zertifizierungen. AWS Solutions Architect Associate, GCP Professional Cloud Developer, CKA. In Beratungen, Systemintegratoren, AWS-Partner-Shops und Teilen des öffentlichen Sektors werden diese sichtbar gewichtet, manchmal weil der Partner-Status des Arbeitgebers von der Anzahl der Mitarbeiter abhängt, die sie halten. In den meisten Produktunternehmen sind sie nahezu neutral, und eine Handvoll Senior Engineers diskontiert sie aktiv. Es gibt keine ehrliche universelle Antwort. Schauen Sie, ob die Anzeige sie nennt. Wenn ja, setzen Sie sie in den Header. Wenn nicht, eine Zeile ganz unten.

GitHub-Links. Ein Profil mit acht Tutorial-Repos und einem geforkten Dotfiles ist schlechter als kein Link. Ein einzelner deployter Service mit einer README, die die Trade-offs erklärt, oder ein direkter Link zu einem gemergten PR in einem Projekt, das jemand anderes wartet, ist viel wert. Verlinken Sie auf die spezifische Sache, nicht auf das Profil.

Länge. Die Ein-Seiten-Regel ist eine amerikanische Konvention, die UK Engineering Hiring nicht regiert. Zwei Seiten sind normal für einen Mid-Level-Engineer, drei sind akzeptabel auf Staff-Level mit langer Geschichte, und Rollen älter als etwa zehn Jahre sollten zu einer einzelnen Zeile pro Rolle zusammenfallen. Laden Sie trotzdem vorn.

Persönliche Projekte auf Senior-Level. Einige Manager lesen sie als Enthusiasmus, einige als Signal, dass Sie nicht genug interessante Arbeit bekommen. Wenn das Projekt etwas demonstriert, was Ihre bezahlte Arbeit nicht tut – Distributed-Systems-Arbeit, eine Sprache, in die Sie wechseln möchten – behalten Sie es. Sonst konkurriert es um Platz mit Ihrer Produktionserfahrung und verliert.

Was als Nächstes zu tun ist

Nehmen Sie die letzte Backend-Anzeige, von der Sie ohne Antwort abgelehnt wurden. Schreiben Sie die vier oder fünf Dinge auf, die sie tatsächlich verlangt – die Sprache, der Datastore, der Message Broker, die Größenordnung, ob sie jemanden will, der On-Call war. Dann öffnen Sie Ihren Lebenslauf und stoppen Sie die Zeit, wie lange es dauert, jedes zu finden. Wenn eines davon mehr als ein paar Sekunden zum Lokalisieren braucht, verschieben Sie es nach oben.

Dann schreiben Sie die zwei stärksten Bullets in Ihrer aktuellsten Rolle als Systeme statt als Verantwortlichkeiten um: worin es gebaut wurde, womit es sprach, was kaputt ging oder schwierig war, was Sie geändert haben. Behalten Sie die echten Zahlen, die Sie haben, und beschreiben Sie die Form, wo Sie sie nicht haben.

Dies für jede Anzeige richtig zu machen ist langsam, weshalb die meisten Leute damit aufhören, nachdem sie die ersten Dutzend Bewerbungen gemacht haben; jobmarket.pro liest jede Anzeige vollständig und bereitet die Bewerbung aus einem Profil vor, dem es keine Erfahrung hinzufügen kann.