Le déroulement des entrevues

Imaginez que vous cherchez quelqu’un pour réparer le câblage électrique de votre maison. Un électricien vous donne une liste de certificats. Un autre dit : « Le mois dernier, j’ai refait le câblage d’une cuisine dans une vieille maison. Les anciens fils n’avaient pas de mise à la terre, alors j’ai d’abord… » Vous demandez : « Pourquoi avez-vous fait les choses dans cet ordre? », et il vous explique. Puis vous demandez : « Et si le panneau électrique est trop petit? » Il réfléchit un moment et vous dit honnêtement ce qu’il vérifierait. Après dix minutes, vous faites beaucoup plus confiance au deuxième électricien. Les certificats ne vous ont pas aidé à décider.

Une entrevue technique sérieuse fonctionne de la même façon. La personne qui mène l’entrevue écoute ce que vous avez construit. Puis elle pose des questions, une après l’autre, jusqu’aux limites de vos connaissances. Cette page explique cette approche, les cinq entrevues du processus de Casewell et l’épreuve de programmation avec un assistant d’IA. Vous serez ensuite prêt pour la partie 3, où cinq candidats passent la même entrevue technique.

Les cinq entrevues chez Casewell

L’offre de Casewell décrit son processus. La plupart des offres ne le font pas. Si la vôtre ne le fait pas, demandez au recruteur dès le départ. Chaque entrevue vérifie un aspect différent, avec une personne différente.

1. L’appel avec le recruteur (30 minutes, Ben Okoro, recruteur). Ben vérifie les éléments de base : votre expérience, votre niveau, vos attentes salariales et votre disponibilité. Il vérifie aussi si vous pouvez expliquer votre travail à quelqu’un qui n’est pas ingénieur. Il vous parle également de l’entreprise. Préparez une présentation d’une minute, votre fourchette salariale et vos questions. C’est le meilleur moment pour poser des questions sur les périodes de garde et les règles de l’épreuve de programmation.

2. La programmation pratique (75 minutes, un des ingénieurs backend de l’équipe). Vous recevez un petit service FastAPI dans un dépôt partagé, avec des tests qui échouent. Vous corrigez les problèmes et ajoutez peut-être une petite fonctionnalité. Un assistant de programmation par IA est permis. La personne qui mène l’entrevue observe comment vous vérifiez ce qu’il écrit. Nous examinons cette épreuve en détail plus bas.

3. L’exploration technique approfondie et la conception (60 minutes, en vidéo, Rafael Mendes, ingénieur expert). C’est l’entrevue de la partie 3 de ce guide. Rafael vous questionne sur un système backend que vous avez construit ou dont vous êtes responsable, et l’explore en profondeur. Puis il vous présente le vrai problème de Casewell et vous demande comment vous le reconcevriez. Aucun outil d’IA dans cette entrevue. Il s’agit seulement d’une conversation.

4. La conception de système (60 minutes, Anjali Desai, ingénieure principale). Anjali vous demande de concevoir un système complet pour les 400 clients. Vous rédigez d’abord un court document de conception dans un fichier partagé, puis vous en discutez avec elle. Elle examine les compromis : ce qui arrive en charge maximale, ce qui tombe en panne en premier et les coûts. Elle examine aussi comment vous le mettez en production sans danger et comment vous savez qu’il fonctionne.

5. La conversation sur les valeurs (45 minutes, Marguerite Hall, responsable de la réussite client). Marguerite était avocate avant de se joindre à Casewell. Elle vous demande comment vous réagissez dans des situations difficiles : un client qui découvre un bogue grave, une échéance incompatible avec la qualité ou un désaccord avec un collègue. Elle vérifie que vous comprenez ce que signifie la confidentialité pour un cabinet d’avocats. Vous pouvez aussi vous renseigner sur les périodes de garde et le rythme réel de l’équipe.

Après la dernière entrevue, les personnes qui les ont menées se réunissent pour un bilan. Chacune partage ses notes écrites. Nora Lindgren, la gestionnaire de l’ingénierie qui recrute, prend la décision avec elles. Un bon résultat dans une épreuve n’annule pas une inquiétude sérieuse soulevée dans une autre.

D’autres types d’entrevues possibles

D’autres entreprises utilisent d’autres épreuves pour les postes backend dans les produits d’IA :

• La programmation sans aide de l’IA. À la fin de 2025, un sondage sectoriel auprès de responsables de l’ingénierie a constaté que près de deux entreprises sur trois interdisaient encore l’IA en entrevue. Ne présumez donc rien. Posez la question avant chaque épreuve de programmation.
• Le débogage ou la révision de code. Vous recevez du code contenant des bogues ou une demande de tirage (pull request) à réviser. Vous expliquez ce qui ne va pas et pourquoi.
• Un travail à faire à la maison. Vous construisez quelque chose de petit chez vous, par exemple une API avec une tâche en arrière-plan. Ces travaux sont moins courants qu’avant.
• Un essai de travail rémunéré. Quelques entreprises demandent aux finalistes de travailler avec l’équipe pendant quelques jours rémunérés.

