Comment rédiger un CV pour un poste d'ingénieur backend ?

Vous avez déployé des services qui gèrent du trafic réel, vous avez été réveillé à 3h du matin par une alerte, et vos candidatures ne reçoivent aucune réponse. La raison la plus probable n'est pas que votre CV soit mal rédigé. C'est que la première personne à le lire est un recruteur qui ne peut pas évaluer l'ingénierie, travaillant à partir d'une liste d'exigences, et votre CV ne répond pas à cette liste dans les trente premières secondes. La deuxième raison la plus probable est que lorsqu'il atteint effectivement un responsable technique, il se lit comme une liste de tickets plutôt qu'un historique de systèmes que vous avez possédés.

Les deux problèmes peuvent être résolus, et les solutions sont spécifiques à ce métier.

Il n'y a ni qualifications, ni inscriptions, ni licences — dites plutôt la vérité

L'ingénierie backend au Royaume-Uni n'a pas de titre protégé, pas d'organisme d'enregistrement dont dépend le recrutement, et pas de licence. La charte BCS et le CEng existent et ne sont presque jamais un facteur pour obtenir un entretien backend en dehors de certains sous-traitants de la défense, du ferroviaire et du nucléaire. Un diplôme en informatique est courant et n'est pas requis ; l'apprentissage Digital and Technology Solutions Professional de niveau 6 et les parcours bootcamp-vers-industrie sont tous deux bien représentés dans les équipes qui recrutent bien. Si vous avez cinq ans ou plus d'expérience en production, la ligne du diplôme est une ligne près du bas, sans les modules.

Les choses qui fonctionnent effectivement comme des accréditations dans ce domaine sont différentes :

Habilitation de sécurité. L'habilitation SC ou DV est un véritable seuil pour le travail backend au Home Office, au MoD, chez les fournisseurs du GCHQ et dans de nombreuses sociétés de conseil du Crown Commercial framework. Si vous la détenez, mettez-la dans l'en-tête avec le niveau et si elle est en cours ou expirée. Si vous l'avez détenue et qu'elle a expiré, dites-le aussi — une habilitation expirée est beaucoup moins coûteuse à rétablir qu'à obtenir de zéro, et les responsables du recrutement dans ce secteur le savent.

Droit de travailler. Si vous détenez un droit de séjour permanent, un statut de résident, ou un passeport qui ne nécessite aucun parrainage, mettez-le en une ligne. Les employeurs capables de parrainer sont une minorité et ceux qui ne le sont pas vous filtreront silencieusement plutôt que de demander.

Exposition à la conformité sectorielle. Périmètre PCI DSS, systèmes de production régulés FCA, NHS DSP Toolkit, HIPAA, contrôles ISO 27001 que vous avez réellement mis en œuvre. Ce ne sont pas des certifications que vous avez obtenues, ce sont des contraintes sous lesquelles vous avez travaillé, et dans le recrutement fintech et santé elles ont plus de poids que n'importe quel certificat. « Construit et exploité des services dans le périmètre de l'environnement de données des titulaires de cartes PCI DSS » est une ligne qui se lit deux fois.

Ce qu'un responsable du recrutement backend examine en premier

Par ordre, approximativement, et rapidement :

1. Langage et runtime principaux, avec version. Java 8 et Java 21 sont des postes différents. La maintenance Python 2 et le Python asynchrone moderne sont des postes différents. Go, Kotlin, C#/.NET, Node/TypeScript, Ruby, Rust, Elixir, Scala — quel qu'il soit, il doit être lisible dans le premier tiers de la page un, pas enterré dans un bloc de compétences à la fin.
2. Bases de données. Postgres, MySQL, MongoDB, DynamoDB, Cassandra, et ce que vous en avez fait. « PostgreSQL » seul ne dit rien à un responsable. « Postgres : conception de schéma, optimisation d'index, partitionnement d'une table qui avait dépassé les performances de requête sur un seul nœud, migrations sans interruption avec double écriture et remplissage » leur dit tout.
3. Si vous avez géré des choses en production. Rotation d'astreinte, réponse aux incidents, SLO, budgets d'erreur, revues post-incident que vous avez rédigées. Un ingénieur qui n'a jamais fait que transmettre du code à une équipe ops est un recrutement différent de celui qui a été appelé pour son propre service, et cela est vérifié tôt.
4. Échelle et forme du trafic. Pas pour impressionner qui que ce soit — pour déterminer si vos instincts se transfèrent. Taux de requêtes, volumes de données, cibles de latence, tailles de lots, nombre de locataires. Utilisez vos vrais chiffres. Si vous ne les avez pas, décrivez plutôt la forme : « transactions financières à faible volume et haute valeur où l'exactitude importait plus que le débit » est une phrase véritablement informative et ce n'est pas un chiffre que vous avez dû inventer.
5. Messagerie et intégration. Kafka, RabbitMQ, SQS/SNS, Pub/Sub, gRPC, REST, GraphQL, webhooks. Si vous avez conçu les contrats ou consommé ceux de quelqu'un d'autre.

