Ingénieur Logiciel
Un CV d’ingénierie est généralement lu deux fois par deux personnes qui cherchent des choses différentes. Un recruteur compare la stack à celle de l’offre et y consacre bien moins d’une minute. Un ingénieur le lit ensuite pour évaluer la taille et la difficulté des systèmes sur lesquels vous avez travaillé. Une page réglée pour l’un seulement rate l’autre, et la plupart sont réglées pour le premier.
La liste de technologies vous fait lire, puis cesse d’aider
La correspondance de mots-clés au premier tri est réelle, et prétendre le contraire coûte des entretiens. Si l’offre dit Kotlin et Postgres et que vous avez livré avec les deux, ces mots doivent figurer. C’est tout le rôle de la rubrique compétences.
C’est aussi toute sa valeur. Dès qu’un ingénieur lit, une liste de dix-huit technologies nuit : elle laisse supposer que la plupart n’ont été touchées qu’une fois, et rend introuvables les deux où vous êtes réellement solide. Séparez ce sur quoi vous accepteriez volontiers un entretien technique de ce que vous avez seulement utilisé, ou supprimez le second groupe.
Numéros de version, tableaux d’années par langage et barres de niveau auto-évaluées se lisent comme du remplissage pour la personne qui vous fera passer l’entretien. Aucun ne survit à la première question technique.
Décrivez le système, pas le ticket
« Développé de nouvelles fonctionnalités en React et Node.js » figure sur des milliers de CV et ne dit rien de la difficulté. Ce qu’un ingénieur veut savoir, c’est l’échelle et la contrainte : combien de trafic, combien de données, combien de services, ce qui ne devait pas tomber, et qui d’autre dépendait de vous.
« Responsable du service de paiement — 400 requêtes par seconde en pointe, reprises idempotentes sur trois prestataires — et ramené les reprises pour échec de prélèvement de 11 % à 3 % » indique en une ligne quel genre d’ingénieur vous êtes. Cela offre aussi la question d’entretien qu’on allait vous poser de toute façon, ce qui joue en votre faveur.
Les incidents ont leur place ici. Quelque chose que vous avez cassé puis réparé, ou une panne que vous avez diagnostiquée, se retient d’une manière que le travail de fonctionnalité n’atteint pas, et démontre le sens opérationnel qui sépare un profil confirmé d’un senior bien mieux qu’un intitulé.
La séniorité se voit au rayon d’impact
Les intitulés sont du bruit d’une entreprise à l’autre : un senior dans une startup de douze personnes et un senior en banque ne disent pas la même chose, et tout le monde le sait. Ce qui voyage, c’est le rayon de vos décisions : combien d’autres personnes ont dû vivre avec, et pendant combien de temps.
Des documents de conception adoptés, une migration que d’autres équipes ont dû suivre, une interface appelée par une douzaine de services, une culture de revue que vous avez fait évoluer. Cela se lit comme de la séniorité dans n’importe quelle organisation. « Encadré des développeurs juniors » non, parce que cela figure sur tous les CV à partir du niveau confirmé et n’est jamais détaillé.
Si vous avez été la personne que les autres consultent avant de toucher à un domaine précis, c’est la phrase à écrire — et il faut nommer le domaine.
Où ces CV sont généralement écartés
Le schéma le plus dommageable est une page de responsabilités qui pourrait décrire n’importe quel développeur de n’importe quelle entreprise : participé aux revues de code, travaillé en environnement agile, collaboré avec des équipes pluridisciplinaires. Tout est vrai, tout est partagé avec les autres candidats, et l’ensemble fait une page entière de rien.
Le deuxième est une rubrique de projets personnels qui pèse plus que la rubrique professionnelle, sur un CV qui a de l’expérience professionnelle. Les projets en forme de tutoriel invitent à la comparaison avec votre travail rémunéré et la perdent. Gardez-en un s’il est réellement inhabituel, et seulement si vous aimeriez qu’on vous interroge dessus.
Le troisième est le silence sur les raisons d’un départ quand les dates parlent fort. Les passages courts et les trous sont ordinaires et ne deviennent gênants que si la page semble les éviter. Quatre mots — « fin de contrat », « équipe dissoute », « reprise d’études » — suppriment la question.
Des termes présents dans presque toutes les offres.
- Langages et frameworks nommés
- Un filtre littéral au premier tri. Indiquez ce qui est vrai et ce que l’offre nomme, sans remplissage.
- Conception de systèmes
- Trafic, volume de données, modes de défaillance. « Scalable » n’est pas une preuve.
- Cloud et infrastructure
- Précisez si vous l’exploitiez ou la consommiez. Ce sont deux métiers, et l’entretien le demande.
- Tests et intégration continue
- Ce que vous avez changé dans la façon de livrer de l’équipe, pas l’existence de tests.
- Astreinte / production
- Un incident que vous avez diagnostiqué dit plus sur la séniorité que n’importe quel intitulé.
N’ajoutez un terme que si votre propre expérience le justifie. ApplySpan signale les exigences que vous ne pouvez pas étayer au lieu de les écrire à votre place.
Questions
Quelle longueur pour un CV d’ingénieur logiciel ?+
Une page jusqu’à environ huit ans d’expérience, deux au-delà. Moins une règle qu’un constat : le premier tri est court, et on n’atteint la seconde page que si la première l’a mérité.
Faut-il un lien GitHub ou un portfolio ?+
Seulement s’il contient quelque chose sur quoi vous aimeriez être interrogé. Un profil abandonné de forks et de tutoriels vaut moins que pas de lien, car on vous jugera sur le plus faible élément trouvé.
Dois-je lister des technologies à peine pratiquées ?+
Pas dans le même groupe que vos points forts. Un recruteur pioche dans votre liste, et il n’y a rien à gagner à une question sur ce que vous avez touché une fois il y a deux ans.