Préparer votre propre entrevue

Vous avez maintenant vu cinq personnes passer la même entrevue avec Rafael. Leurs expériences étaient très différentes : banque, agence, université, géant du nuage, logiciels de santé. Mais leurs moments forts avaient les mêmes causes. Chaque personne connaissait son système en détail, y compris ses défaillances. Elle pensait à tous les endroits où les données pouvaient passer d’un client à l’autre. Elle disait clairement ce qu’elle ne savait pas et proposait une façon de le tester.

Cela ne s’apprend pas par la lecture. Il faut pratiquer, comme pour un exercice d’évacuation. Personne n’apprend à quitter un bâtiment en sécurité en lisant le plan au mur. Vous descendez les escaliers quelques fois. Le jour venu, vous connaissez le chemin. Cette page vous propose un plan pour cette pratique. Il faut environ trois semaines de courtes séances.

Étape 1 : choisissez une offre et lisez-la attentivement

Ne vous préparez pas aux « entrevues backend » en général. Préparez-vous pour une vraie offre, puis adaptez votre préparation à la suivante. Lisez-la comme dans Lire l’offre d’emploi et Lire l’offre sans se faire d’illusions. Trouvez le problème derrière l’offre. Repérez la « ligne sur les pharmacies », celle qui révèle ce que l’équipe craint le plus. Classez les éléments en exigences, souhaits et informations manquantes, puis faites le tableau de préparation.

Vérifiez aussi le type de poste. Si l’offre demande de concevoir des requêtes et de mesurer la qualité, elle ressemble davantage à un poste d’ingénieur en IA. Notre guide Préparation aux entrevues : ingénieur en IA convient alors mieux. Si elle demande de construire les systèmes autour du modèle, restez ici.

Étape 2 : rédigez des notes détaillées sur un système dont vous êtes responsable

Choisissez le système backend (côté serveur) que vous connaissez le mieux. Pour chaque niveau ci-dessous, rédigez de courtes notes avec des chiffres réels quand vous en avez. Des chiffres approximatifs conviennent. « Environ 3 000 requêtes par minute en période de pointe, je pense » est honnête et utile.

1. Quoi et qui : que fait le système, qui l’utilise, combien de requêtes ou de tâches traite-t-il par jour?
2. Les données : quelles sont les principales tables et pourquoi sont-elles structurées ainsi? Quel index compte le plus?
3. En cas de défaillance : que se passe-t-il quand une dépendance ralentit ou tombe en panne? Où sont les délais d’expiration et les nouvelles tentatives?
4. En cas de double exécution : que se passe-t-il si la même requête ou tâche arrive deux fois? Comment le savez-vous?
5. La mise en production : comment déployez-vous un changement et comment savez-vous qu’il fonctionne après le déploiement?
6. Le pire incident : ce qui s’est passé, comment vous l’avez découvert et ce que vous avez changé ensuite.
7. À qui appartiennent les données : si plusieurs clients utilisent le système, où vérifiez-vous exactement l’identité du client?
8. Vos limites : qu’est-ce qui changerait avec une charge 100 fois plus élevée? Avec un appel à un modèle d’IA qui prend 20 secondes et coûte de l’argent au milieu du traitement? Ou avec des données qui ne doivent jamais passer d’un client à l’autre?

Aux niveaux 4 et 7, beaucoup de candidats à ce poste n’ont plus de réponses. Si vous ne pouvez pas répondre pour votre système, renseignez-vous. Lisez le code ou demandez à un collègue. Vous pouvez dire « nous ne gérons pas cela » en entrevue, tant que vous expliquez ce que vous changeriez.

Le niveau 6 compte plus que la plupart des gens le pensent. Les intervieweurs font confiance à une personne qui peut décrire une défaillance en détail. Seule une personne qui était là s’en souvient de cette façon.

Étape 3 : découvrez ce qui distingue un modèle d’une API normale

Vous n’avez pas besoin d’apprentissage automatique pour ce poste. Vous devez toutefois savoir comment un LLM se comporte comme dépendance. Si vous n’en avez jamais appelé un, consacrez une fin de semaine à un petit projet :

• Un point de terminaison FastAPI qui envoie une question à un LLM hébergé et renvoie la réponse en continu avec des événements envoyés par le serveur.
• Un délai d’expiration et un message clair à l’utilisateur quand le modèle ralentit ou échoue.
• Un décompte des jetons (tokens) pour chaque requête, enregistré avec l’identifiant du client, pour calculer le coût par client.
• Un test unitaire qui utilise un faux modèle plutôt que le vrai, pour obtenir le même résultat chaque fois.
• Un document contenant « Ignorez les instructions précédentes… » et une note sur ce que votre conception permet au modèle d’en faire.

