Si vous êtes développeur, vous avez probablement eu cette sensation : appliquer à un poste, c’est comme passer les auditions de The Voice. Sauf que vous n’avez pas une, deux, ou trois chances : vous en avez cinq. Cinq entretiens. Plus tests techniques. Plus vérification de références. Et à la fin, même si vous êtes en finale, il y a encore des tours éliminatoires que vous ignorez.

Bienvenue dans le processus de recrutement tech moderne, où les entreprises ont décidé que la confiance était un luxe qu’elles ne pouvaient pas se permettre.

The Voice du recrutement : une analogie qui devrait vous mettre mal à l’aise

Pensez à The Voice. Imaginez que pour participer au show :

Étape 1 (Les auditions à l’aveugle) = Entretien RH / téléphonique Vous faites une vidéo de vous qui se présente. Le recruteur l’écoute, vous pose des questions génériques. « Parlez-moi de vous ? Pourquoi cette entreprise ? » Vous savez que 90% des candidats sont éliminés ici. Vous devez être parfait, enthousiaste, souriant, même si vous êtes en dépression de chercher un emploi depuis 3 mois.

Étape 2 (Les chaises se tournent) = Entretien technique avec un ingénieur Maintenant, un ingénieur vous pose des questions. Des vraies questions cette fois. Pas juste « parlez-moi de vous », mais « codez une fonction en O(n log n) pour inverser un tableau d’objets nested ». Vous avez 30 minutes. Pas de Google. Pas StackOverflow. Juste vous, votre cerveau stressé, et un IDE rempli de bugs de syntaxe.

Mais attendez. Vous avez 12 ans d’expérience en développement backend en production. Vous avez conçu des systèmes qui servent des millions d’utilisateurs. Et on vous demande de implémenter un algorithme de tri que personne dans l’équipe n’a jamais écrit à la main. L’entreprise utilise Redis, PostgreSQL, et des frameworks modernes. Pas d’algorithmes en temps linéaire implémentés manuellement.

Étape 3 (Les tests en loge) = Test technique asynchrone ou live coding session Avant même le prochain entretien, on vous envoie un test. Ou un cas pratique. Ou une architecture à designer. À faire en 1-2 heures. À la maison. Après votre journée de travail. Parce que oui, vous êtes probablement employé ailleurs et vous candidatez la nuit, comme un fantôme.

Étape 4 (Les batailles) = Entretien avec le manager / tech lead Maintenant, le manager rencontre le candidat. « Parlez-moi d’un projet où vous avez échoué. » « Décrivez-moi vos forces et vos faiblesses. » « Comment géreriez-vous un conflit dans une équipe ? » Vous devez être psychologue, manager de projets, et expert en soft skills. On évalue pas juste vos compétences tech, mais votre « fit culturel ». Ce terme vague qui signifie souvent « serais-je ami avec toi à la pause café ».

Étape 5 (Les finales) = Entretien avec les stakeholders / panel entier Maintenant, il y a des stakeholders. Le CTO, l’équipe entière, le chef de produit. Vous êtes face à 5 personnes qui vous dévisagent. C’est une pièce de théâtre avec un public. Vous devez performer. Vous devez être charismatique. Vous devez montrer que vous n’êtes pas juste un bon développeur, mais un leader, un mentor, un communicateur hors pair.

Étape 6 (Les références) = Appels aux anciens employeurs Et juste avant de vous dire oui, ils appellent vos anciens patrons. Ils demandent si vous êtes vraiment aussi bon que vous l’avez prétendu dans les 5 entretiens précédents. Comme si les 5 étapes n’avaient pas suffi à vérifier ça.

Et tout ça, pour quoi ? Le manque de confiance exposé

Voici la vérité crue : aucune de ces étapes n’existe parce que c’est une bonne pratique. Elles existent parce que les entreprises tech n’ont confiance en rien.

Elles n’ont confiance ni en leurs candidats, ni en leurs recruteurs, ni en leurs managers. Elles pensent que si elles ne font pas 5 entretiens + tests + références, elles vont embaucher un imposteur qui va tout détruire en une semaine.

Sauf que… elles ont aussi une période d’essai. En France, c’est jusqu’à 8 mois. Aux États-Unis, c’est « at-will » : on peut te virer le jour même si on veut. Mais apparemment, ça ne suffit pas. Il faut aussi ne pas laisser entrer l’imposteur en premier lieu.