Tout le reste — Kubernetes, Terraform, pipelines CI, fournisseur cloud — compte, mais c'est le deuxième passage. Les ingénieurs qui commencent par un mur de noms de services AWS et enterrent le langage se classent eux-mêmes dans la mauvaise pile.

Les preuves dans ce domaine signifient systèmes, pas responsabilités

La plus grande différence entre un CV backend qui obtient un premier entretien téléphonique et un qui ne l'obtient pas est la différence entre décrire un poste et décrire un système.

Un poste sonne comme : « Responsable du développement et de la maintenance de microservices dans un environnement Java/Spring Boot en utilisant des méthodologies Agile. »

Un système sonne comme : « Propriété du service de traitement des commandes : Kotlin/Spring Boot, Postgres, groupe de consommateurs Kafka traitant les événements du service de paiement. Reconçu le consommateur pour être idempotent après que des livraisons en double produisaient des commandes facturées deux fois ; introduit une table outbox pour que l'écriture et la publication partagent une transaction. »

Le second est à peine plus long. Il dit à un responsable ce que vous savez sur le fait que la livraison exactement-une-fois est un mensonge, les outbox transactionnelles, et le mode de défaillance que vous avez rencontré. Il donne à l'intervieweur une question à vous poser, ce qui est le véritable objectif du document.

Écrivez deux ou trois de ceux-ci par poste récent. Pas huit. Choisissez ceux où quelque chose était difficile et vous pouvez expliquer le compromis.

Ce que les ingénieurs backend omettent régulièrement

C'est la partie qui coûte des entretiens aux gens, et c'est constant.

Migrations. Décomposition de monolithe, Python 2 vers 3, Postgres auto-géré vers RDS ou Aurora, sur site vers cloud, REST vers gRPC, d'un courtier de messages à un autre, une mise à jour majeure de version de framework sur des dizaines de services. Les ingénieurs omettent cela parce que ce n'étaient pas des fonctionnalités et cela ressemblait à de la maintenance. Les responsables du recrutement les évaluent très favorablement, car le travail de migration est l'endroit où le jugement, la rétrocompatibilité, les feature flags, les doubles écritures, les remplissages et les plans de rollback apparaissent tous en même temps. Si vous en avez dirigé une, elle appartient près du haut de ce poste.

Modélisation des données. « Conçu le schéma » est une phrase que la plupart des ingénieurs backend peuvent écrire honnêtement et la plupart ne le font pas. Dites quelles étaient les entités, quelle était la contrainte délicate, et ce que vous avez raté et avez dû changer.

Travail opérationnel avec un coût attaché. Réduction des dépenses cloud, suppression d'un cluster Redis dont personne n'avait besoin, dimensionnement approprié des instances, élimination d'un N+1 qui martelait une réplique de lecture. Les ingénieurs pensent que c'est peu glorieux. Quiconque a un budget ne pense pas cela.

Incidents. Pas pour admettre une faute — pour démontrer que vous avez été près de la production quand elle s'est cassée. « Diagnostiqué l'épuisement du pool de connexions sous un pic de trafic ; introduit PgBouncer et un circuit breaker sur l'appel en aval » est une ligne forte.

Tests au-delà du mot 'tests'. Tests de contrat entre services, Testcontainers, tests basés sur les propriétés, tests de charge avec k6 ou Gatling, comment vous avez testé une migration. « Écrit des tests unitaires » est du bruit. « Construit des tests de contrat entre notre service et trois consommateurs pour que nous puissions déployer indépendamment » est un signal de recrutement.

La forme de l'équipe et de la base de code. Combien d'ingénieurs, combien de services vous possédiez, quel âge avait la base de code, si vous étiez le seul ingénieur backend. Travailler seul sur un monolithe Rails legacy et travailler dans une équipe plateforme de douze personnes sont tous deux respectables et aucun n'est déductible d'un titre de poste.

