Licence CC BY

Comment faire fuir les bons candidats : un cas d'école

Où il est question de recrutement, de communication et de leçons à retenir

Dernière mise à jour :
Auteur :
Catégories :
Temps de lecture estimé : 32 minutes

Salut !

Aujourd’hui, je vais vous raconter une mésaventure que j’ai vécue cette semaine. Cela sera une très belle occasion de faire un petit point et prendre du recul sur le recrutement des ingénieurs en informatique, à travers un exemple qui serait drôle s’il était isolé.

En ce moment, je passe des entretiens de recrutement à droite à gauche, à la recherche d’un job de rêve. Après tout, quand on est ingénieur, il est sain de se frotter au marché de l’emploi pour voir ce qu’il a à offrir, s’auto-évaluer et éventuellement découvrir de belles opportunités.

Étant donné que j’ai la chance d’être dans un secteur (ingénierie informatique, développement — notamment en Python) où l’on s’arrache les bons profils et où il n’est pas rare de crouler sous les demandes de contact, j’ai choisi des critères extrêmement sélectifs, en ne m’ouvrant qu’à des niches d’activité : si je dois changer de job, je veux que ce soit dans un domaine qui vend du rêve, comme celui de la musique, du divertissement, des arts, ou du jeu vidéo.

Tout se passait parfaitement bien, jusqu’à ce que je sois contacté par l’entreprise X…

Les faits

L’entreprise X

X est une jeune start-up d’environ deux ans qui fournit un service web dans le domaine de la promotion musicale.

Je limite la description pour éviter que cette société soit reconnaissable. Mon but n’est absolument pas de leur causer du tort.

Pour développer et faire croître leur service, X recrute plusieurs profils, dont un ingénieur backend. Je note dès ici que le profil recherché est, selon leurs dires, celui d’un ingénieur expérimenté. D’ailleurs, l’équipe étant très jeune, ils se déclarent avides de recruter des gens chevronnés pour les aider à mettre en place et/ou améliorer leurs processus internes, car ils sont conscients que tout ceci est très nouveau pour eux, et désirent, bien sûr, évoluer dans la bonne direction.

La prise de contact

La semaine dernière, je reçois un mail, très bien rédigé (certes un peu générique), qui me présente l’entreprise X dans un langage "jeune et dynamique" : tutoiement, emojis et points d’exclamation sont de mise. Le mail se conclut sur une invitation à discuter rapidement au téléphone. Je réponds très vite : le domaine correspond, les postes et technos semblent convenir, ce que fait l’entreprise me parle. Le rendez-vous est pris.

Au téléphone, je tombe sur Machin1, cofondateur de X. Machin est jeune, il utilise un langage décomplexé, avec des réponses comme « Top ! » pour exprimer son approbation. Son discours est maîtrisé et bien huilé : il sait présenter son entreprise (« l’aventure » dans la parlance des jeunes pousses), il sait pourquoi il l’a créée, il sait où il veut l’emmener, il a l’air conscient des défis (les « challenges ») que X doit relever du point de vue humain et technique.

Je me présente à mon tour, lui brosse un résumé rapide de mon expérience en me concentrant sur les infos qui me semblent pertinentes dans son contexte. La discussion se conclut sur un match (dans la parlance moderne, on parle de match ou de fit quand les candidats et profils recherchés semblent bien correspondre).

Machin m’explique la suite du processus :

Top !

 Nous allons t’envoyer un challenge technique, qui servira de base à de futurs entretiens, nous permettra de te situer techniquement, et te permettra également de te rendre compte de ce que l’on attend chez X.

Par contre, nous en sommes au tout début de notre recrutement, donc le challenge n’est pas encore tout à fait fini, mais notre lead backend, Bidule, est en train de le finaliser, et ça sera prêt dans le courant de la semaine prochaine.

Machin, au téléphone

J’attire votre attention sur la terminologie : il est question d’un challenge technique. Intérieurement, je tique un petit peu, mais je lui réponds que ça me va.

« Top ! Merci beaucoup pour cet échange. À très bientôt. Salut ! ».

L’attente

Très correct, Machin m’envoie un mail juste après l’entretien téléphonique pour récapituler (débriefer dans le jargon) :

Hello [nohar],

C’était un plaisir de pouvoir échanger avec toi. Je reviens vers toi semaine prochaine avec un challenge technique qui est une base d’échange pour la suite.

Encore merci, À très vite, Best,

Machin, par mail

Fin de semaine dernière, une petite relance pour me rappeler qu’ils pensent à moi.

Hello [nohar],

J’espère que tu vas bien :) ! Un court mail d’update pour te dire que les tests techniques seront finalisés semaine prochaine ([Bidule] dans la boucle). On t’envoie ça au plus vite. Surtout n’hésite pas si tu as des questions d’ici là ! :)

Encore merci, Best,

Machin, par mail

J’accuse réception (« Bien noté, merci, à la semaine prochaine »).

Le week-end passe, puis finalement, Mardi, je reçois un nouveau mail et je commence à pénétrer dans la quatrième dimension :

Hello [nohar],

J’espère que tu vas bien ! :)

Le [X] challenge tech (Back & Ops) est finalisé. Le challenge est à faire en - de 4h sur une plage horaire de ton choix selon tes dispos. Il servira de base d’échange à un futur entretien avec [Bidule] sur la partie tech.