Cette fin de semaine vous apprendra plus que bien des articles. Elle vous donnera aussi une expérience réelle à raconter en entrevue : « Je voulais comprendre la transmission en continu, alors j’ai construit une petite version. Le premier problème que j’ai trouvé était… ». Notre cours Créer et déployer votre première API couvre les bases de FastAPI. La leçon Tests automatisés des points de terminaison montre comment tester un point de terminaison sans clics manuels.

Étape 4 : pratiquez l’exercice de programmation avec IA autorisée

Beaucoup de gens préparent les exercices de programmation avec des problèmes d’algorithmes. Pour ce type d’exercice, ce n’est pas la bonne pratique. Pratiquez plutôt sur une petite base de code réelle.

Prenez une petite API, la vôtre ou une API à code source ouvert. Faites échouer deux ou trois tests volontairement, ou demandez à un ami de le faire. Corrigez-les ensuite avec votre assistant d’IA, avec une minuterie de 60 minutes. Parlez à voix haute tout le temps, comme si un intervieweur vous observait. Enregistrez votre écran et votre voix. En regardant l’enregistrement, vérifiez trois choses :

• Avez-vous lu vous-même le code et les tests avant de consulter l’outil?
• Avez-vous lu chaque ligne écrite par l’outil, et pouvez-vous l’expliquer?
• Avez-vous repéré au moins une erreur ou un oubli de l’outil? Dans du code multilocataire, cherchez d’abord les requêtes et les clés de cache sans identifiant de client.

Faites ensuite le même exercice une fois sans l’outil. Certaines entreprises interdisent l’IA dans les exercices de programmation. Vous devez pouvoir travailler des deux façons. Dans Le déroulement des entrevues, vous trouverez la liste complète des habitudes que les intervieweurs recherchent.

Étape 5 : pratiquez le problème de l’entreprise

La plupart des discussions techniques approfondies incluent un problème tiré du travail de l’entreprise. Vous pouvez généralement le deviner à partir de l’offre. Pour un poste backend dans un produit d’IA multilocataire, il comprendra très probablement certains de ces éléments : une tâche lente à déplacer en arrière-plan, des doublons, un client qui ralentit les autres, des données à isoler entre clients et une réponse transmise en continu.

Rédigez le problème attendu en deux ou trois phrases, comme celui de Rafael. Répondez-y ensuite à voix haute pendant 25 minutes, avec une minuterie. Commencez par vos questions. Suivez ensuite le parcours de la requête, de l’utilisateur au modèle et au retour. À chaque étape, dites ce qui arrive en cas d’échec ou de double exécution, et comment vous vérifiez le locataire.

Voici une façon simple de repérer tous les endroits où les données pourraient passer d’un client à l’autre. Dessinez le parcours d’une requête sur papier et écrivez l’identifiant du locataire à côté de chaque case. La base de données, le stockage des fichiers, le message dans la file, le processus, la clé de cache, le filtre de recherche, les journaux (logs), le texte envoyé au modèle. Si vous ne pouvez pas l’écrire à côté d’une case, cette case présente un risque. Vous avez vu Arash et Claire raisonner ainsi dans L’ingénieur d’une grande entreprise technologique et L’ingénieure attentive à la sécurité.

Faites cet exercice deux ou trois fois, à des jours différents. Chaque fois, vous trouverez une lacune sur laquelle vous pourrez vous renseigner avant la prochaine séance.

Étape 6 : passez une entrevue avec une personne

Pratiquer seul ne peut pas vous surprendre. Demandez à un ami ou à un ancien collègue de vous faire passer une entrevue de 45 minutes. Idéalement, choisissez un ingénieur backend. Donnez-lui votre CV et les huit niveaux de l’étape 2. Demandez-lui d’approfondir tout ce que vous dites et de demander « Comment testeriez-vous cela? » au moins trois fois. Ensuite, demandez-lui un point fort et deux choses à améliorer.

Inversez ensuite les rôles et faites-lui passer l’entrevue. Comme intervieweur, vous entendrez vite la différence entre « nous utilisions une file » et « nous utilisions une file, et après trois échecs d’une tâche, nous la déplacions dans une liste séparée que nous examinions chaque matin ».

