Préparer votre propre entrevue

Vous avez maintenant vu cinq personnes passer la même entrevue sur les pipelines. Leurs parcours étaient très différents : intelligence d’affaires, services backend, outils modernes gérés, 24 ans de travail sur les données et exploitation des compteurs. Mais leurs bons moments avaient les mêmes causes. Chaque personne connaissait son pipeline en détail. Elle savait ce qui arrive quand il s’exécute deux fois et quand les données arrivent en retard. Elle disait clairement ce qu’elle ne savait pas. Et elle parlait des personnes qui utilisent les données, pas seulement des outils.

Rien de tout cela ne s’apprend en lisant. Il faut pratiquer, comme pour apprendre à conduire. Vous pouvez lire les règles pendant des semaines. Mais vous apprenez dans la voiture, avec quelqu’un à côté qui dit « tournez à gauche ici ». Cette page vous propose un plan pour pratiquer. Il demande environ trois semaines de courtes séances.

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

Ne vous préparez pas aux « entrevues d’ingénieur de données » en général. Préparez-vous pour une vraie offre, puis adaptez votre préparation à la suivante. Lisez-la comme vous l’avez vu dans L’offre d’emploi et Lire l’offre avec lucidité.

Les offres d’ingénieur de données présentent un problème particulier : la longue liste d’outils. Ne la laissez pas dicter votre préparation. Regroupez les outils selon leur fonction. Essayez de deviner lequel de chaque groupe l’équipe utilise vraiment. Puis posez la question à la personne responsable du recrutement. Consacrez votre temps aux idées derrière les outils, car les entrevues portent sur ces idées. Qu’est-ce qu’une nouvelle donnée? Une donnée en retard? Qu’arrive-t-il à la deuxième exécution? Que représente une ligne?

Cherchez aussi ce que l’offre ne dit pas. Beaucoup d’offres ne mentionnent ni les périodes de garde ni les coûts. Notez ces questions pour la personne responsable du recrutement.

Étape 2 : rédigez des notes détaillées sur vos pipelines

Choisissez le ou les deux pipelines dont vous parlerez. Pour chacun, rédigez de courtes réponses aux questions qu’une personne menant une entrevue sérieuse posera. Utilisez des chiffres réels quand vous en avez. Les chiffres approximatifs conviennent : « environ 2 millions de lignes par jour » vaut mieux que « beaucoup de données ».

1. Sources, volume et utilisateurs : d’où viennent les données, combien arrivent chaque jour et qui utilise le résultat?
2. Horaire et nouvelles données : quand le pipeline s’exécute-t-il et comment détermine-t-il ce qui est nouveau?
3. Une deuxième exécution : s’il échoue à mi-chemin et que vous le relancez, qu’arrive-t-il aux lignes déjà écrites? L’avez-vous déjà testé?
4. Données en retard et incorrectes : qu’arrive-t-il à une ligne qui arrive plusieurs jours en retard? À une ligne avec une valeur manquante ou à un doublon? À un fichier dans un nouveau format?
5. Exactitude : comment savez-vous que les chiffres sont justes? Quelles vérifications s’exécutent et qu’arrive-t-il quand l’une échoue?
6. Le pire incident : ce qui a cessé de fonctionner, comment vous l’avez appris, qui a été touché et ce que vous avez changé.
7. Coût et volume : combien coûte l’exécution, environ? Que faudrait-il changer avec dix ou cinquante fois plus de données?

Les questions 3 et 6 comptent plus que la plupart des gens ne le pensent. Les responsables d’entrevue font confiance aux personnes qui décrivent un échec en détail. Seule une personne qui l’a vécu s’en souvient ainsi. Vous l’avez vu avec Vikram dans Le vétéran et avec Fatima Zahra dans La développeuse en intelligence d’affaires.

Si vous ne pouvez pas répondre à la question 3, ne vous inquiétez pas. Beaucoup de bons ingénieurs n’ont jamais vérifié. L’étape 3 règle ce problème.