Est-ce que tu as un créneau de disponibilité dans la semaine sur une plage de ~4h (max) pour que je t’envoie le challenge au début et que tu nous le renvoies à la fin ?

Encore merci, Best,

Machin, par mail

QUATRE HEURES ?!

Ma réaction en lisant ce mail
Ma réaction en lisant ce mail

Je suis choqué, quelque chose ne tourne définitivement pas rond, mais j’y reviendrai plus bas. Je prends la décision de jouer le jeu. Je pose mon jeudi après-midi en RTT.

Mercredi soir, changement de dernière minute :

Hello [nohar],

J’espère que tu vas bien ! On a refait le point avec [Bidule] suite à notre appel et on a revu le test technique en conséquence.

On pense en effet également que 4h est un slot trop long. On a donc adapté le test en un test d’1h (plus concis et pertinent). Il s’agit comme mentionné au téléphone d’une première formalité qui est une super base d’échange pendant l’entretien à venir ! :)

N’hésite pas si tu as la moindre question!

Encore merci pour ta motivation, À très vite, Best,

Machin

Ce mail me plonge dans la confusion : il fait référence à un appel qui n’a jamais eu lieu. Je ne les ai pas eus au téléphone depuis la semaine dernière. Selon toute vraisemblance, il me confond avec un autre candidat qui s’était plaint…

Il est trop tard pour annuler mon congé, mais soit. Va pour un test d’une heure.

Le « challenge »

Le jour même, je reçois un mail avec en pièce jointe une archive au format TAR.

L’archive contient :

  • Un fichier docker-compose.yml,
  • Un répertoire testapp,
  • Un fichier README.md dans lequel le but du jeu est plus ou moins clairement défini : je dois réaliser un code qui passe les tests unitaires écrits dans testapp, commiter tout ça et le pousser dans un dépôt git.
  • … et c’est tout.

Le code de testapp contient des tests écrits avec pytest, qui interagissent avec une application dont l’URL est yourapp, et qui vérifient le fonctionnement de plusieurs appels.

  • Un Hello World,
  • Un appel qui est supposé inverser, et concaténer, une liste de chaînes de caractères, avec en commentaire l’instruction de ne pas utiliser un raccourcis syntaxique ou une builtin de Python,
  • Un appel nestedsum qui doit réaliser la somme des nombres compris dans une structure imbriquée, genre [1, [2, 3, [4, 5], 6]]].
  • Un appel qui est supposé associer une clé à une valeur dans une base Redis.
  • Un appel qui est supposé récupérer la valeur associée à une clé dans un Redis.
  • Un appel qui est supposé associer une clé à une valeur, si la clé n’existe pas déjà, dans un Redis, et retourner des codes d’erreur HTTP adaptés.

Comme proposé dans le mail, j’envoie un message pour clarifier et être sûr que j’ai bien compris que je suis censé :

  • Écrire à partir de zéro une application web,
  • La conteneuriser dans un Docker,
  • Adapter la configuration docker-compose,
  • Implémenter les appels correspondants dans l’application web,
  • Versionner tout ça,
  • Le pousser sur Github.

Au bout de trois quarts d’heure, un mail de Bidule.

Hello [nohar],

Effectivement, tu as tout compris !

Lis testapp et tu devrais avoir une idee de l’organisation attendue.

Bidule, par mail
"C'est très bien, very good !"
"C'est très bien, very good !"

Je respire un bon coup, et j’envoie finalement cette réponse.

Ok, désolé mais je préfère renoncer, et voici pourquoi.

Visiblement ce challenge sert à tester la capacité d’un développeur (junior) à comprendre le code qu’il lit et à passer des tests unitaires :

  • retourner "Hello World",
  • inverser une chaîne de caractères sans utiliser une builtin de python (je n’en vois absolument pas l’intérêt, mais soit, faisons une boucle for sur range(len(input), -1, -1))
  • calculer la somme d’une structure imbriquée (piège, la plupart des gens vont faire une fonction récursive au lieu de définir une stack explicite, ce qui est un anti-pattern en Python)
  • savoir faire des opérations de base (get/set) dans un Redis, et transformer une erreur en un code de retour HTTP approprié le cas échéant.
  • implémenter un "set if not exists" avec Redis.

Ce sont des opérations triviales, qui ne mobilisent aucune connaissance en algorithmique.

Le seul challenge réel, est de réaliser une configuration pour redis-compose et une micro-application (avec flask ou autre…), et créer un repo sur github en moins d’une heure de manière à se laisser assez de temps pour écrire du code : ce sont des opérations qu’on ne réalise qu’une seule fois par projet, et jamais dans l’urgence, et si jamais on rencontre un bug au niveau du docker compose, on finit par passer une heure à débugger docker et lire de la doc plutôt que s’attaquer au fond du sujet.

Le candidat doit donc savoir faire tourner et débugger docker-compose en prenant moins d’une heure, mais on n’attend de lui aucun skill en termes de développement (un peu d’algorithmique, estimation de complexité ?), d’architecture (comment distribuer une application ? faire de la réplication ? garantir la disponibilité des données ? comment équilibrer la charge entre serveurs ?), de conception (utiliser des patterns ?).

J’en déduis que je n’ai pas le profil recherché : de toute évidence, ce test est taillé pour un développeur junior, on est très loin de la valeur que je pourrais apporter à une toute jeune entreprise.

