Anthropic : un cadre remplace le test de code par le prototype

Felix Rieseberg, responsable technique chez Anthropic et pilote de Claude.ai et Claude Code Desktop, dit avoir tourné la page des entretiens de codage. Il affirme privilégier des prototypes concrets et soutient que l'IA rend les exercices classiques obsolètes. Un exemple interne cite deux ingénieurs qui ont bâti une interface de Claude Code en un week-end, avec une version publique huit jours plus tard.

Chez Anthropic, des prototypes expédiés en jours et un nouveau critère d’embauche

Deux ingénieurs d’Anthropic, Anthony Morris et Alice Zhao, alors relativement nouveaux, ont réalisé l’interface graphique de Claude Code en un week-end. Selon Felix Rieseberg, la première version publique a suivi environ huit jours plus tard. Il explique désormais rechercher, dans les dossiers de candidature, de petits prototypes qui révèlent du goût, de l’empathie et une réflexion principielle. Il affirme que l’entretien classique de codage ne reviendra pas. Rieseberg a dirigé le développement de Claude.ai et de Claude Code Desktop.

Pourquoi il délaisse les tests : l’IA ferait tomber le coût d’exécution

Felix Rieseberg dit avoir abandonné l’entretien technique fondé sur l’exécution de petits exercices. Il soutient que l’IA rend ces tests inutiles et affirme que Claude résout mieux ces tâches que les candidats. Il estime qu’un défi en React n’a plus de sens, au même titre qu’un questionnement sur Assembly. Selon lui, le problème central des nouveaux arrivants tient au fait qu’on ne les écoute pas, dans des structures historiquement conçues pour filtrer l’exécution parce qu’elle était coûteuse. Il décrit des organisations où quelques décideurs validaient les idées et où il fallait gravir une hiérarchie rigide avant d’obtenir la confiance nécessaire pour construire. Il avance que l’IA modifie cette équation, car l’exécution ne serait plus coûteuse.

Avantage des nouveaux : voir les frictions ignorées par les anciens

Felix Rieseberg soutient que les nouveaux arrivants perçoivent des problèmes que des employés de longue date ont cessé de remarquer. Il cite James March, qui écrivait en 1991 que les organisations dépendent d’un flux constant de nouveaux venus naïfs et mal informés. Il rappelle aussi que Patrick Collison a explicitement encouragé les nouvelles recrues à signaler ce qui leur paraît étrange. Selon Rieseberg, des collègues plus anciens ne voient plus certains points de friction. Il affirme que, chez Slack ou Notion, des profils en poste de longue date avaient du mal à adopter la perspective d’un utilisateur externe, quand les nouveaux venus sur des produits orientés utilisateurs apportent une empathie naturelle. Il ajoute que les ingénieurs sur l’infrastructure ou des outils internes profitent de ne pas savoir pourquoi une solution est supposée impossible.

Exemple chez Notion : une « impossibilité » réévaluée

Chez Notion, Felix Rieseberg indique avoir reçu la mission de concevoir une architecture hors ligne que plusieurs considéraient comme irréalisable. Le modèle de données était jugé trop complexe et il était supposé que le PDG, Ivan Zhao, refuserait la seule voie viable. Il affirme que l’obstacle technique était bien réel mais que la résistance du fondateur ne l’était pas. Selon lui, personne n’avait posé la question à Ivan Zhao, tant cette hypothèse s’était muée en savoir commun.

Sa méthode : viser la valeur métier et livrer un prototype en un week-end

Felix Rieseberg s’appuie sur une formule de Patrick McKenzie, écrite en 2011, selon laquelle les ingénieurs sont embauchés pour créer de la valeur commerciale, pas pour programmer des choses. Il recommande de comprendre ce que l’entreprise cherche à accomplir et de se concentrer sur les parties qui génèrent des revenus, en commençant par connaître les objectifs du manager de son manager. Il préconise de choisir une idée ambitieuse alignée sur ces objectifs et de construire un prototype fonctionnel en un week-end, pour éviter les cycles de spécifications, d’approbations et de plaidoyers internes. Il conseille de miser sur une seule bonne idée plutôt que d’en dissimuler trois bonnes parmi 20 mauvaises et met en garde contre les prototypes qui tentent simultanément un nouveau langage, un backend et des applications mobiles. Il estime que le prototype doit rendre l’opportunité évidente à la direction et identifier la bonne personne pour la porter. Rieseberg affirme aussi que des développeurs ambitieux peuvent utiliser l’IA pour dépasser des collègues plus expérimentés, que les scores de tests ne prédisent plus la réussite et qu’il voit des profils relativement nouveaux surpasser des seniors. Il résume cette dynamique par « la faim bat l’ancienneté » et redéfinit le terme « junior » comme l’absence de statut, de pouvoir ou de réseau, plutôt que l’ancienneté en années.