J'ai évalué +100 ingénieurs IA : Voici comment réussir le test technique

Regardez la vidéo!

Une question qu’on me pose tout le temps, c’est : « Comment je me prépare aux entretiens en ingénierie IA ? »

Et récemment, c’est souvent accompagné de : « J’entends dire que les gens reçoivent des projets à faire en 24 heures. Je pratique quoi pour ne pas paniquer quand j’en ai un ? »

Voici la réponse pratique que vous n’avez peut-être pas envie d’entendre…

La plupart des gens se préparent comme si les entretiens étaient un jeu de trivia. Ils se font une énorme liste de questions. Ils mémorisent des définitions. Ils font quelques problèmes LeetCode. Tout ça est utile, oui, surtout pour certains entretiens de code old-school très spécifiques, mais ça passe à côté de ce que ces projets d’entrevues testent réellement.

Dans ces projets d’entreprise, le résultat compte. Mais votre façon de penser compte plus. Et je dis ça après avoir interviewé, honnêtement, plus d’une centaine de candidats potentiels pour nos rôles d’ingénierie IA chez Towards AI.

La façon dont vous clarifiez une spec vague et cherchez plus d’info avant de continuer, ou à l’inverse dont vous faites de bonnes hypothèses avec plusieurs scénarios. La façon dont vous choisissez un baseline. La façon dont vous évaluez. La façon dont vous documentez les compromis. La façon dont vous montrez que vous pouvez shipper quelque chose de réel, même si c’est petit. Et honnêtement, parfois, la façon dont vous montrez que vous ne pourriez pas shipper, pourquoi, et ce que vous feriez ensuite. C’est ça qu’on cherche dans le test. Pas l’app finale qui marche, que Claude a faite pour vous.

Et si vous voulez vous y préparer, voici une vérité utile sur beaucoup de ces projets utilisés pour vous tester. Ils viennent souvent de quelque chose dont l’entreprise a réellement besoin mais n’a pas eu le temps d’explorer. Une comparaison qu’ils veulent lancer depuis un moment. Un proof of concept rapide pour tester si quelque chose marche dans leur setup. Un petit outil interne qu’ils pourraient garder si c’est décent. C’est pour ça que la consigne est souvent un peu vague. Le vrai travail est vague. C’est ça, le point.

J’ai récemment reçu un email d’un étudiant de notre cours Full Stack AI Engineer, qui disait qu’il postulait, et que ses amis recevaient ces projets de 24 heures. Il voulait une idée d’entraînement sur un week-end qui fasse réaliste, surtout avec les outils modernes et les meilleures pratiques.

Et je lui ai dit que c’est difficile de prédire exactement ce que n’importe quelle entreprise va demander, parce que… vous ne pouvez pas. Mais vous pouvez pratiquer le pattern.

Donc je lui ai donné une idée de projet qui est très proche de quelque chose qui nous importe vraiment en travail client, et que j’ai aussi utilisée pour tester un candidat récemment.

Construisez un pipeline OCR simple de traitement de documents écrits.

Pas un notebook Colab. Pas une démo qui ne marche que sur un exemple parfait. Un petit pipeline que vous pouvez exécuter de bout en bout sur un vrai document scanné, évaluer, et expliquer.

Je n’ai pas donné beaucoup plus de détails, vraiment, mais voici ce que moi (ou un autre manager) regarderait :

La première étape, c’est de choisir genre dix documents. Rendez ça concret. Choisissez un type, mais autorisez de la variation à l’intérieur. Par exemple, dix factures de fournisseurs différents. Ou dix CV. Ou dix recettes scannées. Ou dix formulaires médicaux si vous voulez pimenter, mais restez éthique et évitez les données sensibles. Ça aussi, c’est évalué ! Vous pourriez documenter comment vous évitez d’envoyer des données privées à l’API de Gemini, ou comme raison d’utiliser un modèle local, etc.

Prenons des factures, parce que c’est facile à comprendre, et ça vous force à gérer des layouts bordéliques.

Vos dix factures pourraient inclure, par exemple, un PDF moderne et propre, une page scannée de mauvaise qualité, une facture avec un gros tableau de line items, une avec un format de devise bizarre, une avec une note manuscrite quelque part. Vous voulez cette variation. C’est réaliste, et ça vous force à construire quelque chose de robuste.