Sans rancune, mais je suis désormais convaincu que c’est un mismatch, et donc je préfère arrêter là pour que nous ne nous faisions pas perdre mutuellement notre temps.

Bonne continuation,

Ma réponse

Plus tard dans la journée, Machin me rappelle au téléphone. Dans son laïus, il m’explique que ce test était en fait un test de screening (on y renviendra plus bas).

Qu’à cela ne tienne, je conclus cet épisode en lui envoyant, par mail, deux exemples différents de stratégies de screening utilisées dans la vraie vie, de manière à « alimenter leur réflexion sur le recrutement », et je me promets intérieurement de ne plus jamais avoir affaire à cette entreprise.


  1. Il ne s’appelle pas comme ça en vrai, bien sûr. D’ailleurs, ce billet n’est pas une attaque personnelle : il faut voir y voir Machin comme une persona abstraite. La personne "réelle" derrière cette histoire a, depuis, appris de ses erreurs.

Un râteau passé à la loupe

Cette histoire (malheureusement vraie, malheureusement banale) illustre à peu près tout ce qu’il ne faut pas faire quand on est une « nouvelle startup innovante et disruptive ». Voici une analyse de ce qui ne tourne pas rond.

Le recrutement tech est un jeu de séduction… à double sens !

Dis-moi, Machin. Est-ce que ça te viendrait à l’esprit de te rendre à un premier rencard en sortant de la salle de sport, histoire de faire profiter ton date de l’odeur de ta transpiration sous tes belles fringues ?

… Non ? Sans blague !

La première chose à noter, c’est que dans le domaine des nouvelles technologies, les profils qualifiés ont l’embarras du choix. Nous ne sommes pas en chien lorsque nous cherchons un job. D’ailleurs en informatique, aujourd’hui, les candidats n’écument plus les annonces eux-mêmes : si un développeur compétent place son profil sur un medium de recherche d’emploi "classique" (comme Monster), il s’expose à un harcèlement téléphonique permanent, jusqu’à ce qu’il finisse par supprimer purement et simplement son CV.

Bref, si tu veux que quelqu’un vienne bosser pour toi dans ce domaine, et s’il est parfaitement logique de t’assurer que cette personne a le profil recherché, sache que ça va dans les deux sens, et tu as plutôt intérêt à lui donner envie. Il ne te suffit pas de déclarer « si tu es blonde, à forte poitrine, ça m’intéresse » pour pécho.

"Tournez ménages" (les Inconnus, 1990) était un sketch, PAS un tuto de recrutement !
"Tournez ménages" (les Inconnus, 1990) était un sketch, PAS un tuto de recrutement !

Et pourtant, Machin, c’est exactement ce que tu es en train de faire…

Prendre soin de son image

Alors certes, tu as un discours et un ton bien huilés pour présenter ta boîte et montrer que tu y crois. On sent que tu t’es bien préparé pour te présenter aux investisseurs et lever quelques millions d’euros, mais là je te parle de tes actes. Une fois que tu as eu un premier call avec un candidat, tu n’as encore rien accompli. Tu n’as rien sécurisé : il t’a donné 30 minutes de son temps, c’est tout, mais il a encore tout le loisir de changer d’avis et il a une vue en premier plan sur tout ce qu’il y a derrière et tout autour de ton discours.

  • En m’annonçant que « le challenge n’est pas encore prêt », tu me montres directement que tu abordes ton recrutement à l’arrache : les tests, ça s’anticipe, et ça se crée en même temps que la fiche du poste que tu cherches à pourvoir,
  • En changeant au dernier moment la durée de quatre à une heure, tu crois que tu me montres que tu sais te remettre en question, mais tu me hurles qu’en fait, tu n’avais même pas réfléchi à la façon dont tu allais tester tes candidats et tu me confirmes que tu y vas à l’arrache : tu commences par proposer un resto chic, et tu changes la veille pour le lendemain en faveur d’un MacDo,
  • En me confondant par mail avec un autre candidat, tu me montres que tu te contentes de copier-coller tes communications sans même les relire, signe que tu es probablement en train de pêcher au chalut, pas à la ligne,
  • Et je ne parle pas encore du contenu du test…

Comprendre et respecter les candidats

Peut-être que les jeunes ingénieurs sortis d’école sont moins regardants que moi sur ce sujet, mais sache qu’un ingénieur, c’est quelqu’un de rigoureux, dont on attend qu’il fasse preuve de logique, de soin, de cohérence et de précision et qui n’en attend pas moins de ses futurs collaborateurs.

  • Appeler le candidat 10 minutes en retard sans t’excuser, c’est lui manquer de respect.
  • Lui demander de mobiliser QUATRE HEURES avant même d’avoir rencontré qui que ce soit chez toi, et donc lui faire poser une demi-journée (ou bien le mobiliser entre 20h et minuit ?!) alors qu’il ne sait même pas encore s’il veut bosser avec toi, c’est lui manquer de respect.

    • Tu as une idée du nombre de processes que les candidats suivent en parallèle ?
    • Comment ils font si tout le monde fait comme toi ? Ils prennent une semaine de congés ?
  • Changer d’avis au dernier moment pour qu’il ait finalement posé sa demi-journée dans le vent, c’est lui manquer de respect

    • J’avais accepté le deal de 4h, même si tu réalises entre temps que c’est une connerie, assume-la jusqu’au bout !
  • Répondre avec un délai de trois quarts d’heure pendant un test d’une heure, c’est lui manquer de respect.

