Le déroulement des entrevues

Pensez à un ami qui revient d’un long voyage. Vous demandez : « Comment ça s’est passé? » Il répond : « Très bien, on a traversé le pays en train. » Puis vous posez de petites questions, une après l’autre : « Où avez-vous dormi? », « Qu’est-ce qui s’est passé quand le train était en retard? », « Combien ça a coûté? » Un ami qui a vraiment fait le voyage répond facilement, avec de petits détails que personne n’inventerait. Un ami qui a seulement lu un récit du voyage manque de détails après deux ou trois questions.

Une entrevue technique sérieuse fonctionne de la même façon. L’intervieweur écoute d’abord, puis pose des questions sur ce que vous avez dit, en approfondissant chaque fois. Cette page explique cette méthode et les cinq entrevues du processus de Tidewell. Vous serez ensuite prêt pour la partie 3, où cinq personnes passent la même entrevue de conception de pipeline.

Les cinq entrevues chez Tidewell

L’offre de Tidewell ne décrit pas son processus. La plupart des vraies offres ne le font pas. La première chose à faire pendant l’appel avec la recruteuse est donc de poser la question. Voici ce que la recruteuse a expliqué aux candidats de ce guide. Chaque entrevue vérifie un aspect différent, et une personne différente la mène.

1. L’appel avec la recruteuse (30 minutes, Aisha Rahimi, recruteuse). Aisha vérifie les bases :

• Votre expérience correspond-elle au niveau du poste?
• Quel salaire souhaitez-vous, et quand pouvez-vous commencer?
• Pouvez-vous expliquer votre travail à une personne qui n’est pas ingénieure?

Elle explique aussi le processus et répond aux questions. Pendant cet appel, les candidats ont appris trois faits utiles absents de l’offre. L’équipe utilise Kafka, Databricks (Spark et tables Delta), Airflow et dbt chaque jour. Une rotation de garde couvre une semaine sur sept, car la facturation s’exécute à 5 h. Le poste est de niveau intermédiaire, avec une certaine souplesse pour une candidature solide de niveau senior. Rappelez-vous qu’en Colombie-Britannique, Aisha peut demander quel salaire vous souhaitez, mais pas combien vous gagniez auparavant.

2. SQL et Python (60 minutes, un ingénieur de données de l’équipe). Vous écrivez du code dans un éditeur partagé tout en parlant. Les outils d’IA sont interdits pendant cette étape. Les tâches ressemblent au travail quotidien de l’équipe. Par exemple : trouver les compteurs qui ont envoyé moins de relevés que prévu hier, ou supprimer les copies d’un relevé reçu deux fois. Ensuite vient une petite tâche Python, comme lire un fichier mal organisé du fournisseur de compteurs et trouver les lignes incorrectes. L’intervieweur vérifie que votre code est correct et que vous le testez sur des cas inhabituels (journée vide, doublon, valeur manquante). Il vérifie aussi que vous expliquez ce que vous faites pendant que vous tapez.

3. L’exploration approfondie de la conception d’un pipeline (60 minutes, en vidéo, Esther Adeyemi, ingénieure de données senior). C’est l’entrevue présentée dans la partie 3 de ce guide. Esther a dix ans d’expérience en ingénierie des données. Elle a grandi à Lagos, étudié au Royaume-Uni et vit au Canada depuis six ans. Elle était de garde la nuit de l’incident de double facturation décrit plus bas. Cet incident la touche donc personnellement. Elle est directe et patiente. Elle aime dessiner des blocs sur un tableau blanc partagé pendant que vous parlez. Elle demande souvent : « Et qu’est-ce qui se passe si ça s’exécute deux fois? » Elle vous interroge sur un pipeline que vous avez construit, l’explore en profondeur, puis vous présente le vrai problème de Tidewell.

4. La modélisation des données (45 minutes, Pierre Gagnon, ingénieur de données principal). Pierre vous demande de concevoir des tables pour un besoin réel. Par exemple : « La facturation a besoin de la consommation quotidienne de chaque compte pour les deux dernières années. » Il vérifie comment vous choisissez la granularité, séparez les faits des descriptions et conservez l’historique quand les choses changent. Son exemple préféré est le remplacement d’un compteur : le compte reste le même, mais le compteur change. Beaucoup de candidats trouvent cette étape la plus difficile, car il n’y a pas de code. Vous devez expliquer chaque choix avec des mots.