Étape 3 : testez la réexécution d’un vrai pipeline

Cette petite expérience enseigne plus qu’une semaine de lecture. Prenez un pipeline que vous pouvez exécuter : un au travail, dans un environnement de test, ou un petit pipeline maison.

Si vous en créez un à la maison, trouvez un jeu de données public avec des horodatages. Par exemple, des trajets à vélo en libre-service, des mesures météo ou des courses en taxi. Choisissez des données où l’heure de l’événement compte. Créez une petite tâche qui charge une journée dans une table partitionnée par jour. Puis essayez ceci :

• Exécutez-la deux fois pour la même journée. Comptez les lignes avant et après. Si le nombre a doublé, modifiez la tâche pour qu’elle remplace la journée ou fusionne les données sur une clé unique par ligne. Exécutez-la encore deux fois.
• Ajoutez quelques lignes en retard. Mettez des lignes d’hier dans le fichier d’aujourd’hui. Où vont-elles? Modifiez la tâche pour qu’elles arrivent dans la bonne journée.
• Ajoutez un doublon et une ligne incorrecte. Écrivez une vérification qui les trouve. Décidez ce que fait la tâche : s’arrêter, ignorer la ligne ou la mettre de côté pour un examen humain.

Notez ce que vous avez changé et pourquoi dans un court README. Vous avez maintenant une expérience réelle pour répondre à la question 3. Vous comprenez aussi la question préférée d’Esther grâce à votre propre expérience. Vous avez vu Jordan arriver à la même réponse dans La pile moderne, avec un peu d’aide. Après ce test, vous n’aurez pas besoin de cette aide. Nos leçons Une extraction reproductible et Les règles de validation couvrent le volet SQL.

Étape 4 : pratiquez l’introduction à voix haute

L’examen approfondi commence par « Parlez-moi d’un pipeline que vous avez créé. » Vos deux premières minutes orientent la conversation, car la personne vous questionne sur ce que vous dites. Parlez donc des choses sur lesquelles vous voulez des questions.

Préparez une présentation de deux minutes. Utilisez les notes de l’étape 2, mais ne les lisez pas. Un ordre simple fonctionne :

• Le problème et les personnes qui utilisaient les données.
• Ce que vous avez créé, en présentant les principaux blocs.
• Une décision que vous avez prise et sa raison.
• Un problème rencontré et ce que vous avez changé.
• Une limite qui reste.

Présentez le tout à voix haute et enregistrez-vous sur votre téléphone. Écoutez une fois. La plupart des gens constatent qu’ils nomment beaucoup d’outils et expliquent peu de décisions. Réessayez en nommant moins d’outils. Notre leçon Expliquer vos décisions présente cette étape en détail.

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

La plupart des entrevues sur les pipelines incluent un problème tiré du travail de l’entreprise. Vous pouvez généralement le deviner dans l’offre. Une entreprise d’énergie a des relevés de compteurs. Un détaillant a des commandes et des retours. Une banque a des transactions qui doivent correspondre au cent près. Une entreprise de livraison reçoit des événements de téléphones qui perdent leur connexion réseau. Presque tous ces cas comportent des données en retard, des doublons et des réexécutions.

Rédigez le problème attendu en trois ou quatre phrases, comme celui d’Esther. Puis répondez à voix haute pendant 25 minutes, avec une minuterie. Commencez par vos questions. Dessinez ensuite les principaux blocs sur papier. Puis examinez les parties difficiles, une à une :

• L’heure de l’événement et l’heure d’arrivée.
• Ce qui rend une réexécution sûre.
• Le temps d’attente pour les données en retard et ce que font les utilisateurs pendant ce temps.
• Ce que vous vérifiez chaque matin.
• Ce qui coûte le plus cher.
• Ce qui nécessite vraiment un traitement en continu, s’il y a lieu.

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