Tester un candidat, ça ne se fait pas à coups de truelle

Annoncer au début un challenge technique, puis conclure sur « c’était du screening », c’est absolument contradictoire… Mais au fait, tu connais la différence entre les deux ?

Ce que je visualise derrière les « Top ! » et les « Best, »
Ce que je visualise derrière les « Top ! » et les « Best, »

Eh bien pour commencer, ce sont deux choses contraires et complémentaires.

Le screening

Le screening, c’est le fait de trier le bon grain de l’ivraie, à savoir écrémer les candidats pour en éliminer le plus grand nombre, avec le moins d’efforts et d’investissement possible. En informatique, il est très facile d’éliminer un candidat sur deux critères :

  • Il ne connaît pas les technos, ou pas assez,
  • On ne pige rien à ses explications.

L’enjeu d’un bon screening est de :

  • prendre le moins de temps possible : un appel téléphonique de 30 minutes, ou encore un test écrit de 20 minutes suffisent largement, parce que le temps des candidats est aussi précieux que celui du recruteur,
  • rassurer les bons candidats sur la qualité de l’entreprise.
  • s’adapter au profil recherché
  • tester aussi bien les connaissances techniques que la qualité de l’expression.

Un test de screening trop facile n’est pas bon signe : si on ne se sent pas un tout petit peu challengé, alors on en ressort avec l’impression que la boîte n’est pas compétente. A contrario, un test avec des questions qui dépassent notre niveau aide à épicer les choses, à montrer que l’auteur du test est quelqu’un de bon, et que l’on aura probablement des choses à apprendre dans cette société.

Il est hors de question de demander à une personne de réaliser un programme pendant un screening. C’est beaucoup plus d’investissement qu’il n’y en a besoin, alors qu’il suffit de demander à la personne de nous expliquer rapidement la différence entre un thread et un processus pour en éliminer la moitié.

Toujours dans cette optique de séduction, avec l’expérience, on peut même réaliser ce screening sans même préparer un test ou des questions, mais simplement en demandant au candidat de nous parler de l’un de ses projets, creuser les questions techniques que l’on trouve intéressantes, et essayer de toucher la limite de ce à quoi il sait répondre, sur le ton de la conversation.

Les challenges techniques

Lorsqu’il ne nous reste plus que quelque candidats à départager sur le plan technique (je ne parle même pas de l’humain, mais ça devrait venir avant), on passe alors aux tests techniques plus poussés. En général, on préfère réaliser ces tests en face à face, devant un tableau, en soumettant le candidat à des problèmes plus corsés, mais il est également possible de lui faire faire ce test chez lui, en lui demandant de réaliser un programme, soit sur une durée courte (une heure), soit sur une durée illimitée (« fais-moi parvenir ton code dès que tu auras eu le temps de le finir, on se donne une deadline à telle date »).

Ici, l’enjeu "séduction" est encore plus fort qu’en screening : on veut vraiment que le candidat soit impliqué dans la résolution du problème, l’amuser, l’intéresser et le stimuler pour qu’il passe un bon moment.

Pour les profils de développeurs senior, il n’est pas rare de les confronter à des problématiques d’architecture système, en plus des questions d’algorithmique.

Tester ce qui est pertinent

Qu’il s’agisse de screening ou d’un test technique plus poussé : il faut faire extrêmement attention à ne tester que des compétences utiles, sous peine d’introduire un biais dans l’évaluation des candidats. Typiquement, quand Bidule s’attend à ce qu’on ait poussé un dépôt git ou réalisé une configuration pour docker-compose, il est irrémédiablement à côté de la plaque.

Comme je leur ai expliqué dans le mail, si un candidat n’a jamais touché à ces outils, on s’en fout ! Ce sont des choses qu’il peut acquérir en deux heures le jour où on en a besoin, et surtout, ce n’est clairement pas quelque chose que l’on est amené à faire sur une base quotidienne. A fortiori sur un test en temps limité, où l’outil peut boguer, ou encore ne pas être disponible sur l’ordinateur du candidat, ce qui résulterait en un faux négatif, à savoir un échec complètement indépendant de ses compétences.

D’ailleurs, sur un tel test, il est bon de fournir au minimum le boilerplate, c’est-à-dire qu’au lieu de demander au candidat de créer les bons fichiers, on les lui crée à l’avance et l’on place des instructions en commentaire là où son code est attendu. De cette façon on lui évite cette tâche fastidieuse et inintéressante, pour mieux lui laisser le temps de se concentrer sur l’essentiel du test.

Le test "parle" aux développeurs

En l’occurrence, ce que ce test m’a raconté (et que LinkedIn m’a confirmé), c’est que le fameux lead backend qui avait écrit ce test était inexpérimenté, et que comme tous les jeunes ingénieurs, il a cette propension à se gratter l’oreille droite avec le pied gauche, dans le but de "bien faire", car il n’a pas encore acquis cette leçon fondamentale : KISS.

Évidemment, Machin m’a pourtant assuré au téléphone que le test permettait d’écrémer « plus de 50% des candidats »1, sauf que ce dont il ne se rend probablement pas compte, c’est que même si c’était vrai, ce n’est pas des « 50% les plus mauvais » qu’il s’agit, mais plutôt, probablement, des « 25% les plus mauvais, et des 25% qui trouvent son test complètement débile », faisant ainsi fuir les candidats de qualité.


  1. Je me demande d’ailleurs comment il a pu acquérir une stat fiable sur un jour et demie (mercredi et jeudi). En fait non, je ne me le demande pas, je SAIS qu’il m’a bullshité.