5. Les valeurs et la collaboration (45 minutes, Rosa Delgado, directrice des opérations de facturation). Rosa n’est pas ingénieure. Son équipe répond au téléphone quand une facture est incorrecte. Elle vous demande comment vous réagissez dans des situations difficiles : un utilisateur conteste vos chiffres, ou vous découvrez une erreur qui a déjà touché des clients. Ou encore, à 5 h, vous devez choisir entre respecter une échéance et garantir des résultats corrects. Elle vérifie aussi que vous expliquez un problème de données sans jargon et respectez les personnes qui utilisent vos données.

Après la dernière entrevue, les intervieweurs tiennent une réunion de bilan avec Graham Whitfield, gestionnaire de l’ingénierie des données, qui recrute pour ce poste. Chaque intervieweur partage ses notes écrites, puis ils décident ensemble. Un résultat solide dans une entrevue n’annule pas une préoccupation sérieuse soulevée dans une autre.

D’autres types d’entrevues que vous pourriez rencontrer

Vous pourriez rencontrer d’autres étapes dans d’autres entreprises :

• Un exercice à faire chez vous : vous construisez un petit projet dbt ou un carnet (notebook) Jupyter avec un pipeline, généralement en quelques heures. Beaucoup de personnes évaluent votre README aussi attentivement que votre code. Notez vos hypothèses, vos tests et ce que vous feriez avec plus de temps.
• Un exercice Spark : le même genre de tâche qu’à l’étape SQL, mais en PySpark. Parfois, on vous demande pourquoi un traitement est lent.
• Un exercice de programmation avec un assistant d’IA autorisé : certaines entreprises l’autorisent maintenant et observent comment vous vérifiez ce qu’il écrit. D’autres interdisent toute aide de l’IA. Suivez les règles de chaque étape et posez la question en cas de doute.
• Une entrevue de conception de plateforme : « Concevez la plateforme de données d’une entreprise de livraison de repas. » Elle couvre plus de sujets que l’exploration de Tidewell, mais moins en profondeur.
• Une entrevue comportementale : des questions sur des situations passées. Attendez-vous à au moins une question sur un incident en production. Distinguez votre contribution de celle de l’équipe.

Certaines entreprises ont aussi rétabli au moins une entrevue en personne. C’est notamment parce que des candidats utilisaient des outils d’IA cachés pendant les entrevues vidéo. Nous en parlons davantage dans nos conseils.

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

Beaucoup de personnes qui passent des entrevues en ingénierie des données parlent anglais comme deuxième ou troisième langue. C’est aussi le cas de nombreux intervieweurs. Dans ce guide, plusieurs des cinq candidats ont grandi en parlant d’abord une autre langue. Vous le remarquerez dans leur façon de parler. Un bon intervieweur écoute votre raisonnement, pas la perfection de votre grammaire. Si vous ne comprenez pas une question, demandez qu’on la répète. Si vous avez besoin d’un moment pour trouver un mot, prenez-le. Consultez nos conseils.

Comment un intervieweur sérieux approfondit les questions

L’exploration du pipeline commence par une question ouverte : « Parlez-moi d’un pipeline que vous avez construit ou dont vous êtes responsable. » Ensuite, l’intervieweur suit votre réponse. Voici comment une phrase peut mener à vingt minutes de conversation.

Supposons qu’une personne dise : « J’ai construit un traitement nocturne qui charge nos commandes en ligne dans l’entrepôt de données. » L’intervieweur approfondit, niveau par niveau :

D'une phrase aux limites des connaissances

1. 1

   « D'où viennent les données, quel volume représentent-elles et qui utilise le résultat? »

   Le pipeline existe-t-il vraiment, et quelle est sa taille? Un vrai pipeline a des sources, un volume et des utilisateurs réels.

2. 2

   « Quand s'exécute-t-il, et que lit-il? Toutes les données, ou seulement les nouvelles? »

   La personne a-t-elle construit le pipeline, ou l'a-t-elle seulement utilisé? Celle qui l'a construit sait comment le traitement repère les nouveautés.

3. 3

   « Il échoue à mi-chemin. Vous le relancez. Qu'arrive-t-il aux lignes déjà écrites? »

   Peut-on exécuter le traitement deux fois sans risque? Cette question permet de distinguer beaucoup de candidats.

