L’expérience d’un développeur recalé après un entretien technique basé sur un exercice chez Kagi Search
(bloggeroo.dev)- Lors du processus de recrutement backend de Kagi Search, un développeur a réalisé à temps plein pendant environ une semaine un client mail au style terminal, mais a été recalé après la remise sans entretien de suivi
- L’exercice laissait le choix entre une TUI ou une web app, la consultation et l’envoi d’e-mails de base, ainsi qu’un faux backend ou IMAP/POP/JMAP, ce qui obligeait le candidat à juger lui-même l’étendue de l’implémentation et les critères d’évaluation
- Le candidat avait envoyé à l’avance un plan détaillé incluant une web app Go, AWS ECS Fargate, SSL, Postmark, la connexion, Pulumi, Pocketbase, TEMPL, etc., mais Kagi n’a pas communiqué de critères précis de réussite
- Après le rejet, le retour demandé s’est limité à la réponse selon laquelle il y avait des candidatures « plus simples et plus solides », avec la précision qu’aucun feedback individuel n’est généralement fourni à cette étape
- Cette expérience montre que les entretiens fondés sur des exercices non rémunérés et les énigmes de code chronométrées peuvent tester davantage le temps disponible et la situation de vie des candidats que leurs véritables compétences d’ingénierie
Candidature et réception de l’exercice
- Le candidat a envoyé son CV pour un poste backend chez Kagi Search, dont le résumé mentionnait notamment les compétences suivantes
- expérience dans la construction de systèmes backend
- maîtrise de Go
- compréhension de l’extension et de la maintenance des systèmes backend
- capacité à collaborer avec les SRE et les autres membres de l’équipe
- compréhension des technologies de conteneurisation comme Docker
- Il a ensuite reçu de Kagi un e-mail lui demandant de compléter le Kagi Developer Assessment comme étape suivante
- l’URL de l’exercice a été envoyée via HackMD
- le message indiquait qu’après soumission, l’équipe examinerait le travail et, en cas de réussite, discuterait de l’approche et de la solution lors d’un entretien de suivi
Exigences de l’exercice et critères d’évaluation ouverts
- L’objectif de l’exercice était de créer un « client mail minimal avec une sensation de terminal »
- Les conditions d’implémentation restaient relativement ouvertes
- le client mail pouvait être réalisé sous forme de TUI terminal ou de web app
- des fonctions de base de consultation et d’envoi d’e-mails étaient requises
- il était possible d’utiliser un faux backend (base de données, mémoire, etc.) ou un vrai backend IMAP/POP/JMAP
- les messages en texte enrichi étaient exclus, seul le texte brut devait être géré
- Il était précisé que l’évaluation ne porterait pas seulement sur les compétences de code, mais aussi sur la capacité à gérer l’ambiguïté et les problèmes ouverts nécessaire pour des projets de R&D comme Kagi Labs
- Les livrables demandés étaient les suivants
- implémenter le projet d’une manière montrant ses compétences de développeur
- publier le projet terminé sur un dépôt GitHub et le déployer quelque part pour qu’il soit facile à tester
- documenter la procédure d’installation dans le README
Communication avec le recruteur
- Estimant les exigences trop larges, le candidat a envoyé des questions au recruteur
- Celui-ci a répondu qu’il y avait beaucoup de candidats, certains ne réalisant que le strict minimum tandis que d’autres ajoutaient des fonctionnalités supplémentaires, une excellente documentation, des explications sur leurs décisions, une démo déployée et même des pistes futures
- Lorsqu’il a demandé quels ajouts étaient particulièrement valorisés, le recruteur a répondu que « cela faisait justement partie de l’évaluation » et qu’il voulait voir quelles fonctionnalités supplémentaires les candidats imagineraient
- Le candidat a alors décidé d’écrire et d’envoyer en détail son plan d’implémentation complet avant de commencer à coder réellement
- il espérait qu’une proposition jugée convaincante le rapprocherait d’un entretien téléphonique ou d’une offre
- après coup, il a estimé que ses efforts pour aligner les attentes à l’avance n’avaient guère compté pour le recruteur
L’implémentation proposée par le candidat
- Le cœur de sa proposition était un client mail basé sur une web app Go
- déployée sur AWS
- avec ECS Fargate
- avec SSL/HTTPS
- intégrée à un fournisseur d’envoi d’e-mails
- avec authentification via un écran de connexion
- avec envoi d’e-mails par formulaire
- avec affichage des e-mails reçus dans l’interface
- Dans sa proposition, il indiquait une date de livraison fixée au dimanche 30 mars en fin de journée, soit deux jours ouvrés de plus que le délai de deux semaines à compter du premier e-mail
- Les choix techniques étaient les suivants
- backend Go : utilisation de Pocketbase et de TEMPL
- infrastructure as code : utilisation de Pulumi avec le SDK TypeScript
- fournisseur de service e-mail : utilisation de Postmark
- UI : pagination des e-mails envoyés et reçus, écran de connexion, et deux comptes fournis pour la démo
- Ces choix visaient surtout à montrer un périmètre large en lien avec le poste et l’évaluation
- bien qu’il s’agisse d’un poste backend, l’ajout d’un frontend web pouvait montrer l’étendue de ses compétences web
- la base de données restait pertinente pour un poste backend
- le déploiement sur AWS et l’infrastructure as code ouvraient la discussion sur l’IaC, Docker, le réseau et la résilience
- un service e-mail comme Postmark permettait de conserver les fonctionnalités tout en réduisant la complexité d’une intégration IMAP/POP
- Le candidat a demandé « quel type de réaction il pouvait attendre de Kagi si le projet était mené à bien », mais la réponse s’est bornée à dire que cela paraissait « très intéressant » et que l’équipe avait hâte de voir la soumission
Soumission et rejet
- Le candidat affirme avoir tout implémenté comme proposé, et que l’ensemble du travail lui a pris une semaine à temps plein
- La démo de l’application web a été publiée sur YouTube, et le code a été rendu public sur GitHub avec sa documentation
- Après avoir reçu un e-mail automatique de rejet, il a demandé un retour, et Kagi a répondu comme suit
- à cette étape, l’entreprise ne fournit généralement pas de feedback
- il existait des soumissions plus simples et plus solides, et l’équipe avait décidé de poursuivre avec ces candidats
- l’intérêt et le nombre de candidatures pour chaque poste sont très élevés, ce qui rend la sélection extrêmement compétitive
- il était invité à surveiller les futurs postes et à postuler de nouveau
Questions restées en suspens après le rejet
- Le candidat estime que si Kagi souhaitait une « solution plus simple », l’entreprise aurait pu le dire lorsqu’il avait envoyé sa proposition le 18 mars
- Il considère également que si la solution ne correspondait pas au poste, cela aurait pu être jugé dès l’étape de la proposition du 18 mars
- Il écrit qu’au 13 mai, un mois et demi après le rejet, l’offre d’emploi était toujours en ligne
- il reconnaît que l’entreprise peut chercher à pourvoir plusieurs rôles avec la même annonce
- mais il estime difficile d’y voir une compétition où « la place du gagnant était déjà prise »
- Il précise qu’au départ, la consigne indiquait qu’une démo déployée était appréciée mais non obligatoire, alors qu’après sa soumission, la consigne aurait été modifiée pour faire du déploiement une exigence stricte
Proposition d’une meilleure méthode de sélection
- Le candidat critique les exercices non rémunérés comme une charge importante pour les personnes en recherche d’emploi, en particulier celles dont l’épargne diminue
- Il se montre également critique envers les entretiens de type LeetCode
- il raconte avoir récemment travaillé sur un problème de « coin change » pour un poste autour de Clojure, et n’avoir eu le temps de faire passer qu’environ la moitié des tests en 50 minutes, faute de temps pour implémenter la partie backtracking
- En alternative, il propose une revue de code en direct
- selon lui, cela peut fonctionner en mode asynchrone comme synchrone
- cela permet de discuter verbalement de problèmes et de sujets issus de vrais projets logiciels
- cela met mieux en valeur les connaissances d’un ingénieur logiciel expérimenté
- Sans rejeter totalement le live coding, il estime que savoir résoudre un knapsack en 50 minutes est assez éloigné du travail quotidien d’ingénierie
- Il recommande de refuser les postes qui exigent ce type de travail non rémunéré, sauf en cas de situation vraiment désespérée
1 commentaires
Avis de Hacker News
Du point de vue d’un recruteur, je n’aime pas les épreuves sous forme de projet pour ces raisons. Elles font perdre du temps à tout le monde ; elles peuvent convenir comme toute dernière étape avant l’embauche, mais sont inadaptées comme filtre
Cela dit, ses compétences et sa sincérité semblent évidentes ; j’essaie simplement de jouer l’avocat du diable avec un autre point de vue
« Construire un client e-mail de style terminal que l’on puisse faire tester en alpha à quelques clients » est une demande raisonnable pour un ingénieur dans une startup en phase initiale, et les détails doivent forcément être laissés à l’ingénieur
En particulier, la demande « je voudrais savoir quelle réaction je peux attendre de Kagi si je vais jusqu’au bout » n’était pas bonne. Quand on doit examiner des centaines ou des milliers de soumissions, il n’y a aucun moyen de donner une réponse certaine
Si chercher à clarifier les exigences est un comportement indésirable, autant demander de choisir un nombre entre 1 et 10 et éliminer ceux qui se trompent
Un test sous forme de projet sert à montrer ses capacités ; sans consignes précises, comment deviner jusqu’où il faut aller pour les démontrer ?
Le niveau de finition n’est un problème que lorsqu’il empêche la livraison ; éliminer quelqu’un parce qu’il a « trop peaufiné » donne l’impression de le recaler parce qu’il a trop bien fait le travail
Ce genre de test ambigu ressemble au final surtout à une autre manière de filtrer les gens au motif qu’ils ne seraient pas en adéquation culturelle
Les environnements de type « construis d’abord, on relira ensuite » ont été parmi les plus toxiques de ma carrière, et il n’y a rien de pire que de passer plusieurs jours à développer une fonctionnalité pour découvrir qu’elle n’était pas souhaitée
C’est pourquoi décrire une fonctionnalité par écrit et obtenir une validation est devenu proche d’un standard de l’industrie pour lancer un projet ; ce candidat a suivi des pratiques logicielles qu’une organisation saine appliquerait
C’est aussi ainsi que je le vois en tant que responsable du recrutement dans une entreprise comptant plus de 1 000 ingénieurs
Bien sûr, il ne faut les donner qu’aux candidats pour lesquels le résultat peut réellement faire pencher la décision
Lors de ma dernière recherche d’emploi, j’ai reçu un exercice très large de ce type ; même pour un poste pour lequel j’étais largement surqualifié, j’ai été recalé parce que je ne pouvais pas deviner quelles parties seraient notées
Il me paraît peu probable que j’obtienne à l’avenir un emploi autrement que par recommandation, mais je suis devenu très réticent à recevoir ce genre d’exercice comme à en donner
L’exercice visait à voir s’il était capable de poser quelques questions, de noter ses hypothèses, puis de se lancer avec assurance dans un travail ambigu et de le construire
Il est probable qu’après cet e-mail, le code n’ait plus vraiment compté ; l’entreprise aurait dû s’arrêter à ce moment-là pour éviter au candidat de perdre du temps à implémenter l’exercice
En regardant le code et la vidéo de démo, ma première réaction a été : « Il a fallu une semaine pour faire une application web de deux pages, et il manque même des fonctionnalités e-mail les plus basiques, comme ouvrir un message »
En lisant les exigences, cette personne postulait à un poste d’« Email Backend Engineer », mais pour le véritable backend e-mail, elle a utilisé des produits tiers comme Postmark et Turso
Il manque des éléments de base comme le format d’e-mail en texte brut, l’affichage, les dossiers, au minimum la boîte de réception et les messages envoyés, tandis que des fonctionnalités optionnelles comme un écran de connexion, une page d’administration et un framework backend sont présentes
Dans la base de données backend, il n’y a même pas de map des en-têtes d’e-mail
C’est peut-être un excellent ingénieur, mais il ne semble pas adapté à ce poste précis, et je l’aurais moi aussi refusé
En regardant l’annonce d’origine, le titre était « The project is to build a minimal, terminal-inspired email client », et il était explicitement indiqué de s’inspirer d’outils e-mail existants en terminal comme aerc, mutt ou himalaya
À ce niveau, c’est une mauvaise lecture des exigences, donc cela me paraît non recrutable
Les deux semblent suffisamment remplis
S’inspirer d’outils existants est subjectif, et pour un exercice visant un poste backend, il n’a probablement pas pensé que passer du temps sur l’interface utilisateur était la meilleure manière de montrer ses compétences
Je comprends que ce ne soit pas toujours réaliste si un recruteur doit examiner des centaines de personnes pour un poste très demandé, mais c’est justement pour cela que les épreuves sous forme de projet sont problématiques
Un candidat peut perdre des heures de sa vie sans rien en retirer ; les deux parties doivent donc respecter le temps de l’autre
Je comprends que la réponse ait été très courte et peu utile, mais les exigences demandaient clairement de créer un client e-mail inspiré du terminal.
En regardant la vidéo partagée https://www.youtube.com/watch?v=yY1sVXMkP_o, cela ressemble à une application web d’e-mail assez classique, sans inspiration particulièrement visible venant du terminal.
S’ils voulaient soit une vraie TUI, soit une application web, il est très probable que l’application web devait elle aussi avoir un style terminal.
Dans les exigences complètes, la section « Inspiration » indique explicitement de s’inspirer d’outils e-mail existants en terminal comme « aerc, mutt, himalaya ».
Malgré tout, le prompt mentionnait explicitement d’autres clients en terminal comme sources d’inspiration.
De plus, l’exigence d’un client en terminal change fortement l’objet de l’évaluation. Les interfaces web d’e-mail sont un domaine connu depuis longtemps, tandis que l’expérience utilisateur des clients en terminal n’est pas encore un domaine entièrement « résolu ».
Il est très probable que la grille d’évaluation accordait une place importante aux décisions de conception d’un client en terminal, que sa soumission ne traitait pas du tout.
Les évaluations par exercice à faire chez soi peuvent avoir de la valeur dans un processus d’entretien, mais elles doivent absolument avoir une limite de temps. En 2 à 3 heures, on obtient largement les informations nécessaires ; au-delà, cela revient presque à ne retenir que des juniors sans personnes à charge, loisirs ou responsabilités.
Avec une limite de 3 heures, dans le pire des cas, le candidat n’aurait perdu que 3 heures et, plus probablement, il aurait proposé une approche ou une solution totalement différente, adaptée à cette durée.
Le candidat doit aussi vérifier s’ils veulent « n’importe quelle réponse » ou « une bonne réponse ».
Certains exercices ne regardent que le passage d’un ensemble de tests, sans se soucier de la méthode, tandis que d’autres préfèrent un meilleur code même s’il ne couvre que 80 % des exigences. J’ai vu des candidats mal juger la situation dans les deux cas.
Ce type d’exercice filtre les personnes capables de gaspiller beaucoup de temps sur le projet, tout en risquant de faire passer à côté les personnes occupées — c’est-à-dire celles qu’on voudrait probablement recruter.
Pour recruter des compétences en data engineering, je donne un simple exercice ETL : extraire des données d’un fichier ZIP, les transformer et les insérer dans n’importe quelle base de données.
Je laisse des zones ambiguës, et j’ajoute dans le jeu de données des éléments cachés comme des valeurs null inattendues ou des CSV mal formatés afin d’évaluer la capacité d’exécution.
Je limite à 4 heures, mais je ne donnais pas d’indications sur quoi faire en cas de manque de temps ; c’est une bonne suggestion.
Lors de l’appel suivant, on parcourt le code ensemble et je pose des questions comme « Et si le jeu de données ne tient pas en mémoire ? » pour discuter des pistes d’amélioration ; c’est là que se fait la vraie évaluation technique.
Comme rien ne garantit que tous les candidats aient passé le même temps, cela devient un problème de théorie des jeux, et le candidat est généralement perdant d’une manière ou d’une autre.
Dans beaucoup de cas, la bonne réponse consiste à passer plus de temps pour produire une solution très soignée — mais pas trop soignée — puis à faire semblant d’avoir respecté la limite.
Même 3 heures, c’est très long pour un candidat qui ne sait pas s’il pourra parler à la personne suivante.
Dans un entretien d’une heure, on peut faire un exercice de programmation tout en garantissant que le candidat ne perdra pas de temps supplémentaire.
S’il le souhaite, on peut aussi lui permettre d’envoyer plus tard une version améliorée ; en général, à ce stade, on a déjà une bonne opinion de ses compétences et on peut lui dire : « Faites-le si vous voulez, mais vous êtes déjà passé. »
En gardant un investissement en temps égal entre le candidat et l’intervieweur, je respecte le temps du candidat comme je respecte le mien.
Si un responsable du recrutement ne respecte pas le temps des candidats, il y a peu de chances qu’il respecte celui des employés.
J’ai passé des entretiens récemment dans plusieurs endroits, et mon expérience a été très similaire. J’ai proposé une excellente solution à l’exercice, mais j’ai été refusé sans aucune discussion sur le résultat.
Pour avoir organisé plusieurs fois des processus avec exercice à domicile côté recruteur, je suis convaincu que si l’on demande à quelqu’un de faire un exercice chez lui, il faut impérativement discuter du code avec lui.
Si l’on vous propose un exercice à faire, je recommande fortement de vérifier qu’il y aura une discussion de suivi quel que soit le résultat de l’évaluation, et de ne pas faire ce « devoir à la maison » si vous n’êtes pas d’accord.
Honnêtement, le niveau de beaucoup d’équipes de recrutement est faible, au point qu’implémenter une bonne solution peut devenir un handicap. On peut être refusé pour une raison frustrante : l’équipe de recrutement n’est tout simplement pas à ce niveau.
J’étais un utilisateur précoce de Kagi, mais cette histoire me fait envisager de résilier mon compte. S’ils n’ont pas le temps de parler avec les candidats, ils ne devraient pas leur donner du travail au départ.
Un exercice à domicile demande un effort important non seulement au candidat, mais aussi à la personne qui l’organise et à l’équipe de recrutement ; si le projet a été examiné, il est raisonnable d’attendre un retour ou une réponse sur demande.
Cela dit, il y a aussi la réalité : s’il y a 20 excellents candidats pour un seul poste, beaucoup de personnes compétentes seront refusées. Cela ne veut pas dire qu’elles étaient insuffisantes ou qu’elles ont « échoué ».
Si, pour des raisons juridiques, il faut expliquer pourquoi A a été embauché et pas B, il devient difficile de dire « les deux étaient excellents, mais nous en avons choisi un », et on finit facilement par chercher des défauts qui n’existent pas vraiment.
J’ai souvent vu cette approche dans la culture d’entreprise américaine, et Kagi est basée à Palo Alto.
Être refusé sur un exercice, ce n’est pas un problème ; gaspiller le temps de quelqu’un sans rien lui rendre est difficile à accepter.
Beaucoup d’entreprises, y compris des startups populaires, gèrent cela correctement.
Le résultat ne ressemble pas vraiment à un « client e-mail minimaliste au style terminal », et semble avoir complètement ignoré les outils indiqués comme sources d’inspiration.
Si les exigences ont été aussi largement mal comprises, moi non plus je n’aurais pas passé du temps à en discuter.
C’est un cas typique de mauvaise lecture du contexte implicite. L’entreprise voulait quelqu’un capable de définir de manière autonome son travail et ses objectifs.
Le flou de l’exercice n’était pas là pour pousser à poser une série de questions par e-mail, mais comme une page blanche destinée à montrer comment on explore soi-même un espace de problème assez large et comment on produit un résultat.
Quand on travaille à l’université, cela ressemble beaucoup aux étudiants qui n’ont pas compris un devoir, reçoivent une note inattendue et s’en plaignent.
Dans un contexte d’entretien où l’on veut faire bonne impression, peu de gens osent se montrer « paresseux ».
Pour une entreprise centrée sur les lancements rapides d’expérimentations et les prototypes, certaines personnes ne conviennent vraiment pas, et c’est mauvais pour tout le monde.
Peut-être qu’un candidat aura passé 10 minutes à réfléchir à ce qu’il pouvait faire en 60 minutes, aura utilisé l’authentification HTTP et un formulaire, l’aura fait tourner avec un petit backend en Go, puis l’aura envoyé avec un court e-mail. Ce genre de personne aurait probablement eu bien meilleure allure dans le processus.
Impossible de savoir s’il s’agit d’un prototype jetable, de quelque chose que de vrais utilisateurs verront, si une expérience utilisateur incomplète sera reprochée, ou s’ils veulent simplement voir quelque chose.
Au final, cela devient un exercice où il faut deviner les préférences du reviewer.
À l’inverse, il y en aura aussi qui seront recalés pour ne pas avoir suffisamment insisté afin de clarifier les exigences, alors que c’est une qualité importante chez un ingénieur.
La vie n’est pas juste, mais on attend davantage des responsables du recrutement, et c’est pour cela qu’on est sans cesse déçu.
Il est aussi possible que l’étudiant n’ait pas su lire dans les pensées et que les consignes aient été très mal rédigées, d’où le malentendu.
Un bon enseignant est quelqu’un qui fait en sorte que le plus grand nombre possible d’étudiants comprennent ; un mauvais enseignant, c’est l’inverse.
Avec les meilleurs enseignants, il n’y avait pas besoin de remettre la note en cause, parce que les critères d’évaluation étaient transparents dès le départ.
S’il y a beaucoup d’étudiants perdus, le dénominateur commun peut être l’enseignant.
Ce n’est pas parce que des moines bouddhistes apprennent en résolvant des énigmes ésotériques appelées kōan qu’il faut appliquer la même méthode à des étudiants qui paient des frais de scolarité.
Puisque l’auteur semble l’avoir publié lui-même, je vais essayer d’expliquer le contexte des réactions reçues. J’ai travaillé chez Kagi par le passé et j’ai passé un test technique similaire.
À l’époque, l’entreprise était très petite, Vlad examinait directement les candidats et utilisait ce type de projet à réaliser. Aujourd’hui l’entreprise a grandi et il ne regarde peut-être plus tout lui-même, mais l’essentiel semble similaire.
Quand on parle avec Vlad, il est presque l’archétype du commentateur de Hacker News, et l’entretien ressemble plutôt à une vérification d’ambiance pour voir si l’on a l’air d’être quelqu’un de correct.
Lui envoyer un long document de conception disant « je vais utiliser Galactor, rendre ça florp-ready et fleem » est exactement l’inverse de ce qu’il trouverait cool.
Si l’exercice est « un client e-mail façon terminal », un projet proche du maximum serait probablement quelque chose où toutes les fonctions ont des raccourcis clavier, avec un paragraphe expliquant qu’il ne dépasse pas 2 ms pour dessiner une frame.
Il est possible que l’interviewer ait jugé que le candidat avait une pensée trop enterprise pour travailler chez Kagi.
Bien sûr, la question de savoir si cette méthode de sélection est bonne est un autre sujet. Vlad veut des gens qui pensent comme lui, et ce type d’entretien soulève beaucoup de problèmes longuement débattus et étudiés.
Cela dit, si l’on comprend cela et qu’on a la marge nécessaire pour supporter ce processus, l’exercice a effectivement du sens. Kagi aurait pu mieux communiquer ce point.
C’est dommage d’avoir perdu autant de temps, mais j’espère que l’auteur trouvera un endroit plus adapté à sa manière de travailler.
Pour apporter de nouveaux éclairages à un problème, il faut une diversité de pensée. Si tout le monde pense de la même manière, quand une personne bloque, il y a de fortes chances que tout le monde bloque.
Cela semble être un problème fréquent dans les startups, et c’est peut-être un signal qui explique pourquoi 9 startups sur 10 échouent.
Ce n’est pas la même chose que tester les compétences. Ici, il faut obtenir un bon score sur des critères qui ne sont pas communiqués pour passer.
Donner un exercice en disant « code n’importe quoi, il faut savoir gérer l’ambiguïté », alors qu’en réalité il faut deviner ce que j’ai en tête, ce n’est pas très différent.
C’est une façon très peu respectueuse de traiter les gens, et cela ne donne pas non plus un bon signal sur Vlad en tant que personne.
Je suis censé fouiller les réseaux sociaux des gens de l’entreprise pour découvrir ça ?
Si, au final, ils ont satisfait leur curiosité en me disant de « continuer » alors que j’avais déjà suffisamment montré que je n’étais pas cool, j’espère qu’ils seront traités comme ils traitent les autres.
Merci pour l’explication, et je n’ai pas de rancune. J’aurais simplement aimé voir ce genre de message plus tôt.
À l’avenir, il vaudrait mieux classer les postes avec un « take-home » comme des postes pour les cool kids. Ainsi, les ingénieurs ennuyeux mais expérimentés pourront faire pression sur les entreprises pour qu’elles changent leurs méthodes si elles veulent réellement notre travail.
Et si une entreprise ne change pas, on pourra en déduire quel genre d’entreprise « propose » ce rôle.
J’ai regardé le code pour voir comment je l’aurais perçu en tant que reviewer.
Dans le premier fichier que j’ai ouvert, je me serais arrêté ici : https://github.com/Sleepful/mymail/blob/main/app/router/page...
Le premier commentaire est très étrange, sans rapport avec la tâche, et ressemble à quelque chose copié depuis un exemple de blog. Quoi qu’il en soit, l’avoir laissé tel quel montre un manque d’attention.
La formulation de la deuxième ligne n’est pas cohérente avec la troisième.
Je me serais arrêté là dans la review. C’est un manque d’attention aux détails, et cela ne démontre pas une capacité à penser clairement.
Et la seule réponse a été un e-mail de refus vide.
Dans ces conditions, j’ai du mal à accepter l’idée que j’aurais dû passer plus de temps sur les commentaires du code.
Je parle en tant qu’intervieweur côté ingénierie. Je n’aime ni LeetCode ni les exercices à faire chez soi. Les deux prennent beaucoup de temps et donnent peu d’informations.
Cela dit, dans ce cas, j’aurais probablement refusé l’auteur. Kagi Search est une startup, et ce genre d’entreprise cherche généralement des optimistes pragmatiques capables de trouver un équilibre entre profondeur et largeur.
J’ai déjà eu un collègue qui avait rassemblé les informations, s’était enfermé pendant plusieurs jours pour élaborer une solution, puis était revenu pour découvrir que les exigences avaient changé entre-temps. Ce n’était une expérience agréable pour personne.
Je déteste vraiment les processus avec exercice à faire chez soi.
La phrase « Ce projet ne teste pas seulement le code, mais aussi la capacité à gérer l’ambiguïté et les problèmes ouverts » sonne en réalité comme si a) l’exercice était si mal conçu qu’aucune grille d’évaluation n’avait été préparée, ou b) l’environnement de travail était tellement chaotique qu’aucune spécification ni exigence n’était clairement définie.
En plus, les consignes « montrez votre maîtrise technique » et « proposez une solution pratique et fonctionnelle » se contredisent. Une bonne solution simple n’est pas spectaculaire.
Savoir faire une requête HTTP et créer un écran d’édition CRUD de base ne dit presque rien. Les outils d’IA produisent eux aussi ce genre de choses rapidement, avec une qualité plutôt correcte.
Ce que je veux voir, c’est comment un ingénieur implémente une logique métier bancale.
Est-ce que cela devient un million de
ifimbriqués et des commentaires du type « ici vivent des dragons », ou est-ce qu’il trouve les bons patterns pour produire du code lisible et raisonnement possible ?C’est beaucoup plus précieux dans le vrai travail, c’est un signal d’entretien plus fort, c’est plus difficile à réussir pour l’IA, et cela prend moins de temps.
Produire une bonne solution simple peut justement être une manière de démontrer ses compétences.
À mon avis, c’est une grande partie du rôle d’un ingénieur logiciel senior.
Ce format n’est peut-être pas la meilleure façon de tester cela, mais « voir si la personne sait gérer l’ambiguïté » ne veut pas dire que tout est ambigu.
Cela peut vouloir dire que tout travail doit passer par le processus qui mène d’« exigences ambiguës » à des « spécifications claires ».