Épilogue : une erreur de jeunesse

Depuis la publication de ce billet, j’ai poursuivi mes échanges avec la personne réelle derrière le personnage de "Machin", car je souhaitais donner une fin positive à cette histoire : pour être tout à fait juste, je me dois de noter que le seul réel tort de cette entreprise est d’avoir péché par jeunesse, car ceci est leur toute première campagne de recrutement.

Dans notre échange, après que je leur ai expliqué tout ce que je viens de dire, Machin s’est excusé, et a corrigé le cap. Il a notamment :

  • Changé complètement son processus de recrutement,
  • Revu à la baisse l’expérience du profil recherché, parce qu’il pouvait difficilement savoir, a priori, que 10 ans d’expérience étaient overkill (voire néfaste) dans son contexte.

Ce phénomène est assez rare, et est un signe suffisamment remarquable d’intelligence et de remise en question de sa part pour que je le mentionne ici.

Ce n’est, hélas, pas le cas de tout le monde…


Pour conclure, j’ai perdu une demi-journée pour rien. Mais ça encore, ce n’est pas grave.

Ce qui me révolte, en revanche, c’est que je vois de plus en plus de gens que je connais se faire piéger et traverser, au bout de quelques mois en poste, une cuisante situation d’échec au détriment de leur confiance en eux. Tout cela parce que ces boîtes recrutent n’importe comment.

Jeunes devs de ZdS, restez vigilents, et surtout prenez soin de votre amour-propre : ce genre de truc n’est ni normal, ni acceptable, même (et d’autant moins) pour un premier poste.

35 commentaires

Un test de screening trop facile n’est pas bon signe : si on ne se sent pas un tout petit peu challengé, alors on en ressort avec l’impression que la boîte n’est pas compétente. A contrario, un test avec des questions qui dépassent notre niveau aide à épicer les choses, à montrer que l’auteur du test est quelqu’un de bon, et que l’on aura probablement des choses à apprendre dans cette société.

Tout à fait, j’ajoute même que les entretiens que j’ai le plus apprécié ne sont pas ceux où j’ai su tout répondre correctement, mais ceux où justement j’ai fait des erreurs (ou que j’ignorais tout bonnement la réponse). Car avec le dialogue autour de ce problème permet d’avoir une discussion intéressante, découvrir un autre point de vue, être sûr que la personne qui fait l’entretien sait de quoi il parle. Et cerise sur le gâteau, si le recruteur donne finalement la bonne réponse, même en étant pas choisi, tu auras appris quelque chose.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+9 -0

C’est super intéressant comme retour !

Je m’interroge vraiment sur la pertinence de laisser un junior être lead dev (je déteste vraiment ces anglicismes mais je n’ai pas trouvé de traduction satisfaisante…) et recruter un senior…

« Nous sommes faits de l’étoffe dont sont tissés les vents. »

+0 -0

Merci pour ce billet, vraiment. C’est du pain béni pour un étudiant ou jeune diplôme.

il suffit de demander à la personne de nous expliquer rapidement la différence entre un thread et un processus pour en éliminer la moitié.

? T’es gentil Le test FizzBuzz filtre plus de la moitié des candidats. Ta question filtre bien plus de candidats tout en étant potentiellement plus pertinante.

ache.one                 🦹         👾                                🦊

+5 -0

? T’es gentil Le test FizzBuzz filtre plus de la moitié des candidats. Ta question filtre bien plus de candidats tout en étant potentiellement plus pertinante.

Ça me pique toujours un peu de curiosité de comprendre : comment 50% des développeurs sur le marché sont incapables de répondre à de telles exercices ou questions ?

Je n’ai jamais croisé de tels cas en réalité, du coup je me demande ce qu’'ils sont capables de faire dans un projet pour garder leur poste en fait.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+0 -0

Merci pour vos retours !

À vrai dire, même si ce billet me donne l’air si tranché, quand on est pris dans le mouvement et le jeu des processes de recrutement, on ne se rend pas toujours facilement compte de tout ça.

Il est tellement facile de se mettre en cause (se dire qu’on doit être de mauvaise humeur et que les gens en face n’ont rien fait de mal…), et tellement difficile de tracer une ligne dans le sable en disant : là, c’est ma zone de tolérance, si tu la dépasses, c’est que tu me prends pour une truite.

Ici, on est évidemment dans un cas extrême digne de vidéo gag1, mais quand on y fait attention, ce n’est pas si rare que ça de tomber sur des comportements abusifs de ce genre, de la part de gens à qui personne n’a encore jamais rien dit…

L’autre grosse difficulté, c’est de savoir comment réagir dans ce cas. Il n’est surtout pas question de leur rentrer dans la tronche, sans quoi on se place en défaut, et rien ne bouge : il faut y aller avec un peu de tact, être le plus factuel possible, porter une bonne combinaison anti-bullshit, et leur mettre, poliment mais fermement, le nez dans leur caca.

Si même les plus jeunes développeurs apprenaient à tracer cette limite et la défendre (c’est qu’un job, secouez encore un peu le bananier, il en tombera 3 autres, et quand bien même, si vous vous laissez avoir pendant le recrutement, en toute logique, ça ne s’arrangera pas une fois en poste), le monde du travail et du recrutement tech serait tellement plus sain… :)


  1. Je sais pas ce que j’ai avec les émissions des années 90 aujourd’hui…

