Rémi, CTO de Zénior (ex-Payfit, ex-Alan), fait passer en direct un entretien technique à Philippe, Product Engineer récemment recruté dans son équipe. L'exercice : coder un puissance 4 en quarante-cinq minutes, sans IA. Au-delà du test, c'est tout le raisonnement de recrutement de Rémi qui est exposé — les signaux recherchés, ce qui rassure, ce qui inquiète, et pourquoi l'IA a changé ce qu'il regarde dans un candidat.
1. Un secteur "préhistorique" qui a besoin d'ingénieurs avec une sensibilité produit
<p><em>Zénior est une startup early stage qui construit l'écosystème pour accompagner les aidants dans la recherche de solutions pour leurs proches en perte d'autonomie — EHPAD, habitat partagé, résidence senior, aide à domicile — et qui outille aussi les établissements et les professionnels de santé. Rémi, CTO de Zénior, est passé par Payfit et Alan. Philippe, Product Engineer chez Zénior, vient du jeu vidéo, de la data, et d'un passage par la Commission européenne. L'exercice du jour n'est pas le vrai test technique utilisé par Zénior, mais une version très proche, recréée pour la démonstration.</em></p>
Rémi pose le contexte avant l'exercice. Le secteur du grand âge est, selon lui, technologiquement très en retard. "C'est une industrie qui a été délaissée pendant très longtemps, qui d'un point de vue technique, on pourrait dire est préhistorique aujourd'hui. Il y a un gap immense à aller rattraper."
D'où le profil recherché en priorité : le Product Engineer. "Un ingénieur full stack avec une sensibilité produit. Un ingénieur qui est capable de prendre un problème, de le décomposer, et de le résoudre et de l'implémenter. Si on va même plus loin, c'est quelqu'un qui est capable de discuter avec les stakeholders, de comprendre les enjeux qu'on a et de créer de l'impact sur le business."
La raison structurelle : "On n'a que Rodolphe, qui est CPO, qui fait le rôle un peu de product. Si on mise que sur lui pour vraiment faire un rôle de PM, de faire les tâches, les specs — c'est injouable, on ne va pas avancer. On a vraiment besoin que les ingénieurs soient capables de faire ce travail aussi."
"Les lignes de code, on s'en fout un peu. L'important, c'est surtout qu'est-ce que ça va créer pour le business derrière."
2. Un filtre contre les prompts, un signal humain
Rémi explique son choix de méthode avant de commencer l'exercice. Sur le synchrone vs l'asynchrone : "Le problème des tests asynchrones, c'est qu'on prompte, le test est résolu. Il faut trouver des astuces pour contrecarrer ça." L'expérience humain à humain reste, selon lui, "quelque chose de très classique, mais vachement important."
Sur l'IA désactivée pendant le test : "Comme on a le sujet du test technique, on n'autorise pas l'utilisation de l'IA. C'est devenu tellement basique qu'une demande à l'IA n'aurait pas de sens et ne permet pas de détecter les signaux qui m'intéressent."
L'outil utilisé est Replit, choisi par habitude plus que par nécessité technique. "On n'a pas un besoin très élevé. À partir du moment où on peut avoir un fichier de code et un endroit pour le coder, ça nous suffit." L'option IA de l'outil est explicitement désactivée pendant l'exercice.
Sur le format : un test qui dure habituellement quarante-cinq minutes (sur un entretien d'une heure au total), réduit pour la démonstration. Rémi prévient qu'il jouera double rôle — intervieweur et "pair" — en aidant à corriger des erreurs mineures de syntaxe pour ne pas ralentir le raisonnement du candidat.
3. "Faire un puissance 4" ne veut rien dire — et c'est voulu
L'énoncé donné à Philippe est minimal : coder un puissance 4 en Python ou JavaScript. Pas de spécifications. Rémi explique pourquoi : "L'objectif, c'est de voir si la personne est capable, avec un énoncé pourri, de creuser quels sont les specs qu'on attend. Et ça permet aussi de détecter si la personne part sur des a priori."
Philippe pose les bonnes questions avant de coder : la taille du plateau, les conditions de victoire (quatre pions alignés ou plus, en ligne ou en colonne), le cas d'égalité (plateau plein). Rémi valide chaque clarification au fur et à mesure.
Premier signal positif relevé par Rémi en commentaire : Philippe a explicitement reformulé et fait valider sa compréhension de la "gravité" du jeu — un jeton tombe et prend la place la plus basse disponible. "Même s'il le sait inconsciemment, il a quand même verbalisé et m'a demandé validation."
Sur la décomposition MVP : Philippe propose de couper la gestion d'erreurs (validation des inputs) pour gagner du temps, en l'expliquant explicitement. Quand Rémi le pousse à aller encore plus loin dans le MVP — "es-tu capable de faire encore plus MVP ?" — Philippe propose de retirer même la condition de victoire dans une première itération, pour valider d'abord que la mécanique de jeu fonctionne. Rémi valide : "C'est en effet mieux."
Le framework que Rémi évalue à ce stade : les cinq étapes du flot produit — comprendre, prioriser, résoudre, implémenter, valider. "Là, on est vraiment sur les étapes comprendre, prioriser, et on commence même à résoudre."
4. Naming, dépendances, et une boucle while true reconnaissable
Pendant la phase de code, Philippe construit le plateau, la fonction d'affichage, le placement des pions, puis l'alternance des joueurs (calculée via le nombre de pions déjà placés, pas un compteur séparé). Rémi commente en direct certains choix.
Sur l'usage de len(board[0]) plutôt que d'utiliser directement les constantes définies en haut du fichier : Rémi challenge le choix. Philippe justifie : "Ce qui m'intéressait, c'était que vu qu'on a le board que l'on passe en paramètre, on ne dépend plus forcément de la constante. Si dans le futur on décide d'ajouter la fonctionnalité de pouvoir choisir un nombre de colonnes aléatoires, on n'est plus lié directement par la constante."
Sur le choix d'une boucle while True, Rémi note en aparté pour le public : "Spoiler alert pour ceux qui ne savent pas, Philippe a travaillé aussi dans le jeu vidéo. Le while True est typique d'une boucle infinie du jeu vidéo — c'est une boucle qui continue jusqu'à un break, une condition de victoire ou une fin de jeu."
Sur l'affichage : Philippe ajoute, sur suggestion du chat relayée par Rémi, les numéros de colonnes au-dessus du plateau pour que l'utilisateur s'y retrouve. Rémi qualifie ça de "quick win", pas critique mais utile.
5. Une bonne solution, mal expliquée sur le moment
Pour la condition de victoire, Rémi pousse Philippe à se limiter aux alignements horizontaux et verticaux (pas de diagonales, faute de temps). Philippe choisit de ne vérifier l'alignement qu'autour du dernier pion posé, plutôt que de scanner tout le plateau à chaque coup.
Quand Rémi lui demande pourquoi ce choix, Philippe part dans une explication plus complexe que nécessaire, évoquant BFS et DFS. Rémi commentera ce point précisément dans le débrief final (voir section 6) : la réponse simple était qu'aucun gain n'est possible ailleurs qu'autour du dernier jeton posé, puisqu'aucun pion ne se déplace.
L'implémentation fonctionne : testée en direct sur les colonnes puis sur les lignes, avec une victoire détectée correctement dans les deux cas. Le temps imparti (réduit pour la démo) s'épuise à ce moment — pas de temps pour les diagonales ni pour la gestion d'erreurs.
6. Trois points forts, trois axes d'amélioration
Rémi livre son débrief immédiatement après l'exercice, en commentant pour Philippe et pour le public.
Points forts
La winning condition est jugée "smart" — "un peu atypique, mais en ce moment, c'est smart de la gérer de cette manière." Le code est jugé propre : naming clair, décomposition par fonction lisible. La gestion du temps et la priorisation MVP sont bonnes.
Axe d'amélioration n°1 : la clarté de l'explication technique
Sur le choix de ne checker l'alignement qu'autour du dernier pion : "Je n'ai pas le sentiment que tu es parti dans une explication un peu complexe. La réponse est simple : on ne peut pas gagner en dehors de l'endroit où il y a eu un jeton, puisqu'il n'y a pas de déplacement. Tu avais la base, mais tu as eu du mal à la réexprimer simplement."
Axe d'amélioration n°2 : ne pas trop coder pour un futur hypothétique
Sur le débat des constantes : "Je trouve ça bien que tu projettes sur le futur de l'architecture possible. Mais attention à ne pas coder pour un futur qui potentiellement n'arrivera pas. C'est le genre de truc où tu te dis je gère tel cas parce que dans dix jours on va peut-être gérer ça — et au final, ce n'est jamais géré, tu restes juste avec une dépendance."
Axe d'amélioration n°3 : la question de l'impact business
Quand Rémi demande à Philippe comment il mesurerait l'impact de la feature, Philippe propose des métriques de jeu vidéo (nombre de parties, temps moyen, taux de retour). Rémi : "Tu as globalement la bonne réponse pour les mauvaises raisons. La première question, ce n'est pas 'comment je mesure l'impact', c'est 'c'est quoi l'impact qu'on cherche à avoir ? C'est quoi les KPI qui comptent pour le business ?' Sur un senior, j'en attendrais peut-être plus là-dessus."
Verdict final : "Globalement, il a réussi. Philippe est officiellement junior, officieusement intermediate."
7. Ce que Rémi répond sur l'IA, la séniorité et la triche
Le process complet chez Zénior
Un intro call avec le cofondateur et CPO. Cet entretien technique (puissance 4). Un deuxième entretien plus architectural, sans code — discuter d'une problématique de scale et de design système. Un entretien avec les cofondateurs pour le fit humain. Et un dernier moment informel, "viens au bureau, on mange ensemble." Rémi évoque aussi un process "officieux" : en cas de doute sur un signal, un troisième entretien technique supplémentaire peut être proposé. "Le process ne doit jamais prendre la place de l'humain. Vouloir un process qui fonctionne en tous les cas est impossible et finira par faire des croix sur des gens qui auraient pu être des talents super intéressants."
Sur le langage
Zénior teste uniquement en Python ou en JavaScript (stack réelle de la boîte : Python back, JS front). "On se fait une croix sur les candidats qui ne maîtrisent pas nos langages — par souci de qualité de l'entretien qu'on donne aux candidats."
Sur la séniorité minimale
Zénior ne recrute pas de juniors sortie d'école. Minimum un an d'expérience. Sur l'alternance : "Il n'y a pas de réponse absolue. Ça dépend du type d'alternance, d'où elle a été faite — startup early stage ou grosse boîte. Il y a plein de facteurs."
Sur l'IA et la syntaxe — le tournant post-Claude
"Avant Claude, je regardais quand même vachement la syntaxe. Maintenant, c'est la partie que je vais moins regarder." Chez Zénior, l'IA est utilisée intensivement (Claude, Conductor pour faire tourner plusieurs agents en parallèle), mais chaque PR reste reviewée par un humain en plus d'un agent IA.
Sur pourquoi l'IA est interdite pendant ce test précis
"Si tu mets Claude sur un exercice comme ça, je ne vais rien apprendre. Toute cette réflexion produit, je ne vais pas l'avoir. C'est ça qui m'intéresse." Mais l'usage de l'IA en tant que tel n'est pas un sujet pour Rémi : "Je m'en fous que tu saches utiliser Claude ou pas, de la même manière que je n'ai pas testé si tu sais utiliser VS Code. Ce n'est pas ça qui va définir quoi que ce soit. C'est sa vitesse."
Sur le risque de dépendance à l'IA
"Au pire des cas, si j'ai tort de me méfier de la dépendance à l'IA, on aura perdu vingt pour cent d'efficacité sur un an. Par contre, si j'ai raison, tu finis avec une code base que tu ne contrôles plus." Rémi évoque aussi un risque économique : une hausse anticipée des coûts par token après les introductions en bourse d'Anthropic et OpenAI, qui changerait la rentabilité d'un usage massif et peu maîtrisé de l'IA.
Sur la triche
"Quelqu'un qui veut tricher va toujours réussir. Mais je le sens sur la fluidité avec laquelle la personne répond aux questions quand je la challenge. Pour la majorité, c'est assez facile de détecter si la personne récite ou explique. Tricher en entretien n'a aucun intérêt — tu te fais virer pendant la période d'essai."
"Ce que je ne veux pas, c'est que l'IA prenne le dessus sur la réflexion produit. C'est ça qui m'intéresse — pas de savoir si tu sais utiliser Claude."