4. 4

   « Une commande du lundi arrive le mercredi. Où va-t-elle? »

   La personne connaît-elle la différence entre le moment d'un événement et celui où les données arrivent?

5. 5

   « Comment savez-vous que les chiffres sont corrects? Parlez-moi d'une fois où ils étaient incorrects. »

   La personne peut-elle vérifier ses propres données, et apprend-elle des incidents?

6. 6

   « Qu'est-ce qui changerait avec cinquante fois plus de données, ou si les finances les voulaient chaque heure? »

   La limite : comment la personne raisonne au-delà de sa propre expérience, y compris sur les coûts.

L’intervieweur prévoit les sujets à explorer, pas les questions exactes. Les questions viennent des réponses. Une personne qui dit « nous supprimons la partition d’hier et la réécrivons » recevra une question sur les partitions. Une personne qui dit « nous ajoutons simplement les nouvelles lignes » entendra très vite la question préférée d’Esther.

C’est pourquoi les listes de questions d’entrevue aident si peu. Les questions viennent de votre propre travail. Vous ne pouvez donc pas apprendre les réponses par cœur. Vous pouvez toutefois connaître votre propre pipeline à fond : chaque décision, chaque chiffre, chaque échec.

Les limites de vos connaissances

Chaque personne atteint une limite. Un bon intervieweur l’y amène volontairement, car c’est là qu’il apprend le plus. Il veut voir 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. La personne vient de dire que son traitement nocturne « compacte aussi les petits fichiers » dans ses tables Delta.

Un exemple : atteindre la limite

Esther(intervieweur) :

Vous avez dit que vous compactez les petits fichiers chaque nuit. Pourquoi les petits fichiers posent-ils problème?

Candidat(personne candidate) :

Pardon, vous voulez dire pourquoi on le fait, ou comment le compactage fonctionne?

Esther(intervieweur) :

Pourquoi c’est nécessaire. Qu’est-ce qui se passe mal si vous ne le faites pas?

Candidat(personne candidate) :

D’accord. Hum. Honnêtement, le traitement existait quand je suis arrivé, et je n’ai pas beaucoup regardé son fonctionnement. J’ai vu que les requêtes ralentissaient quand on ne le faisait pas pendant quelques jours.

Esther(intervieweur) :

Hum-hum. Une idée de ce qui les ralentissait?

Candidat(personne candidate) :

Laissez-moi réfléchir. Je pense qu’ouvrir chaque fichier a un coût, même s’il est petit. Donc dix mille petits fichiers, ça fait dix mille ouvertures, et la table doit tous les suivre. Quelques gros fichiers, moins d’ouvertures. C’est mon hypothèse. Je vérifierais la documentation avant de le dire dans une revue de conception.

Pourquoi cela fonctionne

La personne vérifie d’abord le sens de la question, ce qui est normal et utile. Elle dit ensuite exactement où ses connaissances s’arrêtent et raisonne à partir de ses observations. Son hypothèse est essentiellement correcte. Esther en apprend davantage qu’avec une définition apprise par cœur.

Le problème de Tidewell

Dans la deuxième moitié de l’exploration, Esther donne le même problème à chaque personne. C’est la vraie raison pour laquelle l’équipe recrute. D’abord, voici quelques termes dont vous aurez besoin.

Pensez à une lettre. La date sur le cachet indique lundi, mais la lettre arrive jeudi. Si vous classez vos lettres par jour d’arrivée, la lettre du lundi se retrouve dans la pile du jeudi. Les relevés de compteurs fonctionnent de la même façon :

• Heure de l’événement : le moment où le compteur a pris le relevé. C’est la date sur le cachet.
• Heure d’arrivée (aussi appelée heure de traitement) : le moment où le relevé atteint les systèmes de Tidewell. C’est le jour où la lettre arrive.
• Partition : une partie d’une grande table, généralement une journée de données, qu’un traitement peut lire ou remplacer séparément.
• Idempotent : un traitement qui donne le même résultat, qu’il s’exécute une ou deux fois.
• Backfill (retraitement de données historiques) : relancer un pipeline pour des jours passés, par exemple après avoir corrigé un bogue.
• Watermark (seuil temporel) (en traitement en continu) : le délai pendant lequel un traitement en continu attend les événements tardifs avant de fermer une fenêtre temporelle. En traitement par lots, les équipes parlent généralement d’une limite ou d’une période rétrospective.

