Le processus d'entretien d'ingénierie assisté par l'IA de Tolan

Tolan a repensé son processus d'entretien d'ingénierie pour refléter la façon dont les ingénieurs travaillent réellement avec des agents d'IA de codage. Au lieu de questions algorithmiques traditionnelles, ils se concentrent sur les compétences pratiques qui comptent lorsque l'IA écrit la plupart du code en production.

La structure de l'entretien

Les candidats passent une matinée dans leur bureau de San Francisco à travailler sur un petit problème que Tolan a déjà résolu eux-mêmes. Le problème provient d'un fichier Figma minimaliste ou d'un court cahier des charges, représentant généralement un flux simple ou une fonctionnalité légère qui prendrait normalement un jour ou deux à développer.

Les candidats n'ont que quelques heures pour travailler sur le problème, ce qui n'est pas suffisant pour créer un produit abouti. Cette contrainte est intentionnelle—ils veulent voir comment les candidats travaillent avec des limitations.

Les outils d'IA encouragés

Les candidats sont explicitement encouragés à utiliser l'IA pour résoudre le problème. Tolan fournit des licences pour Claude, Codex, Cursor ou Gemini si nécessaire. L'attente clé est que les candidats doivent équilibrer le code généré par les LLM avec leur propre jugement—même s'ils n'écrivent pas le code, ils en sont responsables.

Ce qu'ils recherchent :

• Comment les candidats abordent le problème
• Comment ils structurent une solution
• Comment ils réfléchissent aux contraintes
• Comment ils décident de ce qui compte vraiment

Critères d'évaluation

Après la session de travail, il y a une conversation de 20 à 30 minutes sur ce qui a été créé. Les intervieweurs demandent ce que les candidats amélioreraient s'ils avaient plus de temps, ce qu'ils changeraient avant de soumettre pour revue, et ce qu'ils changeraient avant de livrer.

Les signaux d'alerte incluent :

• Les candidats qui utilisent les LLM pour réfléchir à la façon dont le projet devrait être réalisé (comme capturer une capture d'écran de Figma et demander à Claude de le résoudre)
• Les candidats qui ne remettent pas en question des spécifications peu claires
• Les candidats qui disent "Je ne suis toujours pas sûr de ce que fait cette partie" mais ne changeraient rien avant une revue humaine

Les signaux positifs incluent :

• Clarifier les énoncés de problèmes et explorer les cas limites
• Reconnaître les compromis
• Souligner quand quelque chose semble étrange ou ne paraît pas correct
• Faire preuve de créativité (comme créer un mini-jeu pour divertir les utilisateurs pendant les attentes de réponse des LLM)
• Savoir quand le travail n'est pas assez bon et comment l'améliorer

La philosophie centrale : Dans un monde où la mise en œuvre devient plus facile, ce qui compte le plus est le jugement. Un code fonctionnel n'est pas la ligne d'arrivée—le comprendre et le maintenir l'est.