Une épreuve qui permet l’IA a des règles claires. Une épreuve qui l’interdit aussi. Suivez-les exactement (nos conseils).

L’épreuve de programmation qui permet l’IA

Pensez à un examen de conduite dans une voiture équipée d’une application de navigation. L’application est permise. Elle vous indique où tourner. Mais l’examinateur ne teste pas l’application. Il observe votre regard : vérifiez-vous le rétroviseur? Voyez-vous le cycliste que l’application ne connaît pas? Vous arrêtez-vous quand l’application dit « tournez à gauche » dans une rue interdite d’accès?

L’épreuve de programmation qui permet l’IA fonctionne de la même façon. La personne qui mène l’entrevue sait déjà que l’outil peut écrire du code. Elle veut vous voir utiliser l’outil ouvertement, vérifier sa sortie et expliquer vos décisions. Les candidats qui acceptent tout ce que l’outil écrit réussissent mal cette épreuve, même si les tests passent.

Voici comment bien travailler dans cette épreuve :

• Demandez d’abord les règles. Quels outils sont permis? Pouvez-vous utiliser votre propre configuration, ou seulement celle de l’environnement partagé? L’outil peut-il voir tout le dépôt?
• Lisez avant de demander. Passez les premières minutes à lire vous-même le code et les tests qui échouent. Dites ce que vous voyez : « Le test attend un 409 quand le même fichier est téléversé deux fois. Actuellement, on renvoie 201. »
• Dites ce que vous allez demander à l’outil, et pourquoi. « Je vais lui demander d’écrire la vérification des doublons, parce que c’est du code monotone. Ensuite, je vais le lire attentivement. »
• Lisez chaque ligne qu’il écrit. De petites étapes soigneuses valent mieux qu’un grand bloc. Si vous ne pouvez pas expliquer une ligne, ne la gardez pas.
• Cherchez ce que les outils oublient souvent dans ce type de produit. Dans un service multilocataire, l’erreur la plus courante est une requête de base de données ou une clé de cache sans locataire. Vérifiez aussi la gestion des erreurs et ce qui arrive quand la même requête arrive deux fois. Vérifiez si un secret ou le texte d’un document se retrouve dans un journal.
• Exécutez les tests et ajoutez-en un. Une suite de tests qui passe n’est pas une preuve. Ajoutez un petit test pour le cas qui vous inquiète, par exemple « le locataire A ne peut pas lire le document du locataire B ».
• Dites quand vous rejetez sa suggestion. « Il veut intercepter toutes les exceptions ici. Je n’aime pas ça, on cacherait de vraies erreurs. Je vais intercepter seulement le dépassement du délai. »
• Travaillez sans l’outil quand c’est plus rapide. Personne ne vous donne de points pour l’utiliser le plus possible.

Voici un court passage d’une épreuve de programmation comme celle-ci.

Un exemple : vérifier la sortie de l'assistant

Candidat(personne candidate) :

Bon, il a écrit la requête. Je vais la lire… Hmm. Elle sélectionne le document seulement par son identifiant.

Interviewer(intervieweur) :

Hum-hum.

Candidat(personne candidate) :

Donc, si je connais l’identifiant du document d’un autre client, je peux récupérer son document. Les tests passent parce qu’ils utilisent tous le même locataire. Je vais ajouter l’identifiant du locataire à la requête. Et je vais aussi écrire un test avec deux locataires.

Interviewer(intervieweur) :

Vous ne feriez pas confiance à la base de données pour ça? On a une sécurité au niveau des lignes.

Candidat(personne candidate) :

Peut-être que ça fonctionne ici. Je ne sais pas comment c’est configuré dans ce dépôt. Mais je préfère avoir les deux. Si une protection échoue, l’autre nous protège encore. Et le test le montre en quelques secondes.

Pourquoi cela fonctionne

Le candidat ne cache pas l’erreur de l’outil et ne lui rejette pas non plus la faute. Il lit le code, explique le risque en une phrase, le corrige et ajoute un test qui prouve la correction. La question sur la sécurité au niveau des lignes est une petite vérification : le candidat dépend-il d’une seule couche? C’est exactement ce que cette épreuve cherche à vérifier.

Comment une personne qui mène une entrevue sérieuse approfondit les questions

Revenons maintenant à l’exploration approfondie avec Rafael. Elle commence par une question ouverte : « Parlez-moi d’un système backend que vous avez construit ou dont vous êtes responsable. » Ensuite, Rafael suit votre réponse. Supposons qu’un candidat dise :