Résultat ? Un filtrage paranoia : « On va éliminer 95% des candidats avant d’en embaucher un, juste pour être sûr. »

La sur-évaluation systématique : demander des questions de CTO à un senior dev

Voici où le système devient vraiment absurde : chaque entreprise estime à la hausse les exigences du poste.

Un poste « Développeur Senior » finit par demander des compétences qui devraient être celles d’un CTO ou d’un Principal Engineer. Pourquoi ?

Des questions de direction pour un poste de IC

Vous vous asseyez en face d’un ingénieur senior qui vous pose :

  • « Comment tu architecterais un système pour 100 millions d’utilisateurs ? »
  • « Explique-moi les trade-offs entre une architecture monolithique et microservices »
  • « Comment tu déploierais ça sur 3 continents avec une latence < 100ms ? »
  • « Montre-moi comment tu approchais les décisions de tech stack dans tes projets précédents »

Mais le poste ? C’est un poste de développeur normal. Vous allez coder des features. Intégrer des APIs. Maintenir du code. Écrire des tests.

La personne qui vous interviewe imagine inconsciemment qu’elle recrute son remplaçant, ou son successeur. Elle impose ses propres standards. Elle veut un CTO, mais elle ne peut payer qu’un Senior Dev.

Résultat : vous devez faire semblant de savoir des choses que vous ne saurez jamais utilisées. Vous improvisez des réponses à des questions qui ne sont pas pertinentes pour le job. Et vous êtes jugé sur des critères qui n’existent nulle part dans la description du poste.

Des tests d’algorithmes qui n’existent nulle part dans le métier

Et puis il y a les tests. Les fameux tests d’algorithmes.

« Implémente un BFS pour trouver le chemin le plus court dans un graphe non-pondéré. »

« Résous le problème du vendeur de journaux avec une complexité O(n) en espace et O(n log n) en temps. »

« Implémente une structure de données Union-Find avec compression de chemin. »

Franchement ? 99% des développeurs qui codent au quotidien n’écriront jamais ça.

Votre stack quotidien : JavaScript/TypeScript/Python. Vous utilisez des librairies existantes. Vous appelez Array.sort() ou sorted(). Les algorithmes de tri ? C’est implémenté en O(n log n) par la stdlib. Union-Find ? Jamais utilisé.

Mais on vous teste dessus. Pourquoi ? Parce qu’on confond « quelqu’un qui peut apprendre » avec « quelqu’un qui maîtrise les structures de données classiques ». C’est comme tester la capacité d’un ingénieur électricien à construire un transistor à partir de silicium brut, juste pour vérifier qu’il sait comment fonctionnent les circuits.

Et voici le pire : c’est un test qui récompense la préparation, pas l’intelligence. Quelqu’un qui a fait 100 problèmes LeetCode le mois dernier va réussir. Un développeur brillant qui n’a pas eu le temps de préparer va échouer. On teste la capacité de bachotage, pas la compétence réelle.

La sur-évaluation progressive : chaque étape pousse plus haut

Mais le plus insidieux ? La sur-évaluation progressive.

Étape 2 : « T’as O(n log n) ? D’accord, mais explique-moi aussi la complexité spatiale et prouve que c’est optimal. »

Étape 3 : « Bon, tu maîtrises les algo. Mais là, on te donne un cas pratique. Tu dois pas juste coder, tu dois aussi penser à la scalabilité, à la maintenabilité, à la testabilité, et designer une architecture qui supporte 10 000 requêtes par seconde. »

Étape 4 : « Okay, t’as l’architecture. Mais maintenant, dis-moi comment tu irais en production. Monitoring ? Logging ? Alertes ? Comment tu débogues une issue en production à 3h du matin ? »

Étape 5 : « Excellent. Maintenant, dis-moi comment tu leadériserais une équipe. Tu as 3 devs juniors, un stagiaire, et tu dois livrer une feature compliquée en 2 semaines. Raconte-moi ton approche. »

À chaque étape, les exigences montent. Et à chaque étape, c’est un profil différent qu’on teste :

  • Étape 2 = Un ITA (Ingénieur Technique Avancé)
  • Étape 3 = Un Architect
  • Étape 4 = Un Ops/SRE
  • Étape 5 = Un CTO / Tech Lead