Édité par nohar

I was a llama before it was cool

+4 -0

Ça me pique toujours un peu de curiosité de comprendre : comment 50% des développeurs sur le marché sont incapables de répondre à de telles exercices ou questions ?

Renault

Le dernier test que j’ai passé. 15min le test était tout aussi basique que le FizzBuzz. J’ai fais une faute (15min, 15 questions) et pourtant on m’a dit que j’avais un très bon résultat. Suivi de 30min de tests d’arithmétique assez compliqué (sans calculatrice 30 questions, ça veut dire faire les calculs en 1min, j’étais pas prêt).

Du coup, j’ai l’impression que beaucoup de postes d’ingénieur sont juste destinés à des ingénieurs généralistes qui n’ont aucune réelle expérience et donc que l’entreprise est prête à former.

ache.one                 🦹         👾                                🦊

+0 -0

Merci pour ce moment.

T’es gentil Le test FizzBuzz filtre plus de la moitié des candidats.

ache

Mais n’est en rien intéressant pour les candidats. L’exemple que montre nohar (ou d’autres questions techniques du même genre) a l’avantage de donner lieu a une discussion, dont le degré de précision dépendra de l’entreprise et du candidat, et avec de la chance apprendre 2–3 trucs au passage.

Sur un FizzBuzz, il n’y a rien d’autre à apprendre que des astuces pour réduire la taille du code.

Édité par entwanne

Sur un FizzBuzz, il n’y a rien d’autre à apprendre que des astuces pour réduire la taille du code.

Voire. Un recruteur m’a déjà montré un Fizzbuzz (ou autre exercice semblable) très compact, qui reposait sur des congruences pour gagner de la place. Le type s’est fait recaler pour code non lisible.

Cela dit, pour avoir enseigné à des étudiants et leur avoir fait passer des examens, je comprends tout à fait pourquoi le fizzbuzz permet d’écrémer une certaine quantité de candidats.

Édité par melepe

+1 -0

Évidemment, Machin m’a pourtant assuré au téléphone que le test permettait d’écrémer « plus de 50% des candidats »1, sauf que ce dont il ne se rend probablement pas compte, c’est que même si c’était vrai, ce n’est pas des « 50% les plus mauvais » qu’il s’agit, mais plutôt, probablement, des « 25% les plus mauvais, et des 25% qui trouvent son test complètement débile », faisant ainsi fuir les candidats de qualité.

J’ai eu une expérience similaire.

Un cabinet de recrutement que j’ai rencontré faisait faire un test de logique basique. Je suis quasiment sûr que cela fait partie de la prestation vendue au client 1. Le problème, c’est qu’ils ont l’air de faire ça de manière indiscriminée. Autrement dit, comme dans le cas que tu décris, ils arrivent à éliminer les gens avec qui QI trop bas, et les gens qui trouvent ça débile.

De ce que j’ai vu, ils sont passés pour des rigolos auprès :

  • d’une connaissance, qui a subit ce test de logique pour un poste de directeur très senior ;
  • d’un autre candidat, qui est reparti aussi sec à cause de ça (« j’ai pas de temps à perdre avec vos conneries, je m’en vais ») ;
  • de moi, mais pour une autre raison (demandez des choses bassement administratives avant même de parler du poste…).

Ils ont donc perdu des candidats en route, potentiellement bons pour l’entreprise… mais le client ne le sait pas.

Le cabinet n’est pas seul en tord sur le sujet, le client l’est aussi. Pour l’annonce à laquelle je répondais, l’entreprise ne savait pas vraiment ce qu’elle voulait recruter (ingénieur ou docteur, il faut choisir), à choisir un cabinet de recrutement minable (un autre cabinet mandaté par filiale de cette entreprise était à des années lumières de celui-ci).


  1. Imaginez quelque chose du genre : Nous vous proposons pour X k€ : un rendez-vous de travail pour comprendre vos besoins en détail, la rédaction de l’offre, la gestion des candidats, une sélection des 3 meilleurs pour entretien avec vous selon notre processus prouvé scientifiquement (test de personnalité, test de logique, …), pour vous assurer un recrutement rapide et adapté à votre besoin !

+2 -0

C’est super intéressant comme retour !

Je m’interroge vraiment sur la pertinence de laisser un junior être lead dev (je déteste vraiment ces anglicismes mais je n’ai pas trouvé de traduction satisfaisante…) et recruter un senior…

Ekron

Jeu de relations. Le lead dev en questions peut très bien être un copain de l’ecole, le premier tech' à avoir été embauché (junior probablement car pas cher) etc

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+5 -0

Les cabinets de recrutement ne font pas forcément mieux.

Je me rappelle de celui qui avait frappé à la porte du bureau et qui vendait une « prestation haut de gamme, on fait même passer des entretiens techniques poussés aux candidats, à la fin vous n’avez plus qu’à signer le contrat ». Oh. Et sur quel type de techno vous recrutez ?

« Tout l’écosystème point net, en particulier cé dièze ».

Hmmm… le gars qui fait passer des « entretiens techniques poussés » sur une techno dont il ne sait pas prononcer le nom, personnellement je vais m’abstenir (et c’était pas la seule incohérence dans son discours).