Étape 6 : pratiquez le SQL et la modélisation à voix haute

Les étapes de SQL et de modélisation évaluent des compétences que vous avez peut-être déjà. La différence en entrevue : vous devez parler en réfléchissant, et personne ne vous aide à chercher.

Pour le SQL, pratiquez les requêtes que les ingénieurs de données écrivent chaque semaine. Faites-les sans assistant d’IA, dans un éditeur sans saisie automatique si possible :

• Gardez une seule copie de chaque ligne en double, par exemple avec ROW_NUMBER().
• Trouvez les lacunes : quels compteurs, utilisateurs ou jours ont des données manquantes?
• Comparez chaque ligne à la précédente, par exemple un relevé qui baisse alors qu’il devrait seulement augmenter.
• Comptez les lignes par jour et vérifiez que le total correspond à la source.

Après chaque requête, dites à voix haute ce qui pourrait la faire échouer : journée vide, deux lignes à la même heure, valeur manquante. Notre leçon Le temps et le classement couvre les fonctions de fenêtrage.

Pour la modélisation, prenez une situation réelle et concevez les tables sur papier. Puis expliquez-les à un ami en cinq minutes. Commencez toujours par la granularité : « Une ligne de cette table représente un relevé d’un compteur à un moment donné. » Puis pratiquez la gestion de l’historique. Choisissez quelque chose qui change avec le temps, comme l’adresse d’un client ou le compteur associé à un compte. Concevez une table qui répond à « qu’est-ce qui était vrai le 3 mars? » On appelle souvent cela une dimension à évolution lente de type 2. Vous gardez l’ancienne ligne, lui ajoutez une date de fin et ajoutez une nouvelle ligne. Vous avez vu pourquoi c’est important dans La développeuse en intelligence d’affaires et L’ingénieur logiciel.

Étape 7 : passez une entrevue avec une personne

Pratiquer seul est utile, mais ne peut pas vous surprendre. Demandez à un ami ou à un ancien collègue, idéalement ingénieur de données, de vous faire passer une entrevue de 45 minutes. Donnez-lui votre CV, les sept questions de l’étape 2 et le problème de l’étape 5. Demandez-lui d’approfondir vos réponses et de poser au moins une fois la question « qu’arrive-t-il si le pipeline s’exécute deux fois? » Après, demandez-lui un point fort et deux choses à améliorer.

Puis échangez les rôles et faites-lui passer une entrevue. En posant les questions, vous entendrez vite ce que donne une réponse générale et combien une réponse précise aide.

Vous pouvez aussi pratiquer avec un assistant d’IA. Demandez-lui de jouer un responsable d’entrevue exigeant, qui approfondit chaque réponse et n’accepte jamais une réponse générale. C’est un bon exercice. C’est très différent d’utiliser l’IA pendant une vraie entrevue, ce que nous vous demandons de ne jamais faire (nos conseils).

Étape 8 : préparez-vous aux limites de vos connaissances

Toute bonne entrevue vous amènera aux limites de vos connaissances. Pour les ingénieurs de données, ces limites concernent souvent les mécanismes du traitement en continu, comme les offsets (positions) et le traitement exactly-once (exactement une fois). Elles peuvent aussi concerner les performances de Spark sur de gros volumes. Ou les détails d’un lakehouse (architecture combinant lac et entrepôt de données), comme la compaction, ou la modélisation de l’historique. Vos limites dépendent de votre parcours.

Notez trois sujets où vous pensez atteindre vos limites. Pour chacun, écrivez ce que vous savez et comment vous trouveriez le reste. Puis pratiquez cette réponse : « Je ne l’ai pas utilisé directement. Ce que je sais, c’est… Si je devais décider aujourd’hui, je commencerais par… » C’est inconfortable les premières fois, puis cela devient normal. L’entrevue de Nicole dans L’experte du domaine montre ce que vous pouvez encore apporter à cette limite, en étant honnête.