Ensuite, vous décidez quels champs extraire. Restez serré. Un bon set pourrait être le nom du fournisseur, le numéro de facture, la date de facture, le montant total, le montant des taxes, et la devise. Si vous voulez un élément de tableau, incluez les line items, mais seulement comme stretch goal. En 24 heures, shipper les champs core correctement, c’est déjà une win. Ensuite, travaillez sur des ajouts, ou rédigez simplement la liste de to-dos clairement dans des git issues, et bien documentée aussi, en partant du principe que quelqu’un D’AUTRE va reprendre. Donc elles doivent être lisibles et facilement applicables, PAS JUSTE PAR VOUS ! Documentez proprement et clairement. Et ici, Claude Code peut le faire super bien pour vous !

Maintenant, vous définissez votre output cible. Ça a l’air évident, mais c’est là que beaucoup de gens dérivent et s’éloignent de résultats intéressants. Vous voulez un schéma structuré que vous pouvez stocker et évaluer. Quelque chose comme un record de document avec des métadonnées, et un set de champs extraits typés. Quelque chose que vous pouvez ensuite mesurer.

Donc, par exemple, votre output extrait pour chaque facture pourrait ressembler à :

VendorName en texte
InvoiceNumber en texte
InvoiceDate comme une chaîne de date dans un format unique et cohérent
TotalAmount comme un nombre
TaxAmount comme un nombre
Currency comme un code à trois lettres

Ça devient votre contrat. Votre système remplit ces champs, ou il ne les remplit pas. Et quand il ne les remplit pas, ou qu’il les remplit mal, vous pouvez le mesurer.

Maintenant, vous construisez le pipeline. Dans sa forme la plus simple, c’est OCR + extraction. Vous construisez ça comme vous voulez au début. Mais essayez d’avoir un baseline qui tourne. Ça n’a vraiment pas besoin d’être idéal : juste une recherche rapide sur le meilleur système open-source d’extraction de mots-clés, ou même via API.

L’OCR prend un PDF ou une image et vous donne du texte. L’extraction prend ce texte et produit des champs structurés. Vous pouvez faire l’extraction avec un modèle de langage, des règles, ou un mix. L’important, c’est que ça sorte des données structurées de manière fiable, pas un paragraphe qui a l’air correct jusqu’au moment où vous essayez de le parser. Honnêtement, ici vous pourriez juste utiliser l’API de Gemini puisqu’elle traite des images, et lui demander d’extraire les champs que vous cherchez avec un bon prompt. C’est un bon point de départ.

Et ensuite vient la partie qui rend ça “interview ready”.

Vous mesurez, vous comparez des approches et/ou vous documentez comment vous le feriez ensuite, selon la timeline.

Au minimum, comparez-en deux. Par exemple, un modèle OCR SOTA A versus un modèle vision-LLM B comme OCR. Ou un pipeline OCR open source versus un baseline du style : envoyer votre image à ChatGPT et lui demander d’extraire les champs. Je ne vous dis pas de vous reposer là-dessus en production. Je vous dis que c’est un excellent baseline en entretien parce que ça montre que vous comprenez la mesure et les compromis.

Ensuite, vous définissez l’évaluation. Restez simple et quantitatif. Pour chaque document : est-ce que vous avez le nom du fournisseur correct ? Est-ce que vous avez le numéro de facture correct ? Et ainsi de suite. Comptez le nombre de champs corrects sur N. Et s’il vous plaît, prenez les 10–15 minutes nécessaires pour construire et vérifier le ground truth de votre petit set de test. Ici, ça veut juste dire extraire l’information vous-même, ou prendre ce que ChatGPT vous a donné et vérifier que c’est correct en relisant.

Si vous avez dix documents et six champs, ça fait soixante extractions de champs. Vous pouvez littéralement rapporter : « Approche A a 44 sur 60 correct, Approche B a 51 sur 60 correct. » Et regarder les échecs, checker ce qui s’est passé, puis écrire un mini breakdown. Peut-être que les dates de facture cassent sur deux documents à cause du format. Peut-être que les totaux cassent parce que l’OCR a raté une décimale. Ce genre d’analyse, c’est exactement ce que les interviewers veulent voir. Si vous en aviez assez à cœur pour prendre un peu de temps, comprendre et investiguer, plutôt que juste prompter et attendre.