Sinon, il y a les « tests de compétences » Linkedin (j’en validé sur des domaines que je ne maîtrise pas du tout…)

Sinon, il y a les « tests de compétences » Linkedin (j’en validé sur des domaines que je ne maîtrise pas du tout…)

Ah oui, toi aussi t’es un expert en JSON et git ? :D

I was a llama before it was cool

+4 -0

J’ai une petite réserve sur le test de screening

Un test de screening trop facile n’est pas bon signe : si on ne se sent pas un tout petit peu challengé, alors on en ressort avec l’impression que la boîte n’est pas compétente. A contrario, un test avec des questions qui dépassent notre niveau aide à épicer les choses, à montrer que l’auteur du test est quelqu’un de bon, et que l’on aura probablement des choses à apprendre dans cette société.

Un test de screening doit être facile, parce qu’il ne peut tester qu’une base commune qu’on attend de n’importe quel candidat. Pour un senior, on attend une expérience poussée sur des problèmes techniques complexes qu’on n’a à priori jamais eu. Ca se voit en entretien, pas avec un test générique. Du coup, comme le test est basique, il ne devrait effectivement pas s’éterniser. 30 à 60mn semble raisonnable. Mais le fait que le test de screening soit élégant et fasse réfléchir, c’est pas quelque chose que j’attends sur des postes seniors.

+2 -0

Je pense que je devrais préciser ma pensée : à mes yeux, un test est une communication à double sens.

Quand je reçois un test de screening, le candidat en moi va forcément chercher des indices sur les gens avec qui il est en concurrence, d’autant plus s’il a déjà été à la place du recruteur. Si le test est complètement pété, automatiquement, je vais penser : « OK, le process va être long, parce qu’il n’y a vraiment que les "fonds de tiroir" qui vont échouer. Ça veut dire qu’après cette étape, je n’aurai encore marqué aucun point. ».

J’ai en tête un test de screening en Python tout bonnement excellent que j’avais passé il y a quelques années, et qui consistait en un petit questionnaire d’une vingtaine de minutes :

  • 10 questions, pour lesquelles, automatiquement, "on sait ou on ne sait pas".
  • Les questions sont à niveau de connaissances de Python variable : on va de "qu’affiche cette ligne de code" à "comment pourrait-on optimiser cette fonction ?"

Pour avoir vu les deux faces de ce test (candidat, puis recruteur), je l’ai trouvé parfait.

Du point de vue "candidat", je me suis dit "okay, le type qui a écrit ce test connait Python au moins aussi bien que moi", et ça s’est confirmé quand on s’est vus en entretiens (on savait, sans rien avoir à dire, qu’on discutait de pair à pair, et j’ai su par la suite qu’il était impatient de me rencontrer suite au screening).

Plus tard, quand j’ai moi-même été amené à screener des candidats via ce test :

  • Un candidat n’était pas obligé d’avoir 10/10 pour passer le test, parce qu’au pire, on avait d’autres postes ouverts qui requéraient moins d’expertise, et on pouvait le réorienter vers ceux-ci quand on sentait que la personne manquait juste du petit plus qu’il pourrait acquérir chez nous.
  • Pour les candidats qui avaient 10/10, on levait un flag expert, qui nous permettait de sélectionner, pour la suite du processus, un challenge technique beaucoup plus exigeant.

Simple, super-rapide, efficace : au premier coup d’oeil, le test de screening avait déjà réussi à verrouiller ma candidature, car en l’ayant passé, j’étais déjà prêt à subir un process de 2 mois pour aller chez eux.

Édité par nohar

I was a llama before it was cool

+3 -0

Est-ce que ça te viendrait à l’esprit de te rendre à un premier rencard en sortant de la salle de sport, histoire de faire profiter ton date de l’odeur de ta transpiration sous tes belles fringues ?

Tu sais il y en a qui trouvent l’odeur de tranpi excitante…

+1 -0

Est-ce que ça te viendrait à l’esprit de te rendre à un premier rencard en sortant de la salle de sport, histoire de faire profiter ton date de l’odeur de ta transpiration sous tes belles fringues ?

Tu sais il y en a qui trouvent l’odeur de tranpi excitante…

manus

Trop d’informations, trop tôt. :D

I was a llama before it was cool

+5 -0

Félicitations nono, ton retour d’expérience a fait du bruit. :D

« et quand bien même, si vous vous laissez avoir pendant le recrutement, en toute logique, ça ne s’arrangera pas une fois en poste »

C’était peut-être donc ça en ce qui me concerne… Mais quand tu te fais jeter par les bonnes personnes et accepter par les « mauvaises » personnes… Devrais-je en conclure que je suis mauvais ?

Plus sérieusement, pour rebondir un petit peu sur ce qu’a dit Ache :

? T’es gentil Le test FizzBuzz filtre plus de la moitié des candidats. Ta question filtre bien plus de candidats tout en étant potentiellement plus pertinante.

Honnêtement, que ce soit « plus de la moitié des candidats » ou non… Cela peut vouloir dire qu’une société qui ne propose pas de FizzBuzz en entretien – et il y en a beaucoup – laisse passer, potentiellement, l’autre moitié des candidats. Et cette autre moitié se retrouve à proposer des tests techniques à son tour, sans doute à coup de docker compose et consort (comment ça, je suis mauvaise langue ?).

On se retrouverait donc en toute logique avec un système pervers qui s’entretient lui-même (tiens, ça me rappelle un ouvrage d’un certain M. Debord, mais ça, c’est une tout autre histoire).