Préparez-vous aussi à une autre limite : quand la personne qui mène l’entrevue dit quelque chose que vous pensez incorrect. Dans Le vétéran, Vikram conteste ce que le réglage exactly-once de Kafka couvre réellement, selon Esther. Il le fait poliment, avec une raison, et elle lui donne raison après réflexion. Connaissez assez bien vos sujets principaux pour faire de même et accepter un bon contre-argument. Consultez nos conseils pour exprimer un désaccord.

Étape 9 : préparez vos questions

Rédigez deux ou trois questions pour chaque étape de l’entrevue. Tirez-les de votre tableau de préparation et des questions de Lire l’offre avec honnêteté. Pour un poste en ingénierie de données, ces questions sont particulièrement utiles :

• « Quel a été le pire incident de données cette année et qu’avez-vous changé ensuite? »
• « Y a-t-il une rotation de garde? À quelle fréquence, et quand les tâches les plus importantes s’exécutent-elles? »
• « Qui est responsable du coût de la plateforme? »
• « Quand un système source change son format, comment l’équipe l’apprend-elle? »

Ces questions montrent que vous pensez comme une personne qui fera le travail. Elles vous donnent aussi l’information nécessaire pour décider. Rappelez-vous que la décision va dans les deux sens. Une bonne candidature peut recevoir une autre offre pendant qu’une entreprise réfléchit encore (nos conseils).

Le jour de l’entrevue

• Demandez au début ce qui est permis : notes, documentation, tableau blanc, assistant d’IA pendant une étape de programmation. Suivez ensuite les règles exactement.
• Pour une entrevue vidéo, testez votre caméra, votre microphone et le partage d’écran la veille. Fermez tout ce qui est inutile.
• Gardez du papier et un stylo près de vous. Les pipelines s’expliquent plus facilement avec des blocs et des flèches, même approximatifs.
• Il est normal de dire « Laissez-moi réfléchir un moment », puis de réfléchir en silence pendant 20 ou 30 secondes. Il est aussi normal de dire « Pardon, pouvez-vous répéter la question? »
• Traitez la personne qui mène l’entrevue comme un futur collègue. Vous cherchez aussi à savoir si vous voulez assurer la garde avec cette équipe.

Après l’entrevue

Le jour même, notez chaque question difficile pendant que vous vous en souvenez encore. Puis pratiquez ces questions. Si votre candidature n’est pas retenue, demandez poliment des commentaires. Les entreprises n’en donnent pas toutes. Quand elles le font, une liste honnête de sujets fournie par un responsable d’entrevue peut valoir des semaines de lecture. L’histoire de Jordan dans La pile moderne montre comment l’utiliser.

Une partie du résultat échappe à votre contrôle (nos conseils). L’équipe avait un seul poste vacant et une autre personne avait exactement l’expérience recherchée. Ou l’équipe a vu que vous conveniez mieux à un autre rôle. Un « non » pour un rôle amorce parfois une conversation sur un autre. Continuez et gardez votre plan centré sur les rôles que vous voulez.

Un plan de trois semaines

Le plan ci-dessous résume les étapes. Il 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 créez le tableau de préparation. Rédigez des notes détaillées sur votre pipeline principal. Commencez le test de réexécution de l’étape 3.	Enregistrez deux fois la présentation de deux minutes.
2	Terminez le test de réexécution et rédigez son README. Pratiquez les requêtes SQL et un exercice de modélisation de l’étape 6. Préparez vos trois sujets limites.	Répondez deux fois au problème de l’entreprise, avec une minuterie. Expliquez votre modèle à un ami.
3	Relisez vos notes. Corrigez les problèmes révélés par la pratique. Rédigez vos questions pour chaque étape.	Faites une entrevue simulée avec une personne, puis une autre après avoir corrigé les points soulevés.

Puis posez votre candidature et gardez vos notes. La prochaine offre ne demandera que quelques changements.