Mais c’est un seul poste ! Vous imaginez si on testait un candidat à un poste d’infirmier en lui demandant à la fois de faire des injections (Étape 2), de diagnostiquer des maladies (Étape 3), de gérer un service hospitalier (Étape 4), et de définir la politique de santé du pays (Étape 5) ?

C’est fou. C’est exactement ce qui se passe en recrutement tech.

Le coût humain : l’athlète épuisé

Maintenant, revenez à The Voice. Imaginez que vous êtes candidat. Vous êtes musicien talentueux, ou chanteur, ou musicien compositeur. Vous audition pour le show parce que c’est une opportunité incroyable.

Mais le processus ? Il demande que vous :

  1. Vous donniez à 1000% chaque fois. Pas de « bah, c’est un entretien test ». Non. À chaque étape, vous devez être au top. Synthétiser vos meilleurs projets. Pratiquer vos réponses aux questions pièges. Vous préparer mentalement. C’est épuisant.

  2. Gardez l’esprit positif. Parce que la moindre once de frustration, la moindre moment où vous montrez que le processus vous déprime, vous êtes out. Les recruteurs cherchent des gens « motivés ». Quelqu’un qui a l’air de trouver ça normal de passer 8 heures d’entretiens pour un CDI à 50k par an.

  3. Répétiez ce processus pour chaque entreprise. Chaque semaine, une nouvelle entreprise, une nouvelle série de 5 entretiens. Vous êtes dans un concours permanent. Vous candidatez partout, vous préparez partout, vous échouez partout. Et chaque fois, vous devez remettre de l’énergie.

C’est inhumain. C’est ce qu’on demande à un athlète olympique, pas à quelqu’un qui veut juste coder et gagner sa vie.

Les travers du processus : The Voice nous le montre

The Voice a au moins l’honnêteté d’être un spectacle. Tout le monde sait que c’est dramatisé, que les caméras tournent, que c’est un divertissement. Les candidats savent à quoi ils s’attendent.

Mais le recrutement tech ? Il prétend être objectif. Rationnel. Basé sur les compétences.

Sauf qu’en réalité :

1. L’objectivité est une illusion Les tests techniques supposés « objectifs » testent en réalité votre capacité à faire un test technique sous stress, pas votre capacité à coder au quotidien. Un développeur brilliant qui freeze under pressure va échouer. Un développeur moyen qui a mémorisé les patterns LeetCode va réussir. Où est l’objectivité là-dedans ?

2. Le « fit culturel » est souvent un code pour « ressemble-moi » Quand un entretien évalue le « fit culturel », en réalité, souvent, on teste : « serais-je ami avec toi ? », « viendrais-tu à la happy hour ? », « trouverais-tu drôles les mêmes mèmes que moi ? ». C’est un biais de confirmation déguisé en compétence. Et ça filtre systématiquement certains profils : introverts, neurodiverse, immigrants, femmes, parents.

3. La fatigue de la performance crée des non-représentations Plus le processus est long, plus ça favorise les candidats qui ont le temps et l’énergie de se préparer. Les parents solo qui travaillent et qui n’ont pas le temps de faire des tests LeetCode le soir ? Out. Les gens en reconversion qui doivent justifier chaque choix de carrière ? Out. Les gens qui ont du succès dans des petites boîtes sans grande notoriété ? Out.

4. Les références sont un chaînage de privilèges Si vous devez appeler mon ancien patron pour vérifier que je suis bon, vous présumez que j’ai eu des anciens patrons dans des « bonnes » entreprises. Un étudiant qui sort de l’école ? Il n’a pas de références. Un immigrant qui a travaillé ailleurs ? Ses références ne parlent pas français. Un autodidacte qui vient de terminer une formation ? Il n’a pas d’historique. Le processus filtre structurellement les profiles non-conventionnels.

5. La sur-évaluation du profil Chaque entreprise recrute pour le profil qu’elle aurait aimé avoir plutôt que pour le profil dont elle a besoin. Un poste de Senior Dev finit par demander l’expertise d’un Principal Engineer. Des tests d’algorithmes complexes sur un poste qui n’en utilisera jamais. Des questions de CTO sur l’architecture système pour un poste où vous allez juste coder des features. Le résultat ? 90% des candidats sont overqualified ou sont rejetés parce qu’ils n’ont pas « l’expérience CTO » qu’on leur demande. Et les quelques personnes embauchées sont frustrées parce qu’elles ont surjoué un rôle au recrutement et la réalité est décevante.

