À retenir
- Les entrevues en ingénierie IA ne sont pas seulement un jeu-questionnaire. Elles testent votre façon de raisonner devant des systèmes et des contraintes désordonnés.
- Un projet à faire à la maison montre plus que la qualité des outputs. Il montre les décisions, les compromis, le débogage et la communication.
- Les meilleurs candidats peuvent expliquer ce qu’ils ont construit, pourquoi ils l’ont construit ainsi et comment ils l’amélioreraient.
Une question qu’on me pose tout le temps : « Comment me préparer aux entrevues en ingénierie IA? »
Et récemment, elle est généralement accompagnée de « J’entends constamment dire que les gens reçoivent des projets à faire à la maison en 24 heures. Sur quoi devrais-je m’exercer pour ne pas paniquer lorsque j’en recevrai un? »
P.-S. Vous pouvez regarder la version vidéo de cet article ici! Pensez à l’essayer et à soutenir la chaîne en vous abonnant et en laissant un court commentaire. Regardez ma vidéo de conseils pour les entrevues en IA ici.
La plupart des gens se préparent comme si les entrevues étaient un jeu-questionnaire. Ils rassemblent une liste géante de questions. Ils mémorisent des définitions. Ils font quelques problèmes LeetCode. Tout cela est utile, bien sûr, surtout pour certaines entrevues de code bien particulières à l’ancienne, mais ça passe à côté de ce que les projets à faire à la maison évaluent réellement.
Dans un projet à faire à la maison, l’output compte. Mais votre façon de penser compte davantage. Et je dis cela après avoir reçu, honnêtement, plus d’une centaine de candidats potentiels en entrevue pour nos postes en ingénierie IA chez Towards AI.
La façon dont vous clarifiez une spécification vague et cherchez plus d’information avant de continuer ou, à l’opposé, formulez de bonnes hypothèses avec plusieurs scénarios. La façon dont vous choisissez une baseline. La façon dont vous évaluez. La façon dont vous documentez les compromis. La façon dont vous montrez que vous pouvez livrer quelque chose de réel, même si c’est petit. Et honnêtement, parfois, la façon dont vous montrez que vous n’avez pas pu livrer, pourquoi et ce que vous feriez ensuite. Voilà ce que nous recherchons dans le test. Pas l’application finale fonctionnelle que Claude a faite pour vous.
Et si vous voulez vous y préparer, voici une vérité utile sur plusieurs projets à faire à la maison. Ils proviennent souvent d’un besoin réel de l’entreprise qu’elle n’a pas eu le temps d’explorer. Une comparaison qu’elle veut effectuer depuis un moment. Un proof of concept rapide pour vérifier si quelque chose fonctionne dans son setup. Un petit outil interne qu’elle pourrait conserver s’il est assez bon. C’est pourquoi la consigne est souvent un peu vague. Le vrai travail est vague. C’est justement le but.
J’ai récemment reçu un email d’un étudiant de notre cours Full Stack AI Engineer. Il postulait à des emplois et ses amis recevaient ces projets de 24 heures. Il voulait une idée d’exercice réaliste à faire pendant une fin de semaine, surtout avec les outils modernes et les meilleures pratiques.
Et je lui ai dit qu’il est difficile de prévoir exactement ce que chaque entreprise demandera, parce que c’est impossible. Mais vous pouvez vous entraîner à reproduire le pattern.
Je lui ai donc donné une idée de projet très proche d’un besoin qui compte réellement dans notre travail avec des clients et que j’ai aussi utilisée récemment pour tester un candidat.
Construisez un pipeline OCR simple de traitement de documents.
Pas un notebook Colab. Pas une démo qui fonctionne seulement avec un exemple parfait. Un petit pipeline que vous pouvez exécuter de bout en bout pour traiter un vrai document numérisé, l’évaluer et l’expliquer.
Je n’ai pas vraiment donné plus de détails, mais voici ce qu’un autre gestionnaire ou moi rechercherions :
La première étape consiste à choisir environ dix documents. Rendez le projet concret. Choisissez un seul type, mais gardez une certaine variation au sein de celui-ci. Par exemple, dix factures provenant de différents fournisseurs. Ou dix CV. Ou dix recettes numérisées. Ou dix formulaires médicaux si vous voulez ajouter du piquant, mais restez éthique et évitez les données sensibles. Ce point est aussi évalué! Vous pourriez documenter la façon dont vous évitez d’envoyer des données privées à l’API de Gemini, ou expliquer que c’est justement pourquoi vous utilisez un modèle local, etc.
Utilisons des factures parce qu’elles sont faciles à comprendre et qu’elles vous obligent à gérer des mises en page désordonnées.
Vos dix factures pourraient comprendre un PDF moderne et propre, une page numérisée de mauvaise qualité, une facture avec un grand tableau de postes détaillés, une autre avec un format de devise étrange et une autre avec une note manuscrite quelque part. Vous voulez cette variation. Elle est réaliste et vous oblige à construire quelque chose de robuste.
Vous décidez ensuite des champs à extraire. Gardez la liste courte. Un bon ensemble pourrait comprendre le nom du fournisseur, le numéro de facture, la date de la facture, le montant total, le montant des taxes et la devise. Si vous voulez une donnée sous forme de tableau, ajoutez les postes détaillés, mais seulement comme objectif supplémentaire. En 24 heures, bien livrer les champs principaux est déjà une réussite. Travaillez ensuite sur les ajouts ou rédigez simplement une liste claire des tâches restantes dans des issues Git, avec une bonne documentation, en supposant que quelqu’un D’AUTRE prendra la suite. Elles doivent donc être lisibles et faciles à exécuter, PAS SEULEMENT PAR VOUS! Documentez le tout correctement et clairement. Et ici, Claude Code peut très bien le faire pour vous!
Vous définissez maintenant votre output cible. Cela semble évident, mais c’est là que beaucoup de gens perdent de vue les résultats intéressants. Vous voulez un schéma structuré que vous pouvez stocker et évaluer. Quelque chose comme un enregistrement de document avec des métadonnées et un ensemble de champs extraits avec des types. Quelque chose que vous pourrez ensuite mesurer.
Par exemple, l’output extrait de chaque facture pourrait ressembler à ceci :
VendorName en texte
InvoiceNumber en texte
InvoiceDate comme chaîne de date dans un format unique et cohérent
TotalAmount comme nombre
TaxAmount comme nombre
Currency comme code à trois lettres
Cela devient votre contrat. Votre système remplit ces champs ou ne les remplit pas. Et lorsqu’il ne les remplit pas, ou qu’il les remplit incorrectement, vous pouvez le mesurer.
Vous construisez maintenant le pipeline. Dans sa forme la plus simple, c’est l’OCR plus l’extraction. Construisez-le d’abord comme bon vous semble. Mais essayez d’obtenir une baseline fonctionnelle. Elle n’a vraiment pas besoin d’être idéale. Faites simplement une recherche rapide pour trouver les meilleurs systèmes open source d’extraction de mots-clés ou même des systèmes basés sur une 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 effectuer l’extraction avec un modèle de langage, des règles ou un mélange des deux. Le point clé est de produire des données structurées de façon fiable, pas un paragraphe qui semble correct jusqu’au moment où vous essayez de le parser. Honnêtement, vous pourriez simplement utiliser l’API de Gemini, puisqu’elle traite les images, et lui demander d’extraire les champs recherchés avec un bon prompt. C’est un bon point de départ.
Puis vient la partie qui rend le projet prêt pour une entrevue.
Vous mesurez, vous comparez les approches et/ou vous documentez la façon dont vous procéderiez ensuite, selon le temps disponible.
Comparez-en au moins deux. Par exemple, un modèle OCR à l’état de l’art A et un modèle vision-LLM B pour l’OCR. Ou un pipeline OCR open source et une baseline qui consiste à envoyer l’image à ChatGPT et à lui demander d’extraire les champs. Je ne vous dis pas de compter là-dessus en production. Je vous dis que c’est une excellente baseline en entrevue, parce qu’elle montre que vous comprenez la mesure et les compromis.
Vous définissez ensuite l’évaluation. Gardez-la simple et quantitative. Pour chaque document, avez-vous correctement extrait le nom du fournisseur? Avez-vous correctement extrait le numéro de facture? 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 la vérité terrain de votre petit ensemble de test. Ici, cela signifie simplement extraire l’information vous-même ou prendre ce que ChatGPT vous a donné et vérifier en le relisant que tout est correct.
Si vous avez dix documents et six champs, cela représente soixante extractions de champs. Vous pouvez littéralement rapporter « l’approche A a obtenu 44 résultats corrects sur 60 et l’approche B, 51 sur 60 ». Examinez ensuite les échecs, vérifiez ce qui a mal tourné et rédigez une très courte analyse. Peut-être que les dates de facture échouent sur deux documents à cause du format. Peut-être que les totaux échouent parce que l’OCR n’a pas détecté une décimale. Voilà exactement le genre d’analyse que les intervieweurs veulent voir. Elle montre que vous vous êtes assez investi pour prendre le temps de comprendre et d’enquêter, plutôt que de simplement prompter et attendre.
Si vous avez encore du temps, rendez le projet encore plus réel en sauvegardant les outputs dans une base de données. Encore une fois, gardez ça simple et ennuyant. Une base de données SQLite locale convient parfaitement. Une table pour les documents, une pour les résultats extraits et peut-être une pour les résultats d’évaluation. Cela montre que vous pensez comme un ingénieur. Cela facilite aussi les nouvelles exécutions et les comparaisons. Montrer que vous savez utiliser Git et des services cloud pour tout cela est un bonus que nous aimons aussi voir. Le projet devient également facile à transmettre à d’autres.
Et vous rédigez 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 dans un vrai contexte de travail.
Pour cet exemple, deux scripts suffisent.
Un script pour traiter les documents et stocker les outputs.
Un script pour exécuter les évaluations et présenter les résultats.
C’est tout. C’est déjà un très bon projet à faire à la maison.
Maintenant, oui, vous pouvez utiliser Claude Code, Cursor ou l’outil que vous préférez. Je ne suis pas contre les outils d’IA. C’est ainsi qu’une grande partie de l’ingénierie moderne se fait.
Mais utilisez-le comme un professionnel.
Travaillez de façon itérative, étape par étape. Après chaque bloc, arrêtez-vous et assurez-vous de le comprendre. Ne cliquez pas sur « Yes » lorsque Claude vous demande de continuer automatiquement vers de nouvelles étapes. Lisez ses suggestions, son plan et ses modifications. Lisez le code. Demandez-lui de le commenter clairement. Réexpliquez l’approche dans vos propres mots. Validez les dépendances et leurs versions afin de ne pas installer quelque chose d’étrange qui fera échouer l’installation. Et ne le laissez pas « construire tout le projet » pendant que vous regardez.
Et avant d’envoyer le projet à faire à la maison, testez-le au moins une fois dans un nouvel environnement. D’autres personnes implémenteront votre code dans un vrai environnement de travail. Elles doivent pouvoir suivre votre fichier Markdown d’installation et exécuter le code sans que vous ayez à le déboguer pour elles. Même chose pour les dépendances et l’utilisation de versions à jour. Ici, ne faites pas confiance d’emblée à ce que Claude et les autres LLMs suggèrent! Ils pourraient utiliser de vieilles versions. Demandez-leur de confirmer sur Google qu’ils utilisent des librairies à jour et vérifiez-le vous-même.
Parce qu’en entrevue, on vous demandera pourquoi vous avez procédé ainsi et pourquoi vous utilisez LangChain 0.3 au lieu de la version 1.
Et si la réponse est « parce que l’agent l’a écrit », cette conversation se termine assez rapidement.
C’est aussi pourquoi j’insiste autant 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. Il est de construire quelque chose de réel. Par exemple, votre propre tuteur IA avec de solides pratiques RAG, de vrais patterns de chatbot, des habitudes d’évaluation et un workflow d’ingénierie qui se transpose directement aux entrevues. Vous obtenez quelque chose que vous pouvez montrer, quelque chose que vous pouvez expliquer et quelque chose qui ressemble au travail pour lequel les entreprises embauchent réellement.
Si vous avez fait des projets à faire à la maison récemment, j’aimerais vraiment savoir ce qu’on vous a demandé.
Qu’avez-vous dû construire? Quelle était la contrainte la plus étrange? Combien de temps aviez-vous pour les réaliser? Et l’entreprise accordait-elle plus d’importance au résultat final ou à la façon dont vous y êtes arrivé?
Écrivez-le dans les commentaires. Cela aide tous les autres et me donne des idées pour de prochains articles, puisque les formats varient énormément.
FAQ
Qu’est-ce qui se démarque lors de l’embauche d’ingénieurs IA?
Un jugement clair, du débogage pratique, une bonne communication, un sens du produit et la capacité d’évaluer le comportement des modèles se démarquent.
Comment les candidats devraient-ils se préparer aux projets à faire à la maison?
Entraînez-vous à construire de petits systèmes d’IA de bout en bout, à documenter les compromis, à écrire des tests et à expliquer ce qui a échoué.
Qu’est-ce que les candidats oublient souvent?
Ils se concentrent sur les définitions ou les démos soignées, mais négligent l’évaluation, l’analyse des erreurs et la raison pour laquelle leurs choix de conception comptent.
Pourquoi les candidats devraient-ils expliquer leur choix de modèle?
L’explication montre s’ils ont compris les contraintes de la tâche ou simplement accepté ce qu’un agent a généré.
Comment un projet à faire à la maison peut-il démontrer un bon jugement sur la confidentialité?
Documentez les données qui quittent le système, la raison du choix d’un modèle local ou hébergé et la façon dont les inputs sensibles sont protégés.
Pourquoi un projet d’IA à faire à la maison devrait-il commencer par une baseline simple?
Une baseline fonctionnelle vous donne quelque chose de mesurable à améliorer et facilite l’explication de vos choix ultérieurs de modèle, de confidentialité, de coûts et d’architecture.