« J’ai construit le service qui reçoit les événements de paiement de notre fournisseur de paiement et met à jour les commandes. »

Une phrase peut mener à vingt minutes de conversation, niveau par niveau :

D'une phrase aux limites des connaissances

1. 1

   « Combien d'événements par jour, et que fait le service avec chacun? »

   Le système est-il réel, et quelle est sa taille? Les vrais systèmes ont de vrais chiffres, même approximatifs.

2. 2

   « Que se passe-t-il si le fournisseur envoie le même événement deux fois? »

   L'idempotence : exécuter la même requête deux fois donne le même résultat qu'une seule fois. Seule une personne qui l'a construit sait comment elle l'a fait.

3. 3

   « Et si votre base de données est indisponible pendant deux minutes quand un événement arrive? »

   La gestion des pannes : nouvelles tentatives, attente plus longue entre les tentatives, endroit pour les événements qui échouent toujours.

4. 4

   « Comment déployez-vous un changement, et comment savez-vous qu'il fonctionne après le déploiement? »

   Le candidat exploite-t-il le système, ou écrit-il seulement du code pour celui-ci?

5. 5

   « Parlez-moi du pire incident avec ce service. »

   Peut-il décrire une vraie panne en détail et ce qu'il a changé par la suite?

6. 6

   « Imaginez maintenant que chaque événement prend 30 secondes à traiter et coûte de l'argent. Un client en envoie dix mille à la fois. Qu'est-ce qui change? »

   La limite : Rafael passe de l'expérience du candidat au problème de Casewell et observe son raisonnement.

La personne qui mène l’entrevue prévoit les sujets à explorer, pas les questions exactes. Les questions viennent de vos réponses. Un candidat qui dit « On stocke l’identifiant de l’événement avec un index unique » reçoit une question sur cet index. Un candidat qui dit « Le cadriciel gère les doublons » reçoit la question « Comment? Montrez-moi ce qu’il fait. »

N’apprenez donc pas des listes de questions. Connaissez très bien votre propre travail : chaque décision, chaque chiffre, chaque panne.

Les limites de vos connaissances

Chaque candidat atteint une limite. Une bonne personne qui mène des entrevues y va volontairement, parce que l’information la plus utile se trouve là. Elle observe ce que vous faites quand vous ne savez pas :

• Dites-vous clairement que vous ne savez pas, ou évitez-vous de le dire?
• Raisonnez-vous à partir de ce que vous savez, étape par étape, à voix haute?
• Posez-vous une question qui clarifie le problème?
• Restez-vous calme et honnête?

Voici un court exemple.

Un exemple : atteindre la limite

Rafael(intervieweur) :

La réponse arrive en continu dans le navigateur, et l’utilisateur ferme l’onglet. Qu’arrive-t-il à l’appel au modèle sur votre serveur?

Candidat(personne candidate) :

Hmm. Honnêtement, je ne suis pas sûr. Je n’ai jamais testé ce cas.

Rafael(intervieweur) :

D’accord. Qu’en pensez-vous?

Candidat(personne candidate) :

Je vais réfléchir… Le serveur écrit sur la connexion, la connexion est fermée, donc à un moment l’écriture échoue. Mais l’appel au modèle est séparé. Je pense qu’il peut continuer, et qu’on paie encore pour tous les jetons (tokens). À moins de détecter la déconnexion et de l’annuler.

Rafael(intervieweur) :

Et comment sauriez-vous ce qui se passe vraiment?

Candidat(personne candidate) :

Je le testerais. Un faux modèle qui envoie un mot chaque seconde. Je ferme le client après deux secondes, et je vérifie si on demande encore des mots au faux modèle. C’est peut-être une heure de travail.

Pourquoi cela fonctionne

Le candidat dit exactement où ses connaissances s’arrêtent. Il raisonne ensuite à partir de ce qu’il sait et trouve le vrai risque. Le serveur pourrait continuer de payer pour une réponse que personne ne lit. Il propose un petit test qui donnerait la réponse. Le test compte ici, car la vraie réponse dépend du code de votre serveur et du fournisseur du modèle. Avec certains fournisseurs, fermer la requête arrête la génération; avec d’autres, ce n’est pas nécessairement le cas. Rafael demande souvent « Comment testeriez-vous ça? », et un test concret est la réponse la plus solide.

Votre anglais n’a pas besoin d’être parfait

Pour beaucoup de personnes dans ce processus, l’anglais est une deuxième ou une troisième langue. C’est aussi le cas de Rafael : il a grandi au Portugal. Une bonne personne qui mène des entrevues écoute votre raisonnement, pas la perfection de votre grammaire. Si vous ne comprenez pas une question, demandez : « Excusez-moi, pouvez-vous répéter? » ou « Vous parlez du téléversement ou du clavardage? » Si vous perdez le fil, dites-le et recommencez. C’est beaucoup mieux qu’une longue réponse à la mauvaise question. Consultez nos conseils pour en savoir plus. Dans la partie 3, vous verrez plusieurs candidats dont l’anglais n’est pas la langue maternelle, et combien cela compte peu.