Vous pouvez aussi pratiquer avec un assistant d’IA. Demandez-lui de jouer un intervieweur exigeant qui approfondit chaque réponse et n’accepte jamais de réponse générale. C’est une bonne pratique. C’est très différent d’utiliser l’IA dans une séance où elle est interdite. Nous vous demandons de ne jamais le faire (nos conseils).

Étape 7 : préparez-vous à vos limites

Toute bonne entrevue vous amènera aux limites de vos connaissances. Préparez-vous à cela comme à toute autre partie.

Notez trois sujets où vous pensez atteindre vos limites. Pour ce poste, les sujets courants sont la répartition équitable des tâches entre clients, les tests de sorties qui changent d’une exécution à l’autre et l’injection de requêtes. Pour chaque sujet, écrivez ce que vous savez et comment vous découvririez le reste. Puis pratiquez à le dire : « Je n’ai pas construit ça. Ce que je sais, c’est… Si je devais décider aujourd’hui, je commencerais par… et je le testerais en… ». Vous avez vu Samuel le faire pour les tests, et Claire pour les files équitables.

Préparez-vous aussi à l’autre type de limite : quand l’intervieweur dit quelque chose que vous pensez être faux. Vous avez vu Arash contredire poliment Rafael sur la sécurité au niveau des lignes. Connaissez assez bien vos principaux sujets pour justifier votre point de vue et accepter un bon contre-argument. Consultez nos conseils sur les désaccords.

Étape 8 : préparez vos questions

Rédigez deux ou trois questions pour chaque étape, à partir de votre tableau de préparation et des questions de Lire l’offre avec honnêteté. Pour ce poste, posez des questions sur la garde, la responsabilité des défaillances entre ingénieurs backend et ingénieurs en IA, le coût par client et les migrations prévues. Ces questions montrent que vous pensez comme quelqu’un qui fera le travail. Elles vous donnent aussi l’information nécessaire pour décider. Arash a demandé à quoi ressemble une semaine normale. La réponse l’a aidé à décider que ce poste ne lui convenait pas.

Le jour de l’entrevue

• Au début de chaque séance, demandez ce qui est permis : notes, documentation, tableau blanc, assistant d’IA. Respectez ensuite les règles exactement.
• Pour l’exercice de programmation, testez votre éditeur, votre outil d’IA et l’environnement partagé la veille. Si vous devez utiliser leur environnement, demandez l’accès tôt.
• Pour une entrevue vidéo, testez votre caméra, votre microphone et le partage d’écran. Fermez tout ce dont vous n’avez pas besoin.
• Il est normal de dire « Laissez-moi réfléchir une minute » et de réfléchir en silence. Vous avez vu Minh le faire. Il est aussi normal de poser une question quand celle qu’on vous pose n’est pas claire.
• Gardez du papier et un stylo près de vous. Dessinez le parcours de la requête quand cela vous aide.

Après l’entrevue

Notez chaque question difficile le jour même, pendant que vous vous en souvenez. Pratiquez ensuite ces questions. Si votre candidature n’a pas été retenue, demandez poliment des commentaires. Toutes les entreprises n’en donnent pas, mais une phrase honnête peut valoir des semaines de lecture.

Rappelez-vous qu’une partie du résultat échappe à votre contrôle (nos conseils). Dans ce guide, Casewell avait un seul poste vacant et plusieurs candidatures solides. Samuel a très bien réussi, mais n’a pas rejoint l’entreprise pour des raisons sans lien avec son entrevue. Continuez et gardez votre plan centré sur les postes que vous voulez.

Un plan de trois semaines

Ce plan prévoit environ une heure la plupart des jours, en parallèle d’un emploi ou d’autres études.

Semaine	Travail principal	À voix haute
1	Lisez l’offre et faites le tableau de préparation. Rédigez les notes détaillées sur votre système, des niveaux 1 à 8. Trouvez les réponses manquantes aux niveaux 4 et 7.	Enregistrez deux fois une présentation de deux minutes de votre système.
2	Construisez le petit projet LLM avec transmission en continu de l’étape 3, avec un faux modèle dans les tests. Préparez vos trois sujets limites et vos questions.	Un exercice de programmation avec IA autorisée, enregistré. Répondez une fois au problème de l’entreprise, avec une minuterie.
3	Relisez vos notes. Corrigez ce que la pratique a révélé. Faites un exercice de programmation sans IA.	Répondez de nouveau au problème de l’entreprise. Faites une entrevue simulée avec une personne, puis une autre après avoir corrigé les points signalés.

Postulez ensuite et gardez vos notes. La prochaine offre demandera seulement quelques changements.