- Met en avant l’inefficacité des take-home assignments dans les entretiens de développeur logiciel et le problème du temps gaspillé pour les candidats
- Raconte avoir subi, dans le processus de candidature chez Kagi Search, des exigences d’exercice excessivement larges et floues
- Décrit un manque de retours clairs du manager sur le plan d’exécution concret proposé, ainsi qu’une communication inefficace
- Explique avoir ressenti une injustice après avoir soumis un projet développé avec un grand soin, puis avoir été rejeté sans raison claire, avec des critères qui semblaient avoir changé
- Partage des pistes pour un meilleur processus de recrutement (par ex. revue de code en temps réel) et une réflexion critique sur les exigences excessives des entretiens avec exercice à réaliser
Introduction
- Un take-home assignment est une méthode d’évaluation utilisée dans les entretiens de développeur logiciel, où l’on donne un problème au candidat pour qu’il l’implémente en code et le soumette
- Ce billet s’appuie sur l’exercice réellement reçu lors d’une candidature chez Kagi Search, une entreprise que l’auteur pensait réputée, pour dénoncer le caractère déraisonnable de cette pratique et le gaspillage de temps pour les candidats
Candidature chez Kagi Search
- L’auteur a soumis son CV pour un poste de développeur backend chez Kagi Search
- Les exigences du poste étaient les suivantes
- Expérience dans la conception de systèmes backend
- Maîtrise du langage Go
- Expérience de mise à l’échelle et de maintenance de grands systèmes backend
- Capacité à collaborer avec des membres d’équipe comme les SRE
- Compréhension des technologies de conteneurisation comme Docker
Présentation de l’exercice d’entretien et exigences
- Après avoir franchi l’étape du dossier, l’auteur a reçu un e-mail présentant le take-home assignment
- Sujet de l’exercice : « implémenter un client e-mail minimal inspiré du terminal »
- Choix entre une application terminal ou une web app
- Fonctions de base d’affichage et d’envoi d’e-mails
- Liberté de choisir un backend e-mail fictif ou réel (IMAP/POP, etc.)
- Seule la gestion des messages en plaintext est requise, le rich text n’est pas nécessaire
- Livrables du projet : dépôt GitHub, version déployée, documentation d’installation incluse
- Manque de guide clair et ampleur du projet déjà importante
- L’auteur a malgré tout décidé de réaliser l’exercice, notamment à cause de la réputation de l’entreprise
Communication avec le manager
- Lorsqu’il a demandé des précisions sur le périmètre exact de l’exercice et les fonctionnalités additionnelles, il n’a reçu qu’une réponse vague : « ce que vous ajoutez dépend de vous »
- Avant d’investir du temps et des efforts dans l’exercice, il a partagé un plan d’exécution concret (proposal) et demandé une réponse à ce sujet, mais le processus a continué sans retour particulier
Proposition et plan pour l’exercice
- Plan d’exécution :
- Web app basée sur Go
- Déploiement via AWS ECS Fargate avec SSL
- Intégration d’un service d’envoi d’e-mails (Postmark)
- Ajout de fonctions de connexion et d’authentification
- Envoi/réception d’e-mails et affichage dans l’UI
- Justification des choix techniques :
- Utiliser diverses technologies liées au rôle backend
- Construire un système concret via des outils d’Infrastructure as Code
- Aller au-delà d’une simple intégration d’API pour implémenter des fonctions proches d’un vrai service
- Principaux éléments implémentés :
- Pocketbase (backend/DB), TEMPL (template), Pulumi (IaC), Postmark (service e-mail)
- Implémentation de la pagination, de la connexion, etc.
- Stretch Goal : sauvegarde et restauration des données pour la fiabilité
- Conclusion : l’auteur avait fourni à l’avance des explications et justifications suffisantes, et s’attendait à une évaluation claire ainsi qu’à une réponse explicite
Réponse du manager et problème de communication
- Il n’a reçu qu’une courte réponse du type « proposition intéressante », sans examen concret
- Aucun retour sur la pertinence de la proposition ni sur d’éventuelles améliorations demandées
- Du point de vue du candidat, cela a été ressenti comme un manque de respect pour le temps investi et les efforts fournis
Réalisation du projet
- L’auteur a implémenté l’ensemble des exigences données ainsi que les points proposés, en y consacrant une semaine complète à temps plein
- Il a soumis une vidéo de démonstration du projet, le dépôt GitHub et une documentation détaillée
Notification de rejet et retour associé
- Après avoir reçu un e-mail de rejet automatisé, il a demandé un retour et obtenu la réponse suivante :
- « des candidatures plus solides ont été soumises », « le recrutement est très compétitif »
- Problèmes soulevés
- Si une solution simple était préférée, cela aurait pu être indiqué dès le départ
- Si la proposition était insuffisante, un retour pouvait être donné à ce moment-là
- Même après le rejet, l’annonce restait toujours publiée, ce qui lui a fait penser qu’il ne s’agissait pas seulement de concurrence mais aussi d’une exigence impliquant une consommation excessive de temps
- Les exigences se sont encore durcies après la soumission du projet, comme si la solution remise avait elle-même relevé le niveau attendu
Conclusion et réflexion critique
- Cette façon de faire est jugée déraisonnable pour de nombreux demandeurs d’emploi, avec des conséquences pouvant aller jusqu’à menacer concrètement leurs moyens de subsistance
- Le texte souligne la nécessité de refuser ou de contester les exigences excessives d’exercices non rémunérés
- Il existe, selon l’auteur, de meilleurs processus de recrutement, comme la revue de code en temps réel, pour remplacer les exercices de type projet
- Les capacités réelles à résoudre des problèmes de développement peuvent être observées via des revues de code asynchrones ou synchrones
- Le texte critique aussi l’écart entre les exercices de type Leetcode et les exigences du travail réel
- Il appelle à améliorer une culture de l’épuisement des candidats et de l’évaluation injuste
Propositions pour de meilleures procédures de recrutement
- Présente des alternatives, comme la revue de code en temps réel, pour évaluer plus utilement les compétences des développeurs
- Défend la nécessité d’évoluer d’un modèle centré sur les puzzles algorithmiques chronométrés vers une évaluation davantage fondée sur les compétences réelles et la capacité à résoudre des problèmes
1 commentaires
Avis sur Hacker News
Je reconnais les compétences du candidat et sa passion pour le travail. Je voulais simplement apporter un autre point de vue.
« Développer un client mail inspiré du terminal et le faire alpha-tester par des clients » est une demande raisonnable pour un ingénieur de startup en phase initiale. Même s’il y a d’autres spécifications, une grande partie repose sur le jugement de l’ingénieur. Le candidat semblait vouloir trop de certitudes.
Le fait que le candidat ait voulu savoir à l’avance quel retour Kagi donnerait après l’exercice n’est pas un bon signal. Il est impossible de fournir une réponse définitive dans ce contexte. Ils évaluent probablement des centaines, voire des milliers de candidatures.
S’il n’y avait vraiment pas besoin de clarifier les exigences, autant demander de « deviner un nombre entre 1 et 10 » et éliminer ceux qui choisissent mal.
Je ne suis pas d’accord avec le fait de rejeter quelqu’un parce qu’il a trop soigné l’exercice et livré quelque chose de trop abouti.
En réalité, ce type d’exercice ambigu n’est qu’une autre manière de sélectionner le « fit culturel ».
La culture du « code d’abord, feedback après » a été l’expérience la plus nocive de ma carrière. Ce candidat a suivi des pratiques logicielles modernes. (Je recrute dans une entreprise qui compte plus de 1 000 ingénieurs.)
Lors de ma dernière recherche d’emploi, j’ai moi aussi été rejeté après un take-home très vaste sans savoir quelle partie servait réellement de critère d’évaluation. Depuis, j’ai développé une forte aversion pour ce type d’exercice.
Je pense que l’entreprise aurait mieux fait de mettre fin à l’exercice à ce moment-là plutôt que de laisser le candidat perdre son temps.
Il manque même les fonctions mail les plus basiques (ouvrir un mail, etc.), et alors qu’il s’agissait d’un poste backend, il s’est appuyé en pratique sur des produits externes comme postmark et turso ; on voit aussi l’absence de fonctionnalités de base (formatage en texte brut, affichage, dossiers, etc.).
Il y a bien des éléments annexes comme une page d’administration ou la connexion, mais il manquait même des structures de données minimales comme une map des en-têtes de mails.
Il est peut-être bon ingénieur, mais j’estime qu’il ne convenait pas à ce poste.
J’ai aussi trouvé la proposition take-home très inhabituelle.
En relisant l’annonce initiale, il était bien indiqué « client mail minimal inspiré du terminal » avec des références comme aerc, mutt et himalaya. C’est un échec manifeste dans l’interprétation des exigences.
Il fallait un client mail en terminal ou en web app, avec les fonctions de base, et j’estime que cela a bien été rempli.
La partie demandant de s’inspirer d’outils orientés terminal reste subjective. Pour un poste backend, je pense aussi qu’accorder trop d’attention à l’UI peut être inefficace.
Un feedback pourrait au moins aider à progresser, mais même cela est souvent difficile à obtenir en pratique.
C’est pour cela que je deviens sceptique vis-à-vis des take-home. Candidats et recruteurs doivent tous deux respecter le temps de l’autre.
Deux à trois heures suffisent largement pour évaluer un candidat. S’il y avait eu une limite de temps, le candidat aurait pu proposer une solution adaptée à cette contrainte, et ce que voulait l’entreprise aurait été plus clair.
L’entreprise doit aussi indiquer clairement si « n’importe quelle réponse est acceptable » ou si elle « attend la meilleure réponse possible ».
L’intention d’un take-home peut varier : réussir un test, couvrir une mission, qualité du code, etc., et cela peut dérouter le candidat.
Il risque surtout d’écarter des personnes occupées et sans temps libre.
Dans notre entreprise, on donne simplement un petit problème ETL avec une limite de 4 heures.
On laisse entendre que ce n’est pas grave si tout n’est pas terminé, puis on fait un suivi avec revue de code et questions.
C’est dans cette réunion de suivi qu’on peut vraiment évaluer les compétences.
Contrairement à un exercice sur site, où l’unité de temps est la même pour tous, un take-home peut désavantager certains à cause de répartitions de temps très différentes.
Dans ce cas, autant faire une heure de code sur site. Le candidat et l’intervieweur y consacrent le même temps, ce qui permet de respecter la valeur du temps de chacun.
Dans la vidéo de démo, on ne voit qu’une web app assez classique. Il était explicitement demandé de s’inspirer de clients mail terminal existants comme aerc, mutt et himalaya.
Je me demande si j’ai raté quelque chose.
Comme l’UX propre aux clients terminal est un domaine où il n’existe pas encore de « bonne réponse », il est très probable que ce point ait justement servi de critère d’évaluation.
Je pense que si on demande un exercice, il doit obligatoirement être suivi d’un entretien de suivi.
J’utilisais déjà Kagi en payant, mais avec cette histoire j’envisage de fermer mon compte.
Si l’entreprise n’a même pas le temps d’échanger avec le candidat, elle ne devrait pas demander un exercice dès le départ.
Une fois la revue faite, je pense qu’on a droit à un retour.
Mais en pratique, quand il faut choisir une seule personne parmi des dizaines de très bons candidats, un refus ne signifie pas forcément « compétences insuffisantes ».
D’un point de vue juridique aussi, la réponse officielle à « pourquoi avoir choisi A et rejeté B ? » finit souvent par se réduire à du pinaillage.
Plusieurs entreprises gèrent bien mieux cet aspect.
Quand l’incompréhension des exigences est aussi importante, il est possible que la discussion soit tout simplement abandonnée.
L’entreprise voulait quelqu’un d’autonome, capable de se fixer lui-même des objectifs.
L’ambiguïté servait à voir si le candidat savait explorer plusieurs pistes pour construire une réponse.
Comme ce profil ne convient pas à toutes les entreprises orientées prototype, certains candidats auraient sans doute réfléchi 10 minutes puis produit le maximum en 60 minutes.
Or, cette capacité à poser des questions est une qualité très importante chez un développeur. C’est pourquoi on en attend davantage de ce mode de recrutement, et on ne peut qu’être déçu.
En réalité, c’est souvent l’explication qui est ambiguë.
Un excellent enseignant fait en sorte qu’un maximum de personnes comprennent. S’il y a beaucoup d’élèves perdus, le problème vient de celui qui a posé l’exercice.
Les étudiants à l’université ne devraient pas avoir à résoudre des koans comme des moines zen.
Avant, c’était Vlad qui évaluait directement les candidats, et les exercices se passaient de cette manière.
Avec la croissance de l’entreprise, on dirait que ce sont maintenant d’autres personnes qui les évaluent.
Vlad a un tempérament très HN et aime travailler avec des candidats qu’il trouve « cool ».
Par exemple, si quelqu’un rédige un long document de design en disant « on utilisera Galactor et le projet est prêt pour un flop », cela produit exactement l’effet inverse.
Quand il est demandé quelque chose « inspiré du terminal », on s’attend souvent à des détails réellement présents dans une app terminal, comme tous les raccourcis clavier.
On peut débattre de la qualité de ce filtre, mais si on comprend ce contexte et qu’on a les compétences pour le franchir, l’exercice paraîtra facile.
J’aimerais que Kagi communique mieux ce contexte. C’est dommage que du temps ait été perdu, mais j’espère que l’auteur trouvera une entreprise qui correspond davantage à sa manière d’être.
Une équipe sans diversité peut se heurter tous à la même limite et finir par stagner.
Ce phénomène est particulièrement fréquent dans les startups, et je pense qu’il est lié au fait que 9 sur 10 échouent.
Je trouve injuste de noter un exercice sans critères clairs.
Au fond, cela revient à une consigne implicite du type « devine la réponse dans ma tête ».
Cela donne l’impression d’un manque d’égards envers les gens.
Dans une culture pareille, on ne sait pas si chacun devait faire sa petite enquête en sous-marin pour le découvrir.
Il vaudrait mieux que des candidats « pas cool » comme moi reçoivent aussi des signaux clairs et puissent rapidement se tourner vers d’autres entreprises.
À cause de ces insuffisances dans les détails, j’arrêterais ma revue là.
De la simple proposition de design à l’exercice d’implémentation, tout se faisait avec une limite de temps claire.
Au final je n’ai pas été retenu, et la raison exacte ne m’a pas été communiquée.
Il semble qu’il y avait énormément de candidats, mais cette expérience m’a tout de même marqué émotionnellement pendant longtemps. Je comprends ce que ressent l’OP.
Cela dit, si j’avais été le recruteur, j’aurais probablement aussi rejeté l’auteur.
Les startups veulent des gens capables de travailler vite et de façon pragmatique.
J’ai déjà eu un collègue qui passait plusieurs jours à s’isoler après avoir recueilli les avis autour de lui, puis découvrait que les exigences avaient déjà changé entre-temps, et cela n’a été bon pour personne.