Le lion, la sorcière et l’audace éhontée des recruteurs
(hauleth.dev)- Un candidat critique, à travers les processus de recrutement de deux entreprises, la manière dont le décalage entre le poste et les tâches réelles et l’asymétrie du feedback gaspillent le temps des candidats
- Hop.NS a lancé un contrat d’essai d’une semaine pour un poste de Senior Elixir Developer, mais la mission réelle consistait à maintenir une extension de navigateur en TypeScript et à ajouter des fonctionnalités UI
- Au début de la semaine d’essai, du temps a été perdu pour obtenir l’accès à Slack, GitHub et à des modèles de conception, et il a fallu environ 10 à 12 heures avant de pouvoir exécuter l’extension en local
- PerhapsMaybe a mené plus de 5 heures d’entretiens techniques puis a refusé de fournir un feedback individuel, avant d’envoyer une semaine plus tard une enquête sur l’expérience candidat en demandant, cette fois, du feedback uniquement au candidat
- Si une entreprise exige beaucoup de temps et d’implication, elle doit aussi fournir une description de poste précise, des motifs de refus personnalisés et un minimum de respect envers les candidats
Hop.NS : une semaine d’essai transformée d’un poste Elixir en mission sur une extension de navigateur
- Le candidat a postulé à une offre de Hop.NS vue sur LinkedIn, où travaillait un ancien collègue
- Le nom de l’entreprise et certains détails ont été modifiés pour éviter des problèmes juridiques
- Par le passé, l’entreprise demandait un take-home project d’une semaine et rémunérait ce temps
- L’offre portait sur un poste de Senior Elixir Developer, et l’appel avec le CTO a bien tourné autour du rôle de développeur Elixir, de l’équipe et des processus
- Le CTO a expliqué que, pendant le contrat d’essai d’une semaine, il s’agirait de réaliser « le type de travail confié une fois embauché »
- Les documents contractuels ont été traités sans problème, et la semaine d’essai a commencé le lundi à 09:00
Jour 1 : problèmes d’accès et découverte de la vraie mission
- Le premier jour, le candidat a bien reçu des identifiants d’e-mail d’entreprise temporaires, mais n’a pas pu accéder au workspace Slack, avec pour seul message qu’il fallait contacter un administrateur
- Faute de canal de contact, il a envoyé un message sur LinkedIn à une connaissance interne pour demander de l’aide sur les accès
- 2 à 3 heures du contrat de 40 heures ont été perdues à cause du problème d’accès à Slack
- Il a ensuite dû attendre et refaire des demandes pour obtenir aussi l’accès à GitHub et pouvoir cloner le dépôt
- Comme la personne chargée du suivi se trouvait en Amérique du Sud, l’appel d’explication de la mission a été fixé à 18:00, et avant cela il a parcouru la codebase Elixir en ouvrant une petite PR de correction
- Lors de l’appel du soir, il a découvert que la mission de la semaine d’essai consistait en réalité à maintenir une extension de navigateur en TypeScript et à ajouter de nouvelles fonctionnalités ainsi qu’un design UI
- Le candidat a précisé qu’il avait peu d’expérience dans ce domaine, mais son interlocuteur a confirmé que c’était bien la mission prévue
- Il lui a aussi été dit de « ne pas s’inquiéter », car « tout le travail backend était déjà terminé »
- Le candidat en a conclu que le travail backend/Elixir qu’il recherchait était déjà fait, et qu’on lui demandait désormais d’effectuer un travail à dominante front-end qu’il ne voulait pas faire
Jour 2 : mise en place de l’environnement et confirmation du décalage de rôle
- Le deuxième jour, il a fallu installer Google Chrome pour pouvoir exécuter et comprendre l’extension de navigateur
- Le candidat préfère habituellement Safari et Firefox, et évitait donc d’utiliser Chrome
- Il lui a fallu plusieurs heures pour comprendre comment builder et lancer le projet en local, tout en continuant à contacter différentes personnes pour obtenir des identifiants et des accès supplémentaires
- Lors d’un échange avec la connaissance qui l’avait recommandé, il a demandé s’il était normal qu’une mission de semaine d’essai puisse être totalement éloignée du domaine d’expertise du candidat
- Cette personne a répondu qu’il arrivait de sortir les candidats de leur zone de confort, mais que donner un travail purement front-end à un développeur backend indiquait qu’il y avait un problème
- Elle a aussi dit qu’à sa place, elle aurait arrêté immédiatement
- Le candidat a néanmoins décidé de continuer par respect pour les deux personnes qui l’avaient recommandé
- Dans le canal Slack dédié au recrutement, il a demandé si, une fois embauché, il continuerait à travailler sur ce projet ou ferait autre chose, et la réponse a été : « pas toujours »
- Il a encore dû relancer son interlocuteur pour obtenir le modèle de conception, et ce n’est qu’après 10 à 12 heures sur les 40 heures prévues qu’il a enfin réussi à exécuter l’extension en local
Jour 3 : extension du périmètre et arrêt de la semaine d’essai
- Le troisième jour, il comprenait mieux la manière de travailler et ce qu’il fallait faire, mais manquait toujours de connaissances en débogage d’extensions de navigateur
- Vers midi, au milieu de la semaine d’essai, l’entreprise a encore élargi le périmètre de la mission
- Le candidat a alors protesté dans un long message en expliquant que la mission ne correspondait en rien à ce qui avait été présenté pendant le processus de recrutement
- La description de poste ne mentionnait ni TypeScript ni les extensions de navigateur
- Il avait répété à plusieurs reprises qu’il était un ingénieur à profil « backend-and-ops »
- Selon lui, cette mission faisait perdre du temps autant à lui-même qu’à l’entreprise
- Il a précisé que la seule raison pour laquelle il n’avait pas abandonné plus tôt était le respect qu’il portait aux personnes qui l’avaient recommandé
- Le CTO a répondu qu’il cherchait à vérifier si le candidat « correspondait bien à la culture », a dit ne pas penser que l’entreprise avait commis une faute, puis a demandé à ce que l’histoire ne soit pas rendue publique
- Hop.NS a payé les quelque 20 heures de travail particulièrement pénibles
- Trois à quatre semaines plus tard, le CTO lui a demandé sur LinkedIn s’il était intéressé par un poste de Staff Software Engineer, et le candidat lui a rétorqué en demandant s’ils pratiquaient toujours ce type de bait-and-switch
PerhapsMaybe : pas de feedback après un long entretien, mais une enquête envoyée ensuite
- Chez PerhapsMaybe, un poste de Software Engineer with Elixir était ouvert, et le candidat a postulé car il connaissait des personnes dans l’entreprise
- L’une de ses connaissances a fait remonter sa candidature auprès du VP of Infrastructure, qui semblait être le hiring manager du poste, mais le processus n’a pas été rapide
- Les informations de candidature ont été envoyées le 27 mai 2026
- Le premier contact de l’équipe recrutement n’est arrivé que le 11 juin 2026, soit plus de deux semaines plus tard
- Ce n’est qu’après avoir envoyé une invitation au VP sur LinkedIn que la personne chargée du recrutement l’a contacté
- L’appel d’une heure avec le VP s’est bien passé, et son intérêt pour le poste a grandi
- Ensuite, la coordination des entretiens techniques s’est poursuivie, et l’ensemble du processus a été planifié sur 5 heures 30
Structure des entretiens chez PerhapsMaybe et notification de refus
- Les entretiens ont eu lieu sur une seule journée, avec des pauses de 30 minutes et de 2 heures entre les sessions
- Ils comportaient trois parties
- Systems Design 1 heure : concevoir un système de paiement asynchrone utilisant une passerelle de paiement synchrone
- Coding Interview 1 heure : exercices de type LeetCode comme le produit cartésien et le déplacement de pièces d’échecs sur un clavier
- Technical Deep Dive 1 heure : explication des détails techniques d’un projet passé, Ultravisor
- Le candidat estime avoir commis une erreur dans l’analyse de la complexité en big-O sur le deuxième exercice du coding interview, mais juge que sa solution restait globalement correcte
- Lors du Technical Deep Dive, il a eu le sentiment de s’en être correctement sorti, mais aussi l’intuition que ses interlocuteurs n’avaient pas été impressionnés ou attendaient autre chose
- À la fin du deuxième jour après les entretiens, il a demandé une mise à jour à la personne chargée du recrutement et a reçu une réponse négative
- L’e-mail de refus contenait la formule indiquant qu’en raison du grand nombre de candidats, aucun feedback individuel ne serait fourni
L’asymétrie du feedback créée par l’enquête sur l’expérience candidat
- Une semaine après le refus, l’équipe recrutement de PerhapsMaybe a envoyé un e-mail de Candidate Experience Survey
- Le message expliquait qu’ils voulaient vérifier si le processus de recrutement était efficace et si l’expérience candidat était bonne, et demandait un retour honnête ainsi que des pistes d’amélioration sur l’expérience récente d’entretien
- Le candidat estime que l’entreprise dispose probablement d’environ 5 heures d’enregistrements et de notes de réunion automatiques
- Il précise pour sa part qu’il lui est interdit d’utiliser l’IA pour prendre des notes de réunion
- Il critique le fait que l’entreprise refuse de fournir ne serait-ce que 3 ou 4 phrases personnalisées pour expliquer le refus, tout en demandant au candidat un retour pour améliorer son processus
- Le candidat dit avoir eu l’impression d’être traité non comme un candidat, mais comme un prestataire chargé d’évaluer le processus de recrutement, et a demandé les billing details afin d’envoyer une facture au tarif d’un contractuel
Critique du marché de l’emploi et rare exemple positif
- Le candidat décrit le marché actuel de l’emploi comme dysfonctionnel
- Il mentionne que certains recruteurs dénoncent l’usage des LLM pendant le processus de candidature
- Il critique aussi les formulaires qui posent souvent des questions comme « Pourquoi voulez-vous travailler chez XYZ ? » ou « Qu’est-ce qui vous enthousiasme le plus dans le fait de travailler chez XYZ ? »
- Selon lui, son travail n’est pas de revendre à l’entreprise son propre produit
- Il dit vouloir simplement faire un travail qui l’intéresse et être payé pour cela
- Il affirme que seuls les fondateurs peuvent être sincèrement enthousiasmés par le produit d’une entreprise, et qu’après l’IPO, les actionnaires ne veulent plus que la hausse de la valeur
- À l’inverse, dans le processus de candidature chez Fresha, Christine Wong a représenté un exemple positif
- Le motif du refus était un « manque d’expérience avec les coding agents »
- Christine Wong a demandé à organiser un appel afin de transmettre elle-même un feedback personnalisé
- Le candidat dit avoir apprécié de voir une vraie personne faire preuve de respect envers les candidats, et se dit reconnaissant pour cette expérience
1 commentaires
Avis sur Lobste.rs
Dire qu’il s’agit de pousser le candidat hors de sa zone de confort donne l’impression qu’on cherche un prétexte pour recruter la personne voulue en ignorant le reste.
Demander à un développeur backend de faire du pur frontend puis prétendre évaluer son « adéquation culturelle », c’est comme reprocher à un poisson de ne pas savoir grimper aux arbres.
Tant que les travailleurs ne contrôleront pas les embauches et les licenciements de leur équipe, au moins pour leur propre équipe, ce genre de manigances continuera probablement.
Je n’ai pas vraiment ressenti une grande empathie pour l’auteur de ce billet.
Dans un environnement d’entreprise, il n’est pas si choquant de perdre une journée à obtenir des droits d’accès ou à parler à quelqu’un dans un autre fuseau horaire, et la façon de réagir à ce genre de situation est un bon signal pour évaluer l’adéquation culturelle.
Il n’est pas non plus surprenant que la tâche la plus urgente sorte du périmètre prévu du poste ; un candidat capable de travailler au-delà de son périmètre a plus de valeur pour l’entreprise que quelqu’un qui reste cantonné à un domaine précis.
Bien sûr, si on demande de travailler hors de son domaine d’expertise, l’avancement sera forcément plus lent et le résultat moins bon, mais l’entreprise préférera probablement cela à un refus pur et simple.
Qu’un recruteur mette plusieurs semaines à planifier les entretiens, ou que contacter un vice-président sur LinkedIn accélère le processus, n’a rien d’étrange dans un environnement d’entreprise. Savoir quand contacter un vice-président fait aussi partie du travail.
Si le recruteur a demandé du feedback sans en donner au candidat, dire que c’est ce qui vous a le plus marqué peut déjà constituer un bon feedback.
Ce qui m’a le plus gêné, c’est le terme « bitch » barré tout en haut. Appeler ainsi une collègue ou future collègue n’est jamais acceptable. On peut être en désaccord, mais pas recourir à une attaque personnelle visant le genre.
L’offre décrivait un poste de pur backend, et j’avais aussi dit que j’avais presque exclusivement fait du backend et de l’exploitation système.
Mais si on me propose un poste de pur backend puis qu’on me donne soudain une tâche dont je ne connais rien, en attendant en 32 heures maximum une solution fonctionnelle avec un « design cohérent avec le reste du système », je ne peux y voir qu’un manque de respect envers mon expérience et mes connaissances.
J’ai travaillé plus de dix ans comme développeur backend, dont environ sept sur l’observabilité et la performance ; le frontend que j’ai fait de manière relativement importante remonte à huit ans, quand j’ai ajouté des fonctionnalités à une application Vue existante.
S’ils essaient d’évaluer mon expérience et mes connaissances avec une tâche de ce type, je ne peux que conclure qu’ils ne veulent pas de moi. À mes yeux, plutôt que de le dire poliment, me forcer à souffrir sur un travail dénué de sens frôle l’insulte.
Que le calendrier de recrutement prenne plusieurs semaines m’a aussi surpris. Un ingénieur senior/principal/staff de cette entreprise m’avait recommandé auprès de ce vice-président deux semaines plus tôt, et je savais que le vice-président l’avait confirmé.
J’ai fourni du feedback, et j’ai aussi demandé les informations de facturation du recruteur afin de pouvoir lui facturer du conseil sur le processus de recrutement.
Heureusement, il existe d’autres façons d’obtenir du feedback. Comme je suis dans l’UE, le RGPD me permet de demander toutes les notes et tous les détails concernant mon processus de recrutement.
Le langage d’entreprise existe pour permettre à deux personnes situées aux antipodes sur toutes les grandes questions de la vie de très bien avancer ensemble vers les objectifs de l’entreprise.
Je l’ai lu de la même façon. Je comprends que ce soit un coup de gueule destiné à des amis, mais si une attitude de ce genre était apparue ne serait-ce qu’un peu pendant l’entretien, j’aurais probablement refusé de poursuivre.
La disposition à travailler hors de son domaine d’expertise n’est pas seulement précieuse pour un employeur ; elle peut aussi ouvrir des opportunités de carrière et d’apprentissage qu’on n’aurait jamais découvertes en s’obstinant à rester dans son périmètre.
L’important est de communiquer sur l’endroit où se situe cette limite afin d’ajuster correctement les attentes et le calendrier, et la capacité à le faire est en soi un signal fort lors d’un entretien.
Cela dit, il faut un équilibre. Si votre trajectoire de carrière est déjà très claire et que le projet demandé ne vous y conduit pas, il peut être préférable de consacrer votre temps ailleurs.
Mais je ne pense pas que je prendrais personnellement comme une insulte le fait que mes objectifs et ceux de l’employeur divergent, ni que je prendrais le risque de couper les ponts.
Rien qu’en lisant ce billet, je ne pense pas que je l’embaucherais ; cela paraît immature et peu professionnel.
Il m’est arrivé quelque chose d’assez intéressant récemment. Un recruteur d’une entreprise m’a contacté pour me demander si j’étais ouvert à une discussion, et comme j’utilise le produit de cette entreprise tous les jours, j’ai accepté.
Au début de l’appel, le recruteur m’a demandé : « Alors, que recherchez-vous ? » Or je ne cherchais rien. Comme c’est lui qui m’avait contacté, je pensais que ce n’était pas à moi de convaincre l’entreprise, mais à l’entreprise de me convaincre.
J’ai tout de même supposé que c’était une formule courante, et nous avons parlé pendant environ une heure de ce que faisait l’entreprise, etc. À la fin, il m’a demandé si j’étais prêt à poursuivre un processus pouvant mener à une offre après trois entretiens techniques ; comme j’étais dans une position relativement confortable avec un emploi stable, j’ai accepté, pensant que cela pouvait être intéressant.
Le recruteur a dit qu’il m’enverrait un e-mail après l’appel, puis nous nous sommes dit au revoir.
Mais pendant près d’une semaine, aucun e-mail n’est arrivé. J’ai fini par écrire pour demander s’il avait oublié, et quelques jours plus tard, j’ai reçu une réponse disant qu’ils avaient décidé de ne pas poursuivre le processus cette fois-ci.
Je n’avais même pas postulé, et pourtant j’avais en quelque sorte reçu une notification de refus, ce qui m’a bizarrement blessé.
Mais ce n’était pas fini. Quelques semaines plus tard, alors que j’assistais à une grande conférence de programmation, ce recruteur m’a envoyé un e-mail disant qu’ils y étaient eux aussi, me proposant de dîner ensemble et me demandant si j’étais éventuellement prêt à relancer le processus d’entretien.
Comme ils payaient, je suis allé au dîner, et j’ai eu des échanges agréables avec plusieurs ingénieurs de l’entreprise. Mais je trouvais étrange que relancer le processus soit présenté comme une option alors que ce n’était pas moi qui l’avais interrompu, et que cela semble devenir ma responsabilité.
J’ai l’impression qu’il faudrait une page largement lue, une sorte de guide de l’environnement IT en entreprise, pour se préparer à ce type d’interactions.
Il ne s’agit pas de défendre ce qui s’y passe, mais beaucoup de gens connaissent mal la réalité.
Les retards existent, qu’ils soient internes ou externes. Perdre une journée pour obtenir des accès est normal et prévisible.
Les processus prennent du retard, et on devient un petit rouage dans un système qui observe des indicateurs globaux plutôt que la réussite ou l’échec d’une personne.
Beaucoup d’endroits ont une politique consistant à ne pas donner de feedback de manière uniforme. Le risque potentiel est un procès, et le gain potentiel est nul.
La communication est souvent mauvaise, et il arrive que les tests techniques changent ou disparaissent.
Un tel guide pourrait aider à aligner les attentes, et aussi à filtrer les personnes qui ne veulent pas supporter ce quotidien.
Pour y parvenir dans ce délai, j’ai dû obtenir des accès en passant par des personnes extérieures au processus et par des canaux de communication tiers.
Dans le travail quotidien, on peut attendre, donc les retards peuvent être normaux ; mais un processus de recrutement ne devrait pas affecter mon travail quotidien. C’est une grosse différence.
Quant aux politiques de non-feedback, comme je suis dans l’UE et soumis au RGPD, je peux demander tous les détails et toutes les notes internes me concernant.
Au final, tout ce qu’ils obtiennent, c’est une impression de manque de professionnalisme, et le sentiment que tout ce processus ressemble moins à un recrutement légitime qu’à du conseil sur leur processus de recrutement.
Aligner les attentes et filtrer les gens peut être acceptable, mais si je leur dis que j’ai besoin de plus de temps, je doute fortement que le même standard leur soit appliqué. C’est ainsi que naît un avantage injuste.
Avec le recul, j’aurais peut-être dû ne rien faire, ne pas relancer pour obtenir les accès, attendre simplement jusqu’au week-end que leur machine fonctionne, puis encaisser seulement l’indemnité. J’aurais probablement moins pris les choses à cœur.