Voici comment Esther présente le problème :

« D’accord, maintenant notre vrai problème. Nos compteurs envoient un relevé toutes les 15 minutes. Parfois, un compteur perd sa connexion réseau et les relevés arrivent en retard, jusqu’à trois jours plus tard. Notre traitement nocturne lit les données selon leur date d’arrivée. Le mois dernier, après un échec, nous avons relancé le traitement et un client a été facturé deux fois. Et l’équipe des prévisions dit qu’il manque des données dans son historique. Comment concevriez-vous le pipeline des relevés de compteurs pour éviter que cela se reproduise? »

Il n’y a pas une seule bonne réponse. Esther ne veut pas une conception complète en 25 minutes. Elle veut voir par où vous commencez. Quelles questions posez-vous d’abord? Que changeriez-vous en premier? Comment sauriez-vous que les données sont correctes? Que fait la facturation pendant qu’elle attend les relevés tardifs? Ensuite, elle suit votre réponse, comme pour votre propre pipeline. Si vous approfondissez une partie, elle vous interrogera sur une autre : les compteurs remplacés, les changements d’heure, l’assistant d’IA ou les coûts.

Essayez avant de lire les candidatures

Prenez 25 minutes et expliquez, par écrit ou à voix haute, comment vous aborderiez le problème de Tidewell. Utilisez ce que vous avez appris dans Lire l’offre avec lucidité. Répondez à ces questions pour vous-même :

1. Quelles trois questions poseriez-vous à Esther avant de proposer quoi que ce soit?
2. Pourquoi la relance a-t-elle facturé un client deux fois? Que changeriez-vous pour rendre une relance sûre?
3. Un relevé arrive avec trois jours de retard. À quel jour appartient-il, et quel traitement le récupère?
4. Combien de temps attendriez-vous les relevés tardifs avant que la facturation utilise les données? Que fait la facturation quand un relevé manque?
5. Comment sauriez-vous, chaque matin, que les données d’hier sont complètes? Combien de relevés attendez-vous d’un compteur par jour? Ce nombre est-il toujours le même?
6. Une partie de ce système nécessite-t-elle un traitement en continu?

Gardez vos notes et comparez-les aux réponses des cinq candidats. Chaque personne part de sa propre expérience. Faites de même.

Comment lire les pages des candidats

Chaque page présente la même entrevue de 60 minutes avec Esther, sous forme de conversation. Les interventions bleues sont celles de l’intervieweuse; les vertes sont celles de la personne candidate. Des notes entre les interventions expliquent ce qui se passe :

• Ce que l’intervieweuse vérifie : la vraie question derrière la question.
• Comment l’intervieweuse approfondit : pourquoi la question suivante découle de la réponse.
• Pourquoi cela fonctionne : ce qui rend une réponse solide.
• Ce qui pose problème : 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 de la personne candidate.
• Exprimer un désaccord constructif : comment une personne exprime son désaccord avec l’intervieweuse en donnant ses raisons.

Chaque page se termine par les notes écrites d’Esther, la suite des événements et des conseils pour les lecteurs au profil semblable. Chaque candidature a ses moments forts et ses moments faibles, comme toute candidature réelle.

Les cinq candidats sont :

1. La développeuse en intelligence d’affaires : Fatima Zahra a neuf ans d’expérience en SQL, en rapports et en modèles de données soignés. Le traitement en continu et Spark à cette échelle sont nouveaux pour elle.
2. L’ingénieur logiciel : Lukas construit des services de paiement fiables en Java. Les tables destinées aux analystes sont nouvelles pour lui.
3. La pile moderne : Jordan travaille vite et soigneusement avec des outils gérés. Jordan a rarement eu besoin d’en explorer le fonctionnement interne.
4. Le vétéran : Vikram a 24 ans d’expérience en données et a vécu de nombreux incidents. Certains termes récents ne font pas encore partie de son vocabulaire.
5. L’experte du domaine : Nicole a travaillé dans les opérations de compteurs pendant sept ans et a appris à construire des systèmes le soir.

Lisez ces pages dans l’ordre qui vous convient. Commencez par la personne qui vous ressemble le plus, puis lisez celle qui vous ressemble le moins.