Ceux qui en ont assez des entretiens façon LeetCode
(nelson.cloud)- Après avoir quitté Robinhood fin novembre 2023 pour des raisons de santé et traversé plusieurs processus de recrutement, l’auteur a eu le sentiment que les évaluations de type LeetCode ne correspondaient pas au vrai travail d’ingénierie logicielle
- Il estime que beaucoup d’entreprises répètent des entretiens similaires en suivant les méthodes des grandes entreprises technologiques comme Google, Facebook/Meta et Amazon
- Il critique le fait que, même si les ingénieurs disent ne pas avoir besoin de mémoriser des connaissances facilement recherchables, les entretiens les interrogent comme à un quiz sur des éléments difficiles à rappeler sur le moment
- Il a connu à la fois des réussites et des échecs dans ce type d’entretien, et considère que l’origine de son insatisfaction tient davantage à son expérience pratique passée qu’à ses échecs
- Il ajoute que toute entreprise cherchant un ingénieur ayant de l’expérience avec AWS, Kubernetes et Ruby on Rails, sans faire passer de quiz inutiles, peut le contacter
Là où les entretiens façon LeetCode ne correspondent pas au travail réel
- Après avoir quitté Robinhood fin novembre 2023 pour des raisons de santé, il a passé des entretiens avec plusieurs entreprises
- Les processus de recrutement n’ont pas abouti pour diverses raisons, mais il a surtout ressenti une fatigue face à la répétition des entretiens de style LeetCode
- Il estime que ce type d’entretien ne reflète pas suffisamment les véritables responsabilités en ingénierie logicielle
- Beaucoup d’entreprises semblent adopter cette méthode d’évaluation simplement parce qu’elle est utilisée par de grands groupes comme Google, Facebook/Meta et Amazon
Le conflit entre l’évaluation façon quiz et l’expérience terrain
- Certains ingénieurs disent au quotidien qu’il n’est pas nécessaire de mémoriser des connaissances que l’on peut facilement retrouver sur Google
- Pourtant, en entretien, on pose parfois des questions dont la réponse se trouve en cherchant, mais qu’il est difficile de retrouver instantanément, ce qu’il juge contradictoire
- Il n’a pas de solution évidente à ce problème, mais estime que le problème lui-même est clair
- Il a connu à la fois des réussites et des échecs dans ce type d’entretien, et explique que cette opinion est davantage influencée par son expérience professionnelle antérieure que par son taux d’échec
- Si une entreprise cherche un ingénieur logiciel ayant de l’expérience avec AWS, Kubernetes et Ruby on Rails et ne pratique pas les entretiens sous forme de quiz, elle peut le contacter
- Il propose aussi la lecture de Re-imagining Technical Interviews: Valuing Experience Over Exam Skills
1 commentaires
Réactions sur Hacker News
Je comprends la frustration, mais je pense qu’au final ce type d’entretien a quand même une utilité. Même sans être très bon, c’est suffisamment exploitable, et du point de vue de l’entreprise cela se défend, car cela produit généralement plus de faux négatifs que de faux positifs
Le coût de recaler quelqu’un d’intelligent est faible, alors que recruter la mauvaise personne coûte cher, car il faut parfois plusieurs mois pour s’en rendre compte, la licencier, puis relancer le recrutement. En revanche, pour les candidats, c’est un processus extrêmement pénible, et même d’excellents ingénieurs logiciels peuvent stresser, manquer quelque chose ou simplement tomber sur un mauvais jour et échouer plusieurs fois. Un entretien n’est pas une évaluation finale de la valeur d’une personne, juste un outil grossier, donc il faut simplement passer à autre chose
Les questions « pièges » sont stupides, mais il faut vérifier que le candidat maîtrise les bases tout en lui montrant aussi ce qu’est notre entreprise. Par exemple, demander « Est-ce que je peux modifier les arguments ? » ou dire « Je ne me souviens plus si
strleninclut l’octet nul, donc je vais ajouter 1 ; en temps normal, je vérifierais » sont de bons signaux. Le niveau des questions portait sur des choses fondamentales commeatoiou « mélanger un jeu de cartes », sans être aussi trivial que fizzbuzz. L’une de nos meilleures recrues a commis une erreur de base, mais quand je lui ai demandé si cela fonctionnerait bien comme prévu, il a répondu « Je suis vraiment un idiot » et a corrigé immédiatement. Le ton n’était peut-être pas idéal pour un entretien, mais nous y avons vu un très fort signal positif. À l’inverse, un candidat a soutenu jusqu’au bout qu’il était injuste de demander d’analyser une chaîne pour renvoyer un entier puisqu’il existait déjà une fonction de bibliothèque, alors qu’en pratique une partie de notre système tournait sur un environnement embarqué sans bibliothèqueJ’aimerais qu’on arrête d’imiter les horribles examens scolaires et universitaires qui testent d’abord la mémoire. Moi, j’ai beaucoup de mal à retrouver quelque chose à la volée quand j’en ai besoin, et je ne dois pas être le seul. Quand je faisais passer des entretiens pour des développeurs Android, je posais des questions pour observer leur manière de réfléchir, sans attendre que toutes les réponses soient exactes. Une fois vérifiée la compréhension de base d’Android, je leur demandais ensuite de créer une petite application chez eux
Au bout du compte, quand il faut absolument pourvoir un poste, plus il y a de faux négatifs, plus la probabilité de recruter un faux positif augmente. À l’extrême, s’il n’existait sur Terre qu’une seule personne adaptée au poste et qu’on la rejetait par faux négatif, il ne resterait plus qu’à recruter la mauvaise personne
Le problème n’est pas un manque d’intelligence, mais le fait qu’on peut très bien réussir des problèmes d’algorithmes sans être ingénieur logiciel, ou sans avoir les compétences requises pour le poste. Je travaille dans une équipe où beaucoup de recrutements ont été faits via des entretiens de type puzzle : tout le monde est intelligent, mais ce ne sont pas des ingénieurs logiciels, et la différence se voit énormément
Si quelqu’un les résout, il est bien plus probable qu’il n’ait pas redérivé une solution optimale sur le moment, mais qu’il ait déjà vu un problème identique ou similaire en enchaînant des exercices
Une fois, j’ai passé un entretien qui m’a plutôt plu, dans une banque. On m’a donné du code brouillon, écrit à la va-vite, mais pas délibérément obfusqué, et on m’a demandé de le refactorer du mieux possible
L’intervieweur était assis à côté de moi et nous avons échangé pendant tout le processus ; c’était en pratique très proche d’une séance de pair programming pilotée par le candidat. Après tous les entretiens LeetCode, c’était rafraîchissant. Bien sûr, cette banque connaissait exactement la stack qu’elle utilisait et avait moins besoin d’évaluer la capacité à apprendre de nouvelles technologies. Pour eux, il était plus important de voir si l’on savait produire du code maintenable, bien nommer les choses et communiquer avec ses collègues
Ce qui est intéressant, c’est qu’il m’est arrivé de voir des gens presque échouer aux questions de base, puis se révéler excellents en revue de code, au point de montrer une expertise profonde. L’entretien reste un assez mauvais outil pour montrer la capacité réelle d’une personne à faire son travail, mais si elle sait regarder un problème à la fois de manière large et détaillée, et coder correctement, alors j’ai tendance à considérer que c’est une réussite
Les entretiens façon LeetCode remplissent probablement deux fonctions. D’abord, ils servent à freiner les salaires et la mobilité des ingénieurs logiciel. S’il faut étudier un ou deux mois pour changer d’emploi, qui va partir facilement ?
Et si, par malchance, on tombe sur un intervieweur très préparé qui lâche une bombe de niveau LeetCode hard, il devient même difficile de recandidater dans cette entreprise pendant un an. Ensuite, cela sert à masquer les biais du processus en prétendant donner à tout le monde un objectif similaire et clair. À diplôme, sexe ou origine identiques, on peut poser la même question tout en donnant des indices, en fermant les yeux sur des erreurs de syntaxe et, même sans obtenir l’approche optimale, rendre un avis d’embauche positif au nom de la « communication ». Si quelqu’un ne plaît pas, il suffit de lui donner un problème difficile et de rester silencieux pendant tout l’entretien. Pour l’entreprise, c’est un bruit acceptable ; pour l’individu, c’est la perte d’une opportunité de rémunération de plusieurs centaines de milliers de dollars. J’ai passé des entretiens FAANG et j’ai aussi été intervieweur ; j’ai vu des personnes recrutées avec des exigences faibles, tout en voyant d’excellents ingénieurs rater leur chance à cause de questions absurdes sur les quadtrees ou la théorie des nombres
En partant du principe que les intervieweurs sont honnêtes, cette méthode donne à des candidats dont le CV n’affiche pas de noms prestigieux une occasion de montrer leur niveau. Une partie des opportunités que j’ai eues, sans diplôme d’informatique, n’aurait jamais existé sans les entretiens au tableau blanc. J’ai du mal à imaginer un moyen d’empêcher un intervieweur de détourner délibérément la procédure pour recruter un ami
Beaucoup d’entreprises ont des banques de questions conçues pour être équitables et avoir un certain lien avec des problèmes réels. Les entreprises où j’ai passé des entretiens étaient globalement comme ça ; même quand ce n’étaient pas exactement des problèmes LeetCode, cela restait au fond des exercices de code isolés, donc je les considère comme du style LeetCode. Dans les entreprises qui gèrent bien cette approche, les entretiens étaient plutôt corrects. Les bonnes entreprises et les bons intervieweurs regardent plus que le code final, et les évaluations de recrutement se font sur une échelle, ce qui réduit le côté binaire
En pratique, un simple fizzbuzz éliminait déjà 75 % des candidats. Beaucoup de gens n’arrivent pas à écrire du code sous pression, et certains essaient juste de survivre à coups de copier-coller. Cela ne veut pas dire qu’ils sont incapables de tout, mais ils avancent lentement, produisent des abstractions étranges et consomment énormément de temps avant d’obtenir un résultat exploitable. Et comme des centaines de milliers de dollars sont aussi en jeu pour eux, eux aussi répondent de la même manière
Du point de vue de l’entreprise, c’est rationnel. Elle veut des employés non distraits et capables de faire des heures supplémentaires
Il y a aujourd’hui beaucoup de critiques valables des pratiques de recrutement dans la tech, mais se plaindre qu’« on ne peut pas devenir extrêmement riche sans vendre son âme » n’est pas très convaincant
Ce qui compte pour sélectionner un ingénieur logiciel, ce n’est pas le savoir, mais la capacité à résoudre des problèmes et à construire un modèle mental du problème
Si le candidat n’a jamais vu le problème auparavant et que l’intervieweur comprend ce qu’il doit observer, l’entretien au tableau blanc est un bon moyen d’évaluer cela. Mais, comme avec la loi de Goodhart, dès qu’une mesure devient l’objectif, elle cesse d’être un bon indicateur. Même des personnes faibles en résolution de problèmes ou en modélisation veulent des postes de développeur très bien payés, alors elles bachotent LeetCode ; avec le temps, quand elles deviennent intervieweurs à leur tour, elles mènent les entretiens comme des tests de mémoire, comme on l’a fait avec elles. Malgré tout, compte tenu des contraintes de l’entreprise, de la nécessité de réduire le temps perdu par les candidats et de conserver une grille d’évaluation cohérente appréciée par les RH, je n’ai pas encore vu de meilleure méthode proposée, donc cela continuera probablement encore un moment
C’est bien plus proche du travail réel de développement logiciel. LeetCode est trop éloigné du travail concret, et ses résultats sont trop faiblement corrélés à l’adéquation réelle au poste
C’est un seau percé, mais les entreprises sont satisfaites de l’état actuel, et les développeurs continuent à bachoter LeetCode. Je ne pense pas que cela changera bientôt, mais heureusement je suis dans une situation où je peux refuser ce type d’entretien quand je cherche un nouveau poste
Un ami a déjà arrêté de parler en plein entretien technique, puis s’est levé et est parti. Des employés de l’entreprise lui ont couru après en disant « pourquoi vous faites ça, vous vous débrouillez bien ! », mais il a répondu qu’il était devenu trop déprimé et que cela ne l’intéressait plus
C’est triste pour un métier que la plupart des gens trouveraient pourtant amusant
Puis, vers le milieu de l’entretien, le tableau blanc est sorti et des collègues sont entrés pour me demander d’implémenter des choses basiques au feutre ; plus cela avançait, plus ils devenaient hostiles et impolis, au point que cela ressemblait à du harcèlement ritualisé. J’avais l’impression qu’on testait ma capacité à endurer l’humiliation et l’hostilité tout en produisant un résultat techniquement insignifiant. J’ai fini par arrêter l’entretien et dire : « J’ai vu comment vous travaillez, et j’ai décidé que je ne voulais pas travailler ici. Merci pour l’opportunité, et désolé de vous avoir fait perdre votre temps comme du mien. » Le CEO m’a poursuivi jusqu’au parking pour me demander pourquoi c’en était arrivé là, et il semblait vraiment choqué qu’un candidat puisse prendre sa décision pendant l’entretien. Les gens oublient que l’entretien d’embauche fonctionne dans les deux sens. Depuis ce jour, j’ai compris que j’avais le droit d’examiner tous les aspects d’une entreprise où je pourrais travailler, et que je n’avais pas à faire de compromis si je voyais quelque chose de négatif pendant le processus. Le lendemain, j’ai rencontré dans une entreprise concurrente des personnes qui sont encore aujourd’hui de bons amis et collègues, donc c’était la bonne décision. Ce métier est amusant, mais quand ce plaisir est récolté et exploité comme dans une ferme, cela ne vaut guère mieux qu’une autre forme d’asservissement
Quand j’ai dit : « Je crois que ce n’est pas mon jour aujourd’hui et j’aimerais arrêter l’entretien », ils ont alors fait pas mal d’efforts pour me faire rester jusqu’à la fin. À mon avis, si un candidat veut partir, il faut le laisser partir
Même cinq ans plus tard, je refuse encore ce genre d’entretien et je ne veux plus jamais revivre ce processus. J’ai subi le harcèlement et les moqueries de gens qui traitent les candidats comme dans un jeu de coups de pied d’une heure, et je n’ai plus aucune envie d’avoir affaire à eux.
Comme il y avait souvent des entretiens LeetCode sans préavis, j’ai clairement indiqué sur mes profils LinkedIn [1] et GitHub [2] ce qui est acceptable ou non. « J’ai pour politique personnelle de refuser toute forme de live coding en entretien ou de test de code en ligne, et je n’apprécie pas ni ne pratique la programmation compétitive. En revanche, j’accepte volontiers des exercices de code à faire hors ligne avec des objectifs et des délais raisonnables, ainsi que des discussions techniques approfondies sur l’architecture logicielle, la conception et les technologies associées. »
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
Cela dit, on entend dire que la triche est très répandue dans les entretiens basés sur des exercices, et je crains que cela ne fasse rapidement baisser le nombre d’employeurs prêts à les utiliser.
Pour jouer l’avocat du diable, LeetCode sert, dans le recrutement d’un contributeur individuel moyen, à filtrer l’un des deux profils suivants, voire les deux : est-ce quelqu’un de bosseur, c’est-à-dire capable d’étudier beaucoup de problèmes et d’en mémoriser puis répéter les solutions ? Ou est-ce quelqu’un d’intelligent, c’est-à-dire capable, même sans faire de LeetCode, de s’appuyer sur ses fondamentaux et de recomposer ses connaissances passées pour répondre à une nouvelle question ?
En l’absence de toute autre information, je dirais qu’une personne incapable de passer un problème LeetCode a plus de chances de n’être ni l’un ni l’autre. Pour un poste qui demande de coder, je pense qu’il faut au moins pouvoir résoudre un problème LeetCode facile à moyen, quitte à recevoir un léger guidage de l’intervieweur. En pratique, les entreprises réduisent le poids de LeetCode quand on vise des postes plus seniors ou plus spécialisés. Il y a aussi des corrections de bugs, de la conception de systèmes, des entretiens comportementaux, des exercices, des questions de culture générale et des questions liées au parcours. Dans les recrutements au-delà du niveau débutant, LeetCode n’est pas toute l’histoire. Ce n’est pas un outil magique pour sélectionner les meilleurs ingénieurs, juste un signal supplémentaire parmi d’autres pour un comité de recrutement.
Ça ne mesure pas la capacité d’ingénierie à mener un projet jusqu’au bout dans les limites du budget. Dans le meilleur des cas, c’est périphérique ; dans le pire, c’est un indicateur de substitution pour une discrimination par l’âge en faveur de personnes plus proches de 19 ans. C’est peut-être aussi pour ça que ce secteur a autant de mal à produire des logiciels de qualité. Une meilleure méthode consisterait à donner une situation d’échec réelle, comme un build cassé ou du code qui plante, et demander au candidat de la corriger. S’il peut explorer le système, diagnostiquer le défaut, en trouver la cause, proposer un patch et s’aligner sur le style de code et de commentaires, alors c’est quelqu’un dont on a réellement besoin. On peut lui donner une branche et un issue tracker ; il peut déjà y avoir une discussion sur le bug, voire un fichier de patch à appliquer manuellement dans les commentaires. Le patch peut introduire un nouveau bug, ou être un leurre touchant un problème similaire mais sans rapport. Cela peut être une régression d’un bug fermé sans test unitaire, ou avec un test que le candidat doit retrouver, ou encore un test lui-même obsolète et plein de bugs. Voilà le vrai travail. À la fin, il y a une énorme différence d’attitude entre dire « les tests unitaires étaient cassés » et dire « je suis passé à autre chose parce que je n’ai pas compris comment l’exécuter correctement », et un joueur d’équipe, c’est le second.
Donc on peut aussi se retrouver à recruter un candidat qui n’est pas particulièrement performant dans son poste actuel, mais qui a consacré toute son énergie restante à LeetCode.
Après seulement quelques semaines sur un projet, quelqu’un d’intelligent peut acquérir les intuitions réellement utiles. Les énigmes soudaines que lance LeetCode ressemblent davantage aux mots croisés des vieux magazines.
La seule raison pour laquelle c’est possible, c’est qu’on l’a déjà étudié auparavant.
En 2022, j’aurais été d’accord pour dire que LeetCode n’était pas un outil pour sélectionner les meilleurs ingénieurs, mais en 2024 on se fait de plus en plus éliminer même quand on trouve la bonne réponse, simplement parce qu’on n’a pas été assez rapide ou qu’on n’a pas réussi sans indice. Je ne suis pas un génie de LeetCode, j’ai trop de choses à étudier, et la part de LeetCode dans mes entretiens tourne autour de 20 %, donc je n’ai pas l’impression que ça se soit tant dégradé que ça par rapport à il y a deux ans. Ce sont surtout les attentes des entreprises qui ont explosé, avec cette ambiance où l’on veut acheter des profils à plus de 15 ans d’expérience au prix d’un salaire de 5 ans d’ancienneté.
Un aspect intéressant qu’on mentionne peu dans les entretiens à la LeetCode, c’est que c’est une sorte de bizutage intellectuel.
Il a été démontré à plusieurs reprises que plus un rite d’initiation est rude, plus il renforce l’engagement de ceux qui entrent dans le groupe.
Quand une entreprise capitaliste recrute des programmeurs, qu’est-ce qui vaut mieux : « des gens intelligents, similaires et convaincus d’avoir la bonne réponse », ou « un ensemble aléatoire de personnes compétentes » ? Si vous répondez le second, c’est idéaliste, et cette opinion n’a en pratique aucune importance. La nature vous remplacera par des gens plus intelligents et plus réalistes.
Lors de plusieurs entretiens récents, on a montré un exemple de code au candidat puis on lui a demandé de le relire. L’exemple contenait au moins un bug ou un problème par ligne
Ensuite venait un exercice de modélisation, généralement au tableau blanc. Il y avait aussi un petit exercice simple de type fizzbuzz pour voir si un junior pouvait réellement tenir un rôle de junior, et pour lancer la discussion sur des sujets comme la complexité en temps d’exécution ou l’agencement mémoire. Le tout se déroulait de façon très interactive selon la performance du candidat, avec pour but d’éliminer les imposteurs qui avaient réussi à passer le screening d’une manière ou d’une autre, et aussi de se faire une idée de l’adéquation culturelle
Je crée un problème sale, du genre fuseaux horaires ou validation de numéros de téléphone, et je mets un article Wikipédia comme spécification. Une fois terminé, je lui demande sa solution puis je fais une revue de code. Les meilleurs seniors utilisent simplement une bibliothèque. Les bons candidats le font eux-mêmes mais savent expliquer les compromis. Les juniors s’arrêtent dès que les tests passent
https://github.com/emilybache/GildedRose-Refactoring-Kata
Je laissais le candidat le faire dans le langage de son choix, et c’était un filtre très efficace
J’ai déjà passé en entretien des candidats développeurs qui semblaient très calés en théorie mais échouaient lamentablement dès qu’on leur demandait d’écrire du code. Ils ne parvenaient même pas à implémenter fizzbuzz, et un développeur Java senior n’était pas capable d’importer HashMap sans aller chercher l’info
C’est un peu comme en maths. Pour 562 * 1041, utiliser une calculatrice est normal, mais si quelqu’un sort une calculatrice pour savoir combien font 3 * 7, on peut douter de son niveau d’expertise. Beaucoup d’entreprises abusent des entretiens façon LeetCode, mais un entretien de live coding qui montre la manipulation de tableaux, le contrôle de flux et l’usage des structures de données de base permet de voir s’il y a une mémoire musculaire acquise par l’expérience. Si vous devez réviser des algorithmes de parcours de graphe pour réussir, c’est probablement devenu trop LeetCode
Mais un programme a besoin de plusieurs petits éléments de ce genre et, dans cette vision des choses, il faudrait tous les connaître par cœur. Pour 562 * 1041, on s’attend à ce que vous connaissiez le principe du calcul, autrement dit la méthode. Le résultat peut être faux, mais l’idée de la multiplication posée ne doit pas l’être. Dans ce contexte, oublier un simple 3 * 7 de la table de multiplication reste acceptable. Les programmeurs organisent le calcul, ils ne calculent pas eux-mêmes, c’est l’ordinateur qui le fait. Je suis d’accord sur le fait que pour les algorithmes de parcours de graphe, il suffit de savoir où trouver la solution, pas d’avoir toutes les solutions en tête
Dans quelle situation ces gens ont-ils dû écrire les imports eux-mêmes ? Ils n’avaient pas d’IDE ?
Je ne sais pas si c’était une satire des idées reçues des recruteurs