Le piège des 5 entretiens

Voici ce que je ne comprends pas : si vous êtes déjà capable d’identifier un bon candidat en 3 entretiens bien structurés, pourquoi en faire 5 ?

La réponse révèle la vraie maladie : la peur de se tromper. Les entreprises tech, qui sont censées être innovantes et prendre des risques, sont absolument terrifiées à l’idée d’embaucher quelqu’un qui ne convient pas.

Et là réside l’ironie finale : en évitant le risque d’embaucher « la mauvaise personne », vous garantissez d’avoir des équipes homogènes, sans diversité, sans perspective nouvelle, sans créativité. Vous éliminez le bruit qui pourrait devenir du signal. Vous tuez l’innovation avant même qu’elle commence.

Et maintenant, qu’est-ce que vous avez créé ?

Avec ce processus, les entreprises tech ont créé un marché du travail qui :

  • Épuise les bons candidats. Les gens brillants se fatiguent après 3-4 processus éliminator et arrêtent de candidater.
  • Avantage les survivants du système. Ceux qui ont déjà tout : un réseau, une marque personnelle, une confiance innée. Les autres ? Ils se découragent.
  • Manque des talents cachés. Tous les développeurs brillants qui auraient pu être excellents avec un peu de formation, une bonne intégration, et du soutien ? Jamais embauchés.
  • Crée une culture de la méfiance. Si le processus d’embauche est une bataille, la culture interne sera une bataille aussi.

La question simple à se poser

Avant de mettre en place votre cinquième entretien, posez-vous cette question simple : « Est-ce que cette étape m’aide réellement à prendre une meilleure décision, ou est-ce que c’est juste de la paranoia structuralisée ? »

Parce que si vous avez une période d’essai, si vous avez un onboarding solide, si vous investissez dans la formation et la croissance de votre équipe, vous n’avez pas besoin de 5 entretiens. Vous avez besoin de suffisamment d’entretiens pour vérifier que la personne :

  • Sait coder (ou peut apprendre)
  • N’est pas un sociopathe
  • Est passionnée par le domaine
  • Peut communiquer

C’est tout. Les trois premières étapes le font. La quatrième commence à être de la paranoia. La cinquième ? C’est juste du spectacle.

La vraie conversation qu’il faut avoir

La vraie question pour les entreprises : voulez-vous embaucher le meilleur candidat, ou le candidat qui a le plus de temps à consacrer à vos tests ?

Parce que ce sont deux choses très différentes.

Quand vous faites 5 entretiens, vous n’optimisez pas pour la compétence. Vous optimisez pour la disponibilité, la confiance en soi, l’accès à des ressources pour se préparer. Et vous éliminez systématiquement les gens qui ont trop de responsabilités, trop peu de privilèges, ou trop peu d’énergie pour jouer ce jeu.

Conclusion : Il est temps de changer

Ça demande une chose simple : de la confiance.

Pas en l’embauche parfaite (elle n’existe pas). Pas en l’absence de risque (il y en aura toujours). Mais en votre capacité à accueillir quelqu’un, à le former, et à le laisser devenir excellent.

Les entreprises tech passent 40 heures à filtrer un candidat. Puis 0 heure à l’intégrer. À l’onboarder. À lui donner les outils pour réussir. Elles devraient inverser ça.

Au lieu de demander à un Senior Dev de répondre à des questions de CTO, posez-lui les questions qui importent :

  • « Peux-tu apprendre vite ? »
  • « Tu sais comment tu apprends mieux ? »
  • « Qu’est-ce qui te motive vraiment ? »
  • « Tu es prêt à être honnête quand tu ne sais pas quelque chose ? »

Pas de BFS, pas d’Union-Find, pas de 5 entretiens. Juste une conversation avec une personne que vous avez l’intention de former et de développer.

Et ensuite ? Donnez-lui une vraie chance. Pas une période d’essai où tout le monde espère en secret qu’il part. Mais un vrai apprentissage, des cycles clairs, des objectifs atteignables, et du temps.

Les meilleures équipes du monde ne sont pas composées de gens qui avaient déjà tout maîtrisé avant d’arriver. Elles sont composées de gens qu’on a pris le temps de développer.

Le recrutement tech doit arrêter d’imiter The Voice et commencer à imiter comment les vraies organisations construisent du talent.