Ensuite, si vous avez un peu de temps, rendez ça encore plus réel en sauvegardant les outputs dans une base de données. Encore une fois, restez boring. Une base SQLite locale, c’est parfaitement OK. Une table pour les documents, une table pour les résultats extraits, peut-être une table pour les résultats d’évaluation. Ça montre que vous pensez comme un engineer. Ça rend aussi les reruns et les comparaisons faciles. Montrer que vous savez utiliser Git et des services cloud pour tout ça, c’est un bonus qu’on aime aussi voir. Et c’est facilement transférable à d’autres.

Et vous écrivez un README clair qui explique les hypothèses, les décisions, et ce que vous feriez ensuite.

Ce README compte plus que les gens ne le pensent. Parce qu’il montre comment vous réfléchissez. Il montre si vous savez communiquer. Il montre si vous avez remarqué les contraintes. Il montre ce que vous clarifieriez si c’était du vrai travail.

Aussi, si vous n’avez pas pu finir quelque chose, écrivez-le, ou mettez-le dans des git issues comme je l’ai mentionné. Si vous avez choisi de ne pas faire les line items parce que vous avez priorisé les champs core et l’évaluation, c’est une bonne décision. L’important, c’est que vous puissiez la défendre, pas que vous ayez pu tout faire dans le temps.

Pour cet exemple, deux scripts suffisent.

Un script pour traiter les documents et stocker les outputs.

Un script pour exécuter les evals et reporter les résultats.

C’est tout. C’est déjà un projet très solide.

Maintenant, oui, vous pouvez utiliser Claude Code ou Cursor, ou l’outil que vous voulez. Je ne suis pas anti outils IA. C’est comme ça que beaucoup d’ingénierie moderne se fait.

Mais utilisez ça comme un pro.

Travaillez de manière itérative, step by step. Après chaque chunk, faites une pause et assurez-vous que vous comprenez. Ne cliquez pas “Yes” quand Claude vous demande de continuer automatiquement sur de nouvelles étapes. Lisez ses suggestions, son plan et ses changements. Lisez le code. Demandez-lui de le commenter clairement. Réexpliquez l’approche avec vos propres mots. Validez les dépendances et les versions pour ne pas pull un truc bizarre qui casse à l’installation. Et ne le laissez pas “aller construire un projet” pendant que vous regardez.

Et avant d’envoyer le projet. Testez-le au moins une fois dans un nouvel environnement. D’autres vont implémenter votre code dans un vrai environnement de travail. Ils doivent pouvoir suivre votre fichier markdown de setup et lancer le code sans que vous ayez à déboguer pour eux. Pareil pour les dépendances et le fait d’utiliser des versions à jour. Ici, ne faites pas confiance à ce que Claude et les autres LLMs suggèrent dès le départ ! Ils peuvent utiliser des vieilles versions. Demandez-leur de confirmer sur Google qu’ils utilisent des libraries à jour, et vérifiez par vous-même.

Parce qu’en entretien, on va vous demander pourquoi vous l’avez fait comme ça et pourquoi vous utilisez LangChain 0.3 au lieu de la version 1.

Et si la réponse, c’est : « Parce que l’agent l’a écrit », la conversation se termine assez vite.

C’est aussi pour ça que je suis têtu sur l’apprentissage par projets.

Dans notre cours Full Stack AI Engineer, le but n’est pas de mémoriser des prompts ou de collectionner des techniques. C’est de construire quelque chose de réel. Par exemple, votre propre tuteur IA avec de bonnes pratiques RAG solides, de vrais patterns de chatbot, des habitudes d’évaluation, et un workflow d’ingénierie qui se traduit directement en entretien. Vous finissez avec quelque chose que vous pouvez montrer, quelque chose que vous pouvez expliquer, et quelque chose qui ressemble au travail pour lequel les entreprises embauchent vraiment.

Si vous avez fait des projet d’entrevues comme ça récemment, j’aimerais vraiment entendre ce que vous avez eu.

On vous a demandé de construire quoi ? C’était quoi la contrainte la plus bizarre. Vous aviez combien de temps pour les faire ? Et est-ce qu’ils se souciaient plus du résultat final, ou de la manière dont vous y êtes arrivé ?

Mettez ça en commentaire. Ça aide tout le monde et ça me donne des idées pour des articles de suivi, vu que les formats varient beaucoup.