Documents de conception et RFC. Si vous postulez au niveau senior, staff ou principal, ce qui est évalué est la portée de la prise de décision technique. Rédiger des documents de conception contre lesquels d'autres équipes ont construit est la preuve la plus claire de cela. Dites combien, sur quoi, et qui était l'audience.

La section compétences, et comment elle échoue habituellement

L'échec courant est une liste de soixante technologies dans un paragraphe, incluant chaque service AWS pour lequel vous avez déjà ouvert la console. Cela se lit comme du remplissage et cela rend une véritable force invisible.

Groupez par fonction et gardez chaque groupe court : langages, bases de données, messagerie, infrastructure, observabilité. Supprimez tout ce sur quoi vous ne voudriez pas être interrogé pendant dix minutes. Ne mettez pas d'années à côté de chaque élément et ne mettez pas de barres de compétence ou de notes en étoiles sur quoi que ce soit — un responsable technique lisant « Kafka ★★★☆☆ » n'apprend rien et se fait une opinion sur l'auteur.

Si vous êtes un ingénieur full-stack postulant pour des postes backend, le bloc de compétences est l'endroit où vous décidez de quoi parle le CV. React, Tailwind et Figma près du haut vous feront lire comme un ingénieur front-end qui veut un changement. Gardez l'expérience front-end — c'est un contexte véritablement utile — mais mettez-la après le matériel backend et décrivez-la comme ce qu'elle était.

Choses qui sont contestées, honnêtement

Certifications cloud. AWS Solutions Architect Associate, GCP Professional Cloud Developer, CKA. Dans les sociétés de conseil, les intégrateurs de systèmes, les boutiques partenaires AWS et certaines parties du secteur public, celles-ci sont visiblement pondérées, parfois parce que le statut de partenaire de l'employeur dépend du nombre de personnes qui les détiennent. Dans la plupart des entreprises de produits, elles sont proches de neutre, et une poignée d'ingénieurs seniors les dévaluent activement. Il n'y a pas de réponse universelle honnête. Regardez si l'annonce les nomme. Si c'est le cas, mettez-les dans l'en-tête. Sinon, une ligne en bas.

Liens GitHub. Un profil de huit dépôts de tutoriels et un dotfiles forké est pire que pas de lien. Un seul service déployé avec un README qui explique les compromis, ou un lien direct vers une PR fusionnée dans un projet que quelqu'un d'autre maintient, vaut beaucoup. Liez à la chose spécifique, pas au profil.

Longueur. La règle d'une page est une convention américaine qui ne régit pas le recrutement d'ingénierie britannique. Deux pages sont normales pour un ingénieur de niveau intermédiaire, trois sont acceptables au niveau staff avec un long historique, et les postes de plus d'environ dix ans devraient se réduire à une seule ligne chacun. Chargez le début de toute façon.

Projets personnels au niveau senior. Certains responsables les lisent comme de l'enthousiasme, certains comme un signal que vous n'obtenez pas assez de travail intéressant. Si le projet démontre quelque chose que votre travail rémunéré ne démontre pas — travail sur systèmes distribués, un langage vers lequel vous voulez évoluer — gardez-le. Sinon, il est en concurrence avec votre expérience de production et perd.

Que faire ensuite

Prenez la dernière annonce backend pour laquelle vous avez été rejeté sans réponse. Écrivez les quatre ou cinq choses qu'elle demande réellement — le langage, la base de données, le courtier de messages, l'échelle, si elle veut quelqu'un qui a été d'astreinte. Puis ouvrez votre CV et chronométrez combien de temps il faut pour trouver chacune. Si l'une d'entre elles prend plus de quelques secondes à localiser, déplacez-la vers le haut.

Puis réécrivez les deux puces les plus fortes de votre poste le plus récent comme des systèmes plutôt que des responsabilités : dans quoi c'était construit, à quoi cela parlait, ce qui s'est cassé ou était difficile, ce que vous avez changé. Gardez les vrais chiffres que vous avez et décrivez la forme où vous ne les avez pas.

Faire cela correctement pour chaque annonce est lent, c'est pourquoi la plupart des gens arrêtent de le faire après la première douzaine de candidatures ; jobmarket.pro lit chaque annonce en entier et prépare la candidature à partir d'un profil auquel il ne peut pas ajouter d'expérience.