Le problème de Casewell

Dans la deuxième moitié de l’exploration approfondie, Rafael présente le même problème à chaque candidat. C’est la vraie raison pour laquelle l’équipe recrute :

« Maintenant, notre vrai problème. Au début d’une transaction, un cabinet d’avocats téléverse jusqu’à 2 000 contrats à la fois. Aujourd’hui, on les traite dans la requête de téléversement. Le délai expire, les gens téléversent encore, et on obtient des doublons. Le mois dernier, un gros téléversement a ralenti tous les autres clients pendant des heures. Et — je vais être honnête avec vous — on a eu un incident. Un client a vu du texte du document d’un autre client dans une réponse de clavardage. C’était un bogue de cache, corrigé maintenant. Comment reconcevriez-vous le traitement des documents et le clavardage pour empêcher ces problèmes? »

Cette question contient trois problèmes : des téléversements lents qui créent des doublons, un client qui ralentit tout le monde et des données qui passent d’un client à un autre. Il n’y a pas une seule bonne réponse. Rafael ne s’attend pas à une conception terminée en 25 minutes. Il veut voir par où vous commencez et quelles questions vous posez. Il veut savoir comment vous rendez chaque partie sûre à relancer et où vous vérifieriez le locataire. Ensuite, il suit votre réponse, comme pour votre propre projet.

Essayez avant de lire les réponses des candidats

Prenez 25 minutes. Écrivez, ou dites à voix haute, comment vous aborderiez le problème de Casewell. Utilisez ce que vous avez appris dans Lire l’offre sans se faire d’illusions. Répondez à ces questions pour vous-même :

1. Quelles sont les deux ou trois questions que vous poseriez à Rafael avant de proposer quoi que ce soit?
2. Que devrait faire la requête de téléversement, et que devrait-il se passer plus tard, en arrière-plan?
3. Si un utilisateur téléverse encore les mêmes 2 000 fichiers, comment le système le sait-il?
4. Comment empêchez-vous le téléversement d’un client de ralentir tous les autres?
5. Listez tous les endroits où les données d’un client pourraient atteindre un autre client. Pensez au-delà de la base de données : caches, recherche, tâches en arrière-plan, journaux (logs) et texte envoyé au modèle.
6. Comment testeriez-vous que le bogue de cache ne peut pas revenir?

Gardez vos notes. Quand vous lirez les cinq candidats, comparez. Chaque candidat part de sa propre expérience. C’est normal, et vous devriez faire la même chose.

Comment lire les pages des candidats

Chaque page de candidat présente la même entrevue de 60 minutes avec Rafael, sous forme de conversation. Les interventions en bleu sont celles de la personne qui mène l’entrevue. Les interventions en vert sont celles du candidat. Entre les interventions, des notes expliquent ce qui se passe :

• Ce que la personne qui mène l’entrevue vérifie : la vraie question derrière la question.
• Comment elle approfondit les questions : pourquoi la question suivante découle de la réponse.
• Pourquoi ça fonctionne : ce qui rend une réponse solide.
• Où ça se passe mal : un moment faible, et pourquoi il l’est.
• Une réponse plus solide : le même moment, avec une meilleure réponse, dans les mots du candidat.
• Bien exprimer un désaccord : comment un candidat exprime un désaccord avec la personne qui mène l’entrevue, avec des raisons.

Chaque page se termine par les notes écrites de Rafael, la suite des événements et des conseils pour des profils semblables. Chaque candidat a des moments forts et des moments faibles, comme tous les vrais candidats. Casewell a un seul poste vacant. Les cinq histoires se terminent donc différemment, et pas toutes avec une offre de Casewell.

Les cinq candidats sont :

1. L’ingénieur d’entreprise : Samuel a neuf ans d’expérience en systèmes de paiement dans une banque et n’a jamais construit de fonctionnalité avec un LLM.
2. La développeuse full-stack : Emily construit rapidement et a de nombreux projets d’IA. Ses connaissances backend sont moins approfondies que son CV le laisse croire.
3. Le nouveau diplômé : Minh a terminé son diplôme en mai, avec un stage et des bases solides.
4. L’ingénieur d’une grande entreprise technologique : Arash connaît les systèmes distribués à très grande échelle et n’a jamais été responsable d’un produit avec des clients.
5. L’ingénieure attentive à la sécurité : Claire a construit un logiciel de dossiers médicaux avec des règles strictes de confidentialité, et une fonctionnalité avec un LLM.

Lisez-les dans n’importe quel ordre. Commencez par la personne qui vous ressemble le plus, puis lisez celle qui vous ressemble le moins.