Quelque part ça rassure et je peux me dire que sur tous mes derniers échecs, le problème ne venait pas de moi. D’autre part je me dis que le salariat c’est vraiment pas simple, même si je connais des personnes tout à fait respectables qui y trouvent leur compte. C’est pour ça que le doute point en moi.

En tout cas merci beaucoup pour ta tribune. Je terminerai sur cette question : « quand tu vas au cinéma, est-ce que tu préfères aller voir les films d’aventure, ou les comédies ? Et surtout aprè

Édité par Ge0

C’était peut-être donc ça en ce qui me concerne… Mais quand tu te fais jeter par les bonnes personnes et accepter par les « mauvaises » personnes… Devrais-je en conclure que je suis mauvais ?

C’est jamais aussi simple.

Les problèmes de recrutement expliquent une bonne partie des échecs pro, mais ça ne veut pas dire que tous les échecs pros sont dûs uniquement à des problèmes de recrutement. Il n’existe pas de spectre absolu entre "bon" et "mauvais". Même le titre de ce billet (les "bons" candidats) est une simplification.

Dès lors qu’il s’agit d’humains, tu peux être sûr que chaque problème est complexe et résulte d’un faisceau de causes. Derrière chaque situation d’échec, il peut y avoir des causes aussi bien intrinsèques (le job, l’équipe, les gens ne correspondent pas), qu’extrinsèques (par exemple, la personne traverse une passe difficile dans sa vie perso, ou une dépression, et ça finit par affecter son travail). Par contre, un recrutement foireux ne fait qu’exacerber les choses.

Honnêtement, que ce soit « plus de la moitié des candidats » ou non… Cela peut vouloir dire qu’une société qui ne propose pas de FizzBuzz en entretien – et il y en a beaucoup – laisse passer, potentiellement, l’autre moitié des candidats. Et cette autre moitié se retrouve à proposer des tests techniques à son tour, sans doute à coup de docker compose et consort (comment ça, je suis mauvaise langue ?).

Attention tu simplifies beaucoup trop : je n’ai jamais fait passer de FizzBuzz en entretien, mais pourtant, j’ai toujours été heureux des gens que j’ai recrutés dans mon équipe (je n’ai jamais estimé avoir recruté les mauvaises personnes).

Édité par nohar

I was a llama before it was cool

+0 -0

Ok.

Maintenant il faut quand même éviter d’y voir un "système".

Comme je le mentionne dans l’épilogue (rajouté ce week-end), le but n’est pas de tracer une limite entre les bonnes et les mauvaises entreprises1 : typiquement, dans le cadre de cette histoire, je suis tombé sur des gens qui ont eu l’intelligence de se remettre en question (d’autant plus qu’ils sont jeunes, d’autant plus qu’ils sont à un tournant crucial de la vie de leur boîte). Le but, c’est réellement que tout le monde devienne bon (ou arrête d’être mauvais) !

L’enjeu réel, à mes yeux, est dans le dépassement de cette situation un peu absurde et malsaine que l’on semble tous (recruteurs et candidats) accepter. Ce ne sont pas "ces boîtes" qui ne devraient pas exister, mais les pratiques, et les effets pervers qui découlent de la mécompréhension des candidats, du recrutement et/ou de ses enjeux.

PS : Et encore. Ça c’est dans le domaine de l’ingénierie où nous sommes privilégiés. Il existe des secteurs beaucoup moins bien lotis que nous où certains recruteurs exercent une réelle violence sur les candidats.


  1. La différence entre une bonne et une mauvaise entreprise c’est que la mauvaise entreprise, elle t’envoie un test de screening, tu le passes les doigts dans le nez, alors que la bonne entreprise, elle t’envoie un test de screening… bon tu le passes les doigts dans le nez, mais c’est une bonne entreprise, quoi !

Édité par nohar

I was a llama before it was cool

+3 -0

Moi, ce qui me faisait fuir, c’est les gens qui ne me disaient pas clairement combien ils payaient (« gneugneu ça dépend du profil, de l’XP blabla »). Je refusais systématiquement de donner suite quand la question de l’argent n’était pas élucidée. Souvent, c’était des RH de boîtes déjà établies. On dirait qu’ils sont moins coincés pour parler d’argent, dans les startups.
Le mieux, c’était quand la plateforme de "matching" mentionnait directement le salaire prévu ou bien qu’elle permettait de fixer son seuil.

Édité par sgble

+0 -0

@Phigger : J’en suis conscient. On est très, loin, par exemple, de l’entretien collectif de 30 personnes en simultané, qui se conclut, après 15 minutes de délibération, avec le recruteur qui annonce « Bon, ceux que je vais lister maintenant, vous pouvez partir, on ne vous garde pas. », suivi de la litanie des noms et des gens qui prennent leurs affaires et s’en vont…

@sgble : Je pense que c’est culturel : il y a une sorte tabou autour de la rémunération. Et je suis d’accord avec toi, ça ne devrait pas parce que c’est évident que c’est un critère à prendre en considération.

PS : Comme plate-forme de matching, ChooseYourBoss affiche directement une fourchette de rémunération. D’ailleurs cette plate-forme se présente exactement comme un site de dating, ce qui renforce encore le parallèle avec la séduction que je fais dans ce billet.

Édité par nohar

I was a llama before it was cool

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte