La pile moderne

Imaginez quelqu’un qui a toujours utilisé un cuiseur à riz. Le riz est parfait chaque fois. Puis, un jour, cette personne cuisine avec seulement une casserole et une cuisinière au gaz. Ce n’est pas un manque de talent. Elle n’a simplement jamais eu à apprendre quelle quantité d’eau utiliser, quelle chaleur régler et quand arrêter. La machine décidait pour elle.

Beaucoup d’ingénieurs de données commencent leur carrière ainsi. Ils rejoignent une jeune entreprise qui avance vite et bâtissent une plateforme complète en quelques mois avec des outils gérés. Un outil copie les données des applications, un entrepôt infonuagique les stocke, dbt crée les modèles et un ordonnanceur coordonne le tout. Le travail est réel et avance vite. Mais les outils gèrent discrètement les parties les plus difficiles : données en retard, doublons et réexécutions sûres. Quand ces personnes postulent dans une entreprise avec une source de données volumineuse et désordonnée, elles découvrent la casserole et la cuisinière au gaz.

Suivez Jordan pendant l’examen approfondi du pipeline que mène Esther chez Tidewell Energy. Observez ce que Jordan connaît très bien, ce que les outils lui ont caché et sa réaction devant ses limites. La réponse est « non » cette fois. Regardez bien pourquoi c’est quand même un bon résultat pour une personne ayant deux ans d’expérience en ingénierie de données.

JE

La personne candidate

Jordan Ellis

Ingénieur de données, 2 ans dans une jeune entreprise en forte croissance, pile de données moderne

• 2 ans en ingénierie de données
• Fivetran, dbt, Snowflake, Airflow
• Premier ingénieur de données d'une jeune entreprise
• Vancouver, Colombie-Britannique

• Ingénieur de données, Pantrybox (2024 à aujourd’hui). Jeune entreprise d’abonnement à des boîtes-repas passée de 60 à 220 personnes. Premier ingénieur de données, équipe de deux.
• A bâti la plateforme de données de l’entreprise à partir de zéro avec la pile de données moderne : Fivetran (6 sources), Snowflake, dbt (plus de 180 modèles, plus de 400 tests), Airflow.
• A créé les modèles de revenus utilisés par les finances pour les rapports mensuels. A documenté chaque modèle dans dbt docs.
• A réduit les coûts de Snowflake de 35 %.
• Outils : SQL, Python, dbt, Snowflake, Fivetran, Airflow, Dagster, Kafka, Spark, Flink, Looker, Git.
• Baccalauréat ès arts en économie (2023). Certification dbt (2025).

Ce qu’Esther voit avant l’appel

Esther lit le CV deux fois. La première partie est bonne. Jordan a bâti une plateforme sans aide, et 400 tests pour 180 modèles témoignent d’un travail soigné. Beaucoup d’ingénieurs de données ayant cinq ans d’expérience écrivent moins de tests.

La liste d’outils l’inquiète un peu. Kafka, Spark et Flink y figurent, mais aucun projet ne les utilise. Elle ne prévoit pas d’interroger Jordan sur cette liste. Elle veut voir ce que Jordan peut expliquer. Ses questions :

• Comment le pipeline de Jordan se comporte-t-il quand il s’exécute deux fois, ou quand les données arrivent en retard? Jordan le sait-il, ou les outils ont-ils décidé?
• « Coûts réduits de 35 % » : qu’est-ce que Jordan a changé, et comment a-t-il mesuré cette réduction?
• Face au problème de Tidewell, Jordan peut-il raisonner étape par étape quand aucun outil ne le fait à sa place?

Termes utilisés sur cette page

• Fivetran : service géré qui copie les données d’applications et de bases de données dans un entrepôt selon un horaire.
• dbt : outil qui crée des tables dans un entrepôt à partir de modèles SQL, avec des tests et de la documentation.
• Modèle incrémentiel : modèle dbt qui traite seulement les lignes nouvelles ou modifiées à chaque exécution, plutôt que de reconstruire toute la table. Une actualisation complète reconstruit toute la table.
• Heure de l’événement et heure d’arrivée : moment où un compteur a pris une mesure et moment où elle a atteint nos systèmes. Plusieurs jours peuvent séparer ces deux moments.
• Partition : partie d’une table, ici une journée de mesures. Remplacement de partitions : remplacer des partitions entières par une nouvelle version, plutôt que d’ajouter des lignes.
• MERGE : instruction SQL qui met à jour les lignes existantes, repérées par une clé, et insère celles qui n’existent pas.
• SCD de type 2 (dimension à évolution lente, type 2) : table qui conserve chaque version d’un enregistrement, avec ses dates de validité. Un instantané dbt crée ce type de table.

L’entrevue

Minutes 0 à 5 : le début

Esther(intervieweur) :

Bonjour Jordan. Vous m’entendez bien? Je suis Esther, ingénieure de données principale dans l’équipe Data Platform. Je travaille surtout sur les pipelines de facturation. Alors, voici le plan. D’abord, vous me parlez d’un pipeline que vous avez construit, et je pose beaucoup de questions. Ensuite, je vous présente un de nos vrais problèmes. À la fin, vos questions. Une chose : pas d’outils d’IA pour cette étape, s’il vous plaît. Le papier, c’est permis. J’ai aussi un tableau blanc où on peut dessiner ensemble.

Jordan(personne candidate) :

Oui, je vous entends. Bonjour! D’accord, ça me va. J’ai du papier. Je vais essayer de ne pas parler trop vite. Je fais ça quand je suis nerveux.

Esther(intervieweur) :

Rit un peu. Pas de problème. Je vous arrête si je ne suis plus.

Minutes 5 à 25 : le pipeline, puis les détails

Esther(intervieweur) :

Alors. Choisissez un pipeline que vous connaissez bien et expliquez-moi son fonctionnement.

Jordan(personne candidate) :

D’accord. Le pipeline des revenus chez Pantrybox, parce que les finances l’utilisent chaque mois. Donc, on vend des boîtes-repas par abonnement. Les paiements sont dans Stripe, les commandes dans la base de données Postgres de notre application. Fivetran copie les deux dans Snowflake, toutes les quinze minutes, je pense. Peut-être trente pour Stripe. Ensuite, dbt construit les modèles : paiements, remboursements, revenus par jour et par forfait. Airflow exécute dbt chaque matin à six heures. Et il y a des tests sur tout : unicité, absence de valeurs nulles, et quelques tests personnalisés. Par exemple, les revenus d’une journée ne peuvent pas être négatifs.

Esther(intervieweur) :

Hum-hum. Quel volume de données?

Jordan(personne candidate) :

Pas énorme. Environ 40 000 abonnés. La table des paiements contient peut-être deux millions de lignes. Le plus gros, ce sont les événements de l’application, je pense autour de 300 millions de lignes. Mais les revenus ne les utilisent pas.

Esther(intervieweur) :

D’accord. Et comment le relancez-vous?

Jordan(personne candidate) :

Airflow réessaie chaque tâche deux fois, avec cinq minutes entre les tentatives. Si elle échoue encore, je reçois un message Slack.

Esther(intervieweur) :

Pardon, je voulais dire autre chose. Disons que les revenus de mardi dernier étaient incorrects. Vous corrigez le code. Comment retraitez-vous mardi dernier?

Jordan(personne candidate) :

Ah, d’accord. Hum. On ne traite pas vraiment « mardi dernier ». dbt construit les modèles avec toutes les données présentes dans Snowflake maintenant. Donc je corrige le code et je relance. Pour les modèles incrémentaux, je fais une reconstruction complète.

Esther(intervieweur) :

Donc il n’y a pas de « mardi » dans votre pipeline. Chaque exécution traite « tout jusqu’à maintenant ».

Jordan(personne candidate) :

Oui. Je n’y avais jamais pensé comme ça, mais oui.

Ce que l’intervieweur vérifie

La première question d’Esther sur la relance n’était pas claire. Jordan a répondu à une autre question, sur les nouvelles tentatives automatiques. Elle ne juge pas cette réponse. Elle repose la question avec un exemple concret. Puis elle apprend quelque chose d’important : le pipeline de Jordan ne prévoit pas de journée qu’on peut traiter de nouveau. À l’échelle de Pantrybox, cela convenait.

Esther(intervieweur) :

D’accord. Quel a été le pire incident sur ce pipeline?

Jordan(personne candidate) :

Les remboursements. L’an dernier, les finances ont découvert que les revenus de mars étaient trop élevés, d’environ 2 %. Peut-être un peu moins. Le modèle des paiements était incrémental et récupérait les nouvelles lignes selon leur date de création. Mais un remboursement ne crée pas un nouveau paiement, il modifie l’ancien. Donc les paiements remboursés n’étaient jamais mis à jour dans notre modèle.

Esther(intervieweur) :

Bien. Comment avez-vous corrigé ça?

Jordan(personne candidate) :

J’ai changé le filtre pour utiliser la date de mise à jour, en reprenant les trois derniers jours. Et une clé unique sur l’identifiant du paiement, pour que dbt fusionne au lieu d’ajouter. Puis une reconstruction complète chaque dimanche, par sécurité.

Esther(intervieweur) :

Pourquoi trois jours?

Jordan(personne candidate) :

Honnêtement… j’ai pris ça dans un article de blogue. Ça me semblait sûr.

Esther(intervieweur) :

Et la reconstruction complète du dimanche. À quoi sert-elle, si le traitement incrémental est correct?

Jordan(personne candidate) :

Pause. Parce qu’on ne lui faisait pas complètement confiance. Ça coûte peu à notre échelle, donc on faisait les deux.

Où cela tourne mal

Une reconstruction complète chaque semaine « par sécurité » est courante. Avec deux millions de lignes, elle ne coûte presque rien. Mais elle cache une question à laquelle Jordan n’a jamais eu à répondre : quelles lignes peuvent encore changer, et quand? Chez Tidewell, la table des relevés augmente d’environ 115 millions de lignes par jour, soit 42 milliards par année. La reconstruire au complet chaque dimanche n’est pas une petite précaution. C’est une grosse facture.

Esther(intervieweur) :

Allons un niveau plus bas. Quand un remboursement modifie un paiement dans Stripe, comment cette modification arrive-t-elle dans Snowflake? Et si Fivetran envoie la même modification deux fois, obtenez-vous deux lignes?

Jordan(personne candidate) :

Fivetran faisait ça pour nous. Je ne sais pas vraiment comment. Je n’ai jamais vu de doublons, donc je pense qu’il met la ligne à jour avec la clé primaire. Mais je suppose. Je n’ai jamais regardé.

Esther(intervieweur) :

C’est une réponse honnête, merci. Votre supposition est bonne. Fivetran demande à la source ce qui a changé depuis la dernière synchronisation, puis écrit selon la clé primaire. Donc, si la même modification arrive deux fois, il met encore à jour la même ligne. Vous aviez des relances sûres sans effort, vous ne les voyiez simplement pas.

Jordan(personne candidate) :

Ah. D’accord. Donc on pouvait relancer l’outil sans risque, il était idempotent, mais mon modèle ne l’était pas au début.

Pourquoi cette honnêteté fonctionne

« Fivetran faisait ça pour nous. Je ne sais pas vraiment comment » est la phrase la plus utile de cette entrevue. Esther sait maintenant exactement où s’arrêtent les connaissances de Jordan. Elle peut donc faire confiance au reste de ses réponses. Puis Jordan fait mieux que supposer : Jordan relie l’explication d’Esther à son propre incident. Voir Expliquer vos compétences honnêtement.

Esther(intervieweur) :

Votre CV indique que vous avez réduit les coûts de Snowflake de 35 %. Qu’avez-vous changé?

Jordan(personne candidate) :

Deux choses, surtout. Les entrepôts de calcul attendaient dix minutes avant de se suspendre. J’ai réduit ça à une minute, parce que nos tâches sont courtes. Et j’ai fait passer deux gros modèles de la reconstruction complète au traitement incrémental. La facture est passée d’environ 6 000 dollars par mois à environ 4 000. Donc… honnêtement, c’est plutôt 33 %. Le 35, c’était le meilleur mois.

Esther(intervieweur) :

Rit. D’accord, 33. Et quelqu’un était responsable des coûts, ou c’était vous?

Jordan(personne candidate) :

Moi, parce que personne d’autre ne les regardait. J’ai fait un petit tableau de bord des crédits par modèle.

La dernière question d’Esther sur le CV concernait Kafka, Spark et Flink. Jordan a dit directement avoir utilisé ces outils seulement dans un cours en ligne et un petit projet Flink sur son portable. Jordan a ajouté que le CV devrait probablement les déplacer vers une ligne « en apprentissage ».

Une meilleure ligne dans le CV

La liste d’outils faisait une promesse que l’entrevue ne pouvait pas tenir. Jordan a bien répondu à la question. Un meilleur CV évite cette question : « En apprentissage : Kafka et Spark (cours en ligne, un petit projet) ». C’est vrai, ça reste intéressant, et la personne qui mène l’entrevue peut parler du projet plutôt que vérifier une affirmation. Voir Les éléments d’un portfolio.

Minutes 25 à 40 : le problème de Tidewell, la relance

Esther(intervieweur) :

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

Jordan(personne candidate) :

D’accord. Je peux d’abord poser quelques questions? La tâche nocturne lit ce qui est arrivé hier et l’ajoute à la table nettoyée?

Esther(intervieweur) :

Oui. Elle ajoute les lignes. La table nettoyée est divisée par date d’arrivée.

Jordan(personne candidate) :

Et la relance a ajouté la même journée de nouveau. Donc chaque relevé de cette journée était présent deux fois.

Esther(intervieweur) :

Oui. Et la facturation les a additionnés.

Jordan(personne candidate) :

D’accord. Ma première idée, c’est ce que j’ai fait avec les remboursements. Un traitement incrémental avec une clé unique, l’identifiant du compteur plus l’heure du relevé, et une fusion. Ensuite, une deuxième exécution met à jour les mêmes lignes sans en ajouter de nouvelles.

Esther(intervieweur) :

Ça fonctionne. C’est une bonne réponse. Maintenant, la table nettoyée contient environ cinq ans de relevés. Combien coûte un MERGE là-dessus?

Jordan(personne candidate) :

Hum. Il faut trouver les lignes correspondantes pour chaque nouveau relevé. Dans Snowflake, je n’ai jamais réfléchi à comment il les trouve. Je ne sais pas comment Delta fait ça.

Esther(intervieweur) :

Je vous donne un indice. Pensez aux journées entières, pas aux lignes individuelles. Un relevé en retard, à quelle journée appartient-il?

Jordan(personne candidate) :

La journée où le compteur a pris la mesure. Pas celle où le relevé est arrivé. Ah. Donc la table nettoyée devrait être divisée par date de relevé, pas par date d’arrivée.

Esther(intervieweur) :

Hum-hum. Et ensuite?

Jordan(personne candidate) :

Ensuite… chaque nuit, prendre les trois derniers jours de relevés, les supprimer et les reconstruire avec les données brutes. Tout ce qui est arrivé pour ces jours jusqu’à maintenant. Parce que ce sont les seuls jours qui peuvent encore changer.

Esther(intervieweur) :

Et que se passe-t-il si la tâche s’exécute deux fois?

Jordan(personne candidate) :

Les mêmes trois jours sont remplacés par les mêmes données. Même résultat. Pause. D’accord, c’est vraiment plus simple que la fusion. C’est comme ma reconstruction complète du dimanche, mais seulement pour les jours qui peuvent encore changer.

Esther(intervieweur) :

Exactement. On appelle ça le remplacement de partitions. Dans Delta, vous indiquez les dates à remplacer, et il les remplace dans une seule transaction. Il ne touche pas aux cinq autres années.

Raisonner avec de l'aide

La première réponse de Jordan, un MERGE sur une clé, est correcte. Esther ne dit pas qu’elle est mauvaise. Elle pose une question sur le coût, puis donne un indice. Jordan fait le reste du raisonnement : l’heure de l’événement détermine la journée, seuls les jours récents peuvent changer. Ces jours sont remplacés au complet. Un bon indice ne fait pas perdre un point. Ce qui compte, c’est ce que vous en faites. Un MERGE qui limite aussi les dates de relevés coûte peu lui aussi. Les deux sont corrects; le remplacement est plus simple à comprendre.

Esther(intervieweur) :

Encore une chose sur la table brute. Le système central de collecte renvoie parfois le même relevé après un problème de réseau. Donc les données brutes peuvent contenir des doublons.

Jordan(personne candidate) :

Alors, quand je reconstruis une journée, je garde une ligne par compteur et heure de relevé. ROW_NUMBER sur l’identifiant du compteur et l’heure du relevé, trié par heure d’arrivée, la plus récente d’abord. Et je garde la première ligne. Cette partie, je la connais bien.

Esther(intervieweur) :

Pourquoi la plus récente?

Jordan(personne candidate) :

Au cas où le deuxième serait une correction? Mais je ne suis pas sûr que les compteurs envoient des corrections. Est-ce qu’ils le font?

Esther(intervieweur) :

Parfois, oui, après la réparation d’un compteur. Bonne question. Et les relevés qui arrivent après trois jours? Une semaine normale, il y en a très peu. Après une grosse tempête, peut-être un ou deux pour cent des compteurs, avec jusqu’à une semaine de retard.

Jordan(personne candidate) :

Alors la tâche ne devrait peut-être pas utiliser une période fixe de trois jours. Elle pourrait regarder les données brutes d’hier, voir quelles dates de relevés s’y trouvent et reconstruire seulement ces jours. Habituellement, ça fait trois ou quatre jours. Après une tempête, c’est plus, mais seulement au besoin.

Esther(intervieweur) :

J’aime ça. Les données vous indiquent quels jours reconstruire.

Minutes 40 à 50 : facturation, qualité et historique

Esther(intervieweur) :

Maintenant, la facturation s’exécute à 5 h. Certains relevés d’hier ne sont pas encore arrivés. Que fait la facturation?

Jordan(personne candidate) :

Je ne sais pas comment la facturation gère les relevés manquants. Vous les estimez?

Esther(intervieweur) :

Oui. La facturation estime les heures manquantes, puis corrige la facture suivante quand les vrais relevés arrivent.

Jordan(personne candidate) :

Alors il faut un indicateur dans la table : réel ou estimé. Et la facture devrait conserver la version des données qu’elle a utilisée. Sinon, personne ne peut expliquer la correction au client.

Esther(intervieweur) :

Bien. Comment sauriez-vous qu’une journée est complète?

Jordan(personne candidate) :

Un test, comme dans dbt. Compter les relevés par compteur et par jour. Il devrait y en avoir 96. Envoyer une alerte quand trop de compteurs en ont moins.

Esther(intervieweur) :

Toujours 96? Pensez au premier novembre.

Jordan(personne candidate) :

Le premier… ah, le changement d’heure. La journée a 25 heures, donc 100 relevés. Et en mars, 23 heures, donc 92. Donc le nombre attendu vient du nombre d’heures de cette journée locale, pas d’un nombre fixe.

Esther(intervieweur) :

Oui. Une de nos tâches a encore 96 écrit dans le code. Petit rire. D’accord, dernier sujet. Quand on remplace un compteur, le nouveau a un nouvel identifiant. Et le CRM conserve seulement le compteur associé au compte aujourd’hui. L’équipe de prévision voit des trous et des sauts.

Jordan(personne candidate) :

Ah, ça, je connais. Un instantané dbt de la table du CRM, chaque nuit. Ensuite, on a l’historique : compte, compteur, début de validité, fin de validité. Type 2. Et la prévision joint les relevés au compte pour les bonnes dates.

Esther(intervieweur) :

Et l’historique avant le jour où vous activez l’instantané?

Jordan(personne candidate) :

Pause. Il n’existe pas. L’instantané commence seulement à enregistrer à partir de ce jour-là. Est-ce que les remplacements sont notés ailleurs? Comme dans l’ordre de travail de la personne qui remplace le compteur?

Esther(intervieweur) :

Oui, les ordres de travail sur le terrain. On en a trois ans.

Jordan(personne candidate) :

Alors construire l’historique passé à partir des ordres de travail, et l’instantané continue à le conserver à partir de maintenant. Et les comparer pendant quelques mois, parce qu’ils ne seront pas d’accord partout.

La meilleure réponse de la journée

Ici, les vraies forces de Jordan apparaissent. Jordan connaît les dimensions à évolution lente (SCD) de type 2 grâce aux instantanés dbt. Et Jordan voit le piège que beaucoup ratent : un instantané conserve l’historique seulement à partir du jour de son activation. Puis Jordan cherche une autre source fiable et prévoit de comparer les deux. C’est le même raisonnement soigneux que pour ses 400 tests.

Esther a posé une autre courte question sur l’assistant d’IA du service à la clientèle. Jordan a répondu à partir de son expérience. Chez Pantrybox, Jordan avait défini des règles d’accès par ligne sur les données clients dans Snowflake. Ainsi, chaque outil de soutien voyait seulement les lignes d’un seul client. « Je voudrais la même chose ici, et un test dbt qui essaie de lire un autre compte et échoue. » Esther a aimé l’idée du test.

Minutes 50 à 57 : les questions de Jordan

Jordan(personne candidate) :

J’en ai trois. D’abord, la partie Spark. Si une personne comme moi arrivait, comment l’apprendrait-elle? Est-ce qu’on travaille en binôme?

Esther(intervieweur) :

Réponse honnête : un peu. On travaille en binôme sur les nouveaux pipelines. Mais il n’y a pas de plan de formation. Les gens apprennent au travail, et il y a beaucoup à faire.

Jordan(personne candidate) :

D’accord. Deuxième question. Aisha a dit que la garde, c’est une semaine sur sept. Comment une nouvelle personne commence-t-elle?

Esther(intervieweur) :

Elle observe d’abord, aux côtés de la personne de garde, avant de le faire seule. La facturation s’exécute à 5 h, donc si elle échoue, quelqu’un se réveille.

Jordan(personne candidate) :

Je n’ai jamais fait de garde. Honnêtement, ça me fait un peu peur. Mais je voudrais apprendre. Dernière question : qui est responsable du coût de l’entrepôt ici?

Esther(intervieweur) :

Rit. Bonne question. Personne, vraiment. Il a beaucoup augmenté cette année.

De bonnes questions

Chaque question obtient une vraie réponse que Jordan peut utiliser. L’apprentissage se fait au travail, les nouvelles personnes observent la garde avant de la faire seules, et personne ne gère les coûts. La question sur les coûts rappelle aussi à Esther que Jordan en était responsable chez Pantrybox. Vos questions peuvent aussi montrer vos forces. Voir Les entrevues vont dans les deux sens.

Minutes 57 à 60 : la fin

Esther(intervieweur) :

Merci, Jordan. Prochaines étapes : Aisha vous contactera cette semaine.

Jordan(personne candidate) :

Merci. J’ai beaucoup appris en une heure, surtout la partie sur les partitions. Je vais revoir ma reconstruction complète du dimanche.

Après l’appel : les notes d’Esther

Jordan Ellis, examen approfondi de la conception du pipeline

• dbt, tests, documentation : preuves solides. Plus de 400 tests, modèles documentés, incident clair (remboursements) avec une vraie correction. A repéré le piège des instantanés dbt sans aide.
• SQL : preuves solides. Déduplication avec ROW_NUMBER, expliquée en une phrase.
• Réexécutions et données tardives : quelques preuves. A commencé avec MERGE sur une clé (correct). A trouvé l’écrasement des partitions par date de lecture avec un indice. Ne savait pas pourquoi sa propre fenêtre rétrospective était de trois jours.
• Spark, Kafka, traitement en continu : aucune preuve. Seulement des connaissances de cours, et l’a dit.
• Exploitation en production : aucune preuve. Jamais de garde; honnête à ce sujet.
• Coûts : quelques preuves. Responsable des coûts chez Pantrybox; changements simples, mais mesurés, et a corrigé son propre chiffre.
• Préoccupation : la liste d’outils du CV. Elle promet plus que ce que le travail démontre. Jordan l’a reconnu directement à la question.

Recommandation : non pour ce poste. Nous avons besoin de quelqu’un qui prendra en charge la conception du retraitement et la garde à 5 h d’ici quelques mois. Jordan aurait besoin d’un accompagnement étroit de six mois à un an sur Spark et l’exploitation. Nous n’avons pas ce temps ce trimestre. Je serais heureuse de revoir Jordan dans un an. Son honnêteté sur les limites de ses connaissances était la meilleure de la semaine.

La suite

Les entrevues de Jordan avec Pierre et Rosa se sont bien passées. Mais au bilan, elles n’ont pas changé la principale lacune, et Graham partageait l’avis d’Esther. Aisha a appelé Jordan la semaine suivante pour annoncer la décision. Deux jours plus tard, Graham a envoyé un court courriel avec des commentaires précis, tirés des notes d’Esther :

• Les points forts : les tests, l’incident des remboursements, le piège des instantanés, l’honnêteté sur Fivetran et le CV.
• Ce qui manquait : le partitionnement selon l’heure de l’événement, les réexécutions sûres sans actualisation complète, Spark à grande échelle et la garde.
• Quoi apprendre ensuite : construire un petit pipeline avec un jeu de données public de séries chronologiques où certaines données arrivent tard. Le partitionner par date d’événement, reconstruire les derniers jours chaque nuit et prouver que deux exécutions donnent le même résultat. Ensuite, lire comment Delta ou Iceberg remplace les partitions. Apprendre les bases des consommateurs Kafka et des décalages.

Jordan a répondu le jour même. Jordan a remercié Graham et a demandé à garder le contact et à postuler de nouveau plus tard. Graham a dit oui. Esther a accepté la demande de connexion de Jordan et lui a envoyé un lien vers une conférence sur les données tardives.

C’est un bon résultat pour quelqu’un qui a deux ans d’expérience en ingénierie. Jordan a atteint une entrevue finale de conception dans une entreprise aux prises avec un problème de données difficile. Jordan en est sorti avec une liste claire de choses à apprendre, écrite par les personnes qui pourraient l’embaucher plus tard. Et Jordan a laissé une bonne impression. Le poste est allé à une personne qui avait beaucoup plus d’années d’expérience en production. Ce n’était pas un jugement sur l’avenir de Jordan. La chance et le moment jouent aussi un rôle.

Ce qu’il faut en retenir

• Apprenez ce qui se passe sous vos outils. Les outils gérés traitent les données tardives, les doublons et les réexécutions pour vous. Découvrez comment ils le font, pour pouvoir le faire sans eux.
• « Je ne sais pas comment l’outil le fait » est une réponse solide quand c’est vrai. Elle montre à la personne qui vous évalue où s’arrêtent vos connaissances. Elle peut alors faire confiance au reste.
• Sachez pourquoi vous avez choisi vos chiffres. « Trois jours, selon un billet de blogue », c’est honnête. Mais vous devriez pouvoir expliquer chaque chiffre dans votre propre pipeline.
• Adaptez votre CV à ce que vous pouvez expliquer. Un outil découvert seulement dans un cours appartient à une ligne « en apprentissage ».
• Un indice n’est pas un échec. Jordan a trouvé l’écrasement des partitions avec un indice, et c’est ce qu’Esther a noté.
• Un « non » accompagné de commentaires précis est utile. Demandez-les poliment, et demandez à garder le contact.

Si votre profil ressemble à celui de Jordan

1. Reconstruisez un de vos pipelines sans l’outil géré. Chargez manuellement un jeu de données public dans des tables, puis répondez : que se passe-t-il si ce traitement s’exécute deux fois? Que se passe-t-il si une ligne arrive avec trois jours de retard? Écrivez les réponses dans votre README.
2. Partitionnez selon l’heure de l’événement et réexécutez volontairement. Reconstruisez les derniers jours chaque nuit, exécutez le traitement deux fois et comparez les nombres de lignes et les totaux. Livrer un jeu de données réutilisable montre comment prouver que deux exécutions donnent le même résultat.
3. Exercez-vous au SQL qui déduplique et rapproche les données. Les fonctions de fenêtre dans Le temps et le classement, et les vérifications de données codées dans Les règles de validation.
4. Apprenez les bases d’un moteur sous les outils. Spark ou un système de traitement en continu : partitions, consommateurs et décalages, filigranes. Un petit projet suffit pour en parler honnêtement.
5. Demandez à observer une personne de garde à votre emploi actuel, même pour une semaine. C’est l’expérience que les entrevues pour ce poste vérifient le plus souvent, et elle est souvent facile à obtenir.
6. Corrigez le CV. Chaque outil de la liste devrait correspondre à une ligne que vous pouvez expliquer pendant dix minutes. Consultez Se préparer aux candidatures et Expliquer vos décisions.