Le vétéran

Imaginez un chauffeur d’autobus qui, après 25 ans de conduite, arrive dans une ville équipée de nouveaux autobus électriques. L’écran est différent, les portes s’ouvrent autrement et les jeunes chauffeurs emploient des mots qu’il n’utilise pas. Mais dès sa première semaine, il voit le cycliste dans le rétroviseur avant tout le monde. Il sait ce qui se passe sur une route mouillée à 18 h. Ce savoir ne vient pas de l’autobus.

Beaucoup d’ingénieurs de données expérimentés vivent la même situation. Ils ont construit des entrepôts sur Teradata ou Oracle, écrit des traitements ETL dans Informatica et exploité des grappes Hadoop. Beaucoup ont aussi dirigé le passage au nuage. Certains ont plus de 50 ans et gardent une inquiétude pour eux : « Vont-ils voir mon âge et mes anciens outils, puis cesser de m’écouter? » Cette inquiétude est réelle. En Colombie-Britannique, le Human Rights Code protège les candidats contre la discrimination fondée sur l’âge. Les bonnes équipes embauchent sur la base de preuves. Mais une loi ne dissipe pas l’inquiétude. Les preuves, oui.

Suivez Vikram pendant l’examen approfondi des pipelines qu’Esther mène chez Tidewell Energy. Il ne mentionne jamais son âge, et il n’en a pas besoin. Observez comment son expérience se traduit en réponses précises. Notez où ses mots sont plus anciens que ceux de l’équipe et comment il corrige poliment la personne qui l’interroge.

VR

La personne candidate

Vikram Rao

Responsable de l'ingénierie des données, 24 ans dans les données bancaires, a dirigé une migration de Teradata vers un lakehouse infonuagique

• 24 ans dans les données
• Teradata, Informatica, Hadoop
• A dirigé une migration vers un lakehouse
• Surrey, C.-B.

• Ingénieur de données principal, migration vers le nuage, Westmark Financial (depuis 2023). A dirigé une équipe de 6 personnes qui a migré l’entrepôt des finances et des risques de Teradata et Hadoop vers un lakehouse infonuagique (architecture combinant lac et entrepôt de données). Outils : Spark, Iceberg, Airflow et Kafka pour les événements de carte.
• A exploité les anciennes et nouvelles plateformes en parallèle pendant 4 mois, avec un rapprochement quotidien au cent près. A mis Teradata hors service en 2025.
• Architecte d’entrepôt de données, puis responsable ETL, Westmark Financial (2006 à 2023). Chargements quotidiens des transactions par carte, du grand livre et des rapports réglementaires, avec Informatica PowerCenter, Teradata et Hive.
• A conçu le cadre de totaux de contrôle utilisé par plus de 40 flux quotidiens.
• A dirigé la rotation de garde pour les données pendant 10 ans.
• Développeur ETL, société de conseil, Pune (2002 à 2006).

Ce qu’Esther voit avant l’appel

Quatre éléments du CV intéressent Esther : l’exploitation en parallèle, « au cent près », les totaux de contrôle et dix ans de garde. Tidewell utilise ces données pour facturer ses clients, et le dernier incident était une double facturation.

Elle remarque aussi une pensée qui lui vient : « Est-il trop expérimenté pour cette échelle salariale? Va-t-il s’ennuyer? » Elle s’arrête là. C’est à Vikram d’en décider, pas à elle, et cette question cache souvent un préjugé lié à l’âge. Son travail consiste à découvrir ce qu’il sait faire. Elle note trois questions :

• Après trois ans à diriger, travaille-t-il encore directement sur les tâches techniques? Sait-il encore écrire et lire le code?
• Comment son rapprochement fonctionne-t-il en pratique, et convient-il aux données de compteurs?
• Ses outils sont plus anciens que les nôtres. Connaît-il les idées derrière les nouveaux noms?

À propos de l'âge et des anciens outils

Une bonne personne qui mène une entrevue ne demande pas votre âge et ne le devine pas à partir de votre CV. Elle peut vérifier si vos connaissances sont assez à jour pour le travail. Les anciens noms d’outils ne posent pas de problème si vous pouvez expliquer les idées qu’ils représentent. Le problème apparaît seulement quand un candidat parle en noms d’outils que la personne qui l’interroge ne connaît pas.

Termes utilisés dans cette page

• Totaux de contrôle : nombres calculés à la source, puis après le chargement, comme le nombre de lignes et la somme d’un montant. S’ils ne correspondent pas, quelque chose a été perdu ou ajouté.
• Rapprochement : comparaison de deux systèmes ou de deux tables jusqu’à ce que chaque différence ait une explication.
• Date d’affaires (ou heure de l’événement) : date à laquelle un enregistrement appartient, et non sa date de chargement.
• Repère de progression (high-water mark) : dernier horodatage ou identifiant déjà lu par un chargement. L’exécution suivante commence après ce repère.
• Filigrane (watermark, en traitement en continu) : délai d’attente des événements en retard avant qu’un traitement en continu ferme une fenêtre temporelle.
• Remplacement de partitions : remplacement de partitions entières d’une table (ici, des journées entières) par une nouvelle version.
• MERGE : instruction SQL qui met à jour les lignes existantes, associées par une clé, et insère les autres.
• Traitement exactement une fois de Kafka : fonctions de Kafka (producteur idempotent et transactions) qui empêchent les doublons lorsqu’un producteur réessaie. Elles permettent aussi à un traitement de lire dans Kafka et d’écrire dans Kafka comme une seule unité. Le producteur idempotent est activé par défaut dans les versions récentes. Donc, « activer le traitement exactement une fois » signifie généralement utiliser des transactions.
• Point de contrôle (checkpoint) : trace qu’un traitement en continu conserve de ce qu’il a déjà traité, pour reprendre là où il s’est arrêté.

L’entrevue

Minutes 0 à 5 : le début

Esther(intervieweur) :

Bonjour Vikram. Désolée, j’ai deux minutes de retard, ma dernière réunion a été longue. Donc, je suis Esther, ingénieure de données principale dans l’équipe Data Platform. Je travaille surtout sur les données de facturation. Le plan : d’abord, un pipeline que vous avez construit ou dont vous êtes responsable. Je vais poser des questions détaillées. Ensuite, un de nos vrais problèmes. Puis vos questions. Et pas d’outils d’IA pour cette étape, s’il vous plaît. Le papier, c’est bien. Il y a aussi un tableau blanc si vous voulez dessiner.

Vikram(personne candidate) :

Aucun problème. Bien, je réfléchis toujours mieux avec du papier. J’en ai ici.

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

Esther(intervieweur) :

Alors, parlez-moi d’un pipeline que vous connaissez bien.

Vikram(personne candidate) :

Je vais prendre le chargement des transactions par carte chez Westmark. J’en étais responsable pendant plusieurs années, sur l’ancienne plateforme et la nouvelle. Alors. Chaque nuit, le système de cartes envoie un fichier avec les transactions de la journée. Environ 15 millions de lignes, plus en décembre. On le charge, on le vérifie. Le lendemain matin, les finances, la gestion des risques et les rapports réglementaires l’utilisent.

Sur l’ancienne plateforme, Informatica lisait le fichier et chargeait Teradata. Le mappage faisait une recherche dans la dimension des comptes, puis une transformation de stratégie de mise à jour, puis…

Esther(intervieweur) :

Désolée, je peux vous arrêter? Je connais mal Informatica. Qu’est-ce que ça faisait, en mots simples?

Vikram(personne candidate) :

Ah, désolé. Oui. En mots simples : lire le fichier, vérifier que chaque ligne a un compte valide. Puis écrire dans la table les lignes de cette date d’activité. Et avant ça, vérifier la fin du fichier. Le système de cartes écrit le nombre de lignes et le montant total à la fin du fichier. On compare avec ce qu’on a chargé. Si la différence est d’un cent, le chargement s’arrête.

Où cela tourne mal

Vikram a commencé à expliquer son travail à travers l’outil : les mappages et les transformations dans Informatica. Esther ne connaît pas l’outil, donc elle ne peut pas juger le travail. Il corrige vite son explication quand elle le demande. Si vous connaissez bien des outils plus anciens, décrivez d’abord l’idée (« lire, vérifier, écrire par date d’activité »). Nommez l’outil seulement si la personne qui mène l’entrevue le demande.

Esther(intervieweur) :

D’accord, c’est clair. Et si le traitement échoue à mi-chemin, comment le relancez-vous?

Vikram(personne candidate) :

On supprime toujours toute la date d’activité et on la recharge. Jamais d’ajout. J’ai appris ça en 2011, de façon pénible.

Esther(intervieweur) :

Parlez-moi de 2011.

Vikram(personne candidate) :

Le système de cartes avait un problème. Ils ont renvoyé le fichier de la même journée, avec un nouveau nom. Notre traitement a vu un nouveau fichier et l’a ajouté. Donc cette journée était dans la table deux fois. On a calculé des intérêts dessus, pour environ trois mille comptes, je pense. Peut-être un peu plus.

Les totaux de contrôle l’ont détecté le lendemain matin, avant l’envoi des relevés aux clients. Mais un rapport réglementaire était déjà parti. On a dû envoyer un rapport corrigé, avec une lettre. Pas une bonne semaine.

Esther(intervieweur) :

Un instant de silence. J’étais de garde pour notre double facturation le mois dernier. Je connais ce sentiment.

Vikram(personne candidate) :

Alors vous savez. Après ça, deux changements. Un, le chargement remplace toute la date d’activité. Deux, on garde un registre de chaque fichier, avec une somme de contrôle. Si le même contenu revient, peu importe le nom, on arrête et on demande à une personne.

Pourquoi cela fonctionne

Ce récit d’incident contient tout ce dont Esther a besoin. Ce qui s’est passé, comment on l’a découvert (les totaux de contrôle), les dommages et les changements pour éviter une répétition. « Remplacer toute la date d’activité », c’est l’écrasement de partition. Vikram connaissait l’idée 15 ans avant le nouveau nom.

Esther(intervieweur) :

D’accord. Maintenant, la migration. Comment saviez-vous que la nouvelle plateforme donnait les bons résultats?

Vikram(personne candidate) :

On a fait fonctionner les deux pendant quatre mois. Chaque matin, un traitement comparait chaque table, par date d’activité. Nombre de lignes, somme des montants et quelques décomptes par produit. Chaque différence allait sur une liste, et quelqu’un devait donner une raison.

Esther(intervieweur) :

Quel genre de différences?

Vikram(personne candidate) :

Surtout petites. La célèbre, c’était un cent. Un traitement Spark lisait les montants en double précision, pas en décimal. Sourit. L’ingénieur qui l’a trouvé était très content. On a corrigé le type et ajouté une vérification des types des colonnes.

Esther(intervieweur) :

Et vous écriviez le code vous-même? Ou vous dirigiez?

Vikram(personne candidate) :

Les deux. Les traitements de rapprochement, je les ai écrits moi-même en PySpark. La dernière année, moins de code, plus de révisions et de planification. Honnêtement, je suis plus lent en PySpark qu’en SQL. Le SQL, j’en écris depuis 24 ans.

Esther(intervieweur) :

D’accord, c’est honnête.

Esther a aussi posé des questions sur les coûts après le départ de Teradata. La première facture du nuage les avait surpris. Beaucoup de requêtes lisaient tous les fichiers de la table, parce que les analystes ne filtraient pas par date. L’équipe a partitionné les données par date d’activité et demandé aux gens de toujours filtrer sur cette date. La facture a baissé « d’un peu plus de la moitié, je pense ». Vikram ne se rappelait pas le chiffre exact, et il l’a dit.

Minutes 25 à 40 : le problème de Tidewell

Esther(intervieweur) :

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

Vikram(personne candidate) :

Une question d’abord. « Facturé deux fois ». Les lectures étaient deux fois dans la table, ou la facture a été produite deux fois?

Esther(intervieweur) :

Les lectures. La relance a ajouté la même date d’arrivée encore une fois, et la facturation les a additionnées.

Vikram(personne candidate) :

D’accord. Donc, comme mon incident de 2011. Le traitement raisonne en date de chargement, mais la facturation raisonne en date d’activité. Ici, la date d’activité, c’est la date de lecture. Donc la table nettoyée est organisée par date de lecture. Chaque nuit, on reconstruit les dates de lecture qui peuvent encore changer. Supprimer et charger la journée complète. Jamais d’ajout.

Esther(intervieweur) :

Hum-hum. Comment savez-vous quelles dates de lecture peuvent encore changer?

Vikram(personne candidate) :

Pour chaque source, on garde un high-water mark, un repère de progression. Ensuite…

Esther(intervieweur) :

Un watermark, un filigrane, vous voulez dire? Comme dans le traitement en continu de Spark?

Vikram(personne candidate) :

Hmm. Peut-être pas la même chose. Je vais expliquer ce que je veux dire, puis vous me direz. Pour moi, le high-water mark, c’est la dernière heure d’arrivée qu’on a déjà chargée. L’exécution suivante lit tout ce qui vient après. Ensuite, je regarde quelles dates de lecture sont dans ces nouvelles lignes, et je reconstruis ces dates.

Esther(intervieweur) :

Ah, d’accord. Alors c’est différent. Dans le traitement en continu de Spark, un watermark indique combien de temps un traitement attend les événements en retard. Après, il ferme une fenêtre. Notre flux n’en utilise pas. Il ajoute seulement les lectures brutes. Désolée, j’ai conclu trop vite.

Vikram(personne candidate) :

Non, c’est bien, maintenant je connais votre mot. Donc le mien, c’est « qu’est-ce que j’ai déjà lu », et le vôtre, « combien de temps j’attends ». Pour la facturation, il nous faut les deux, je pense. Mais l’attente peut se faire dans le traitement par lots.

Deux mots qui se ressemblent

Un high-water mark suit la progression selon l’arrivée : « J’ai tout lu jusqu’ici ». Un watermark de traitement en continu concerne l’heure de l’événement : « Je n’attends plus les événements plus anciens que ça ». Ils se ressemblent et sont liés, mais ils répondent à des questions différentes. Esther a supposé qu’ils étaient identiques. Vikram n’a pas débattu du mot. Il a expliqué ce qu’il voulait dire, et ils ont trouvé la différence ensemble. Si vous doutez qu’un terme ait le même sens pour deux personnes, décrivez-le en mots simples.

Esther(intervieweur) :

D’accord. Et pour la reconstruction elle-même. Dans Delta, utiliseriez-vous MERGE ou écraseriez-vous les journées?

Vikram(personne candidate) :

Je n’ai pas écrit de MERGE sur Delta. Sur Teradata, souvent. Je m’attends à la même idée : faire correspondre l’identifiant du compteur et l’heure de lecture. Mettre à jour si ça existe, insérer sinon. Mais ici, je préfère remplacer les journées. Plus facile à comprendre. Après le traitement, la journée correspond exactement aux données brutes, après dédoublonnage. Avec MERGE, si la source a la même clé deux fois, ça va mal. Sur Teradata, c’était une erreur, je pense. Ici, je ne sais pas.

Esther(intervieweur) :

Seulement si la clé est déjà dans la table. Alors le message dit que plusieurs lignes sources correspondent. Si la clé est nouvelle, les deux lignes entrent, et personne ne le voit.

Vikram(personne candidate) :

Alors c’est pire. Donc, dédoublonnage d’abord, toujours : une ligne par compteur et heure de lecture.

Esther(intervieweur) :

D’accord. Maintenant, un point dont on discute. L’équipe plateforme veut activer exactly-once, le traitement exactement une fois, dans Kafka. Alors les doublons disparaissent, de bout en bout, je pense. Donc peut-être qu’on n’a pas besoin du dédoublonnage après.

Vikram(personne candidate) :

Hmm. Je peux être un peu en désaccord?

Esther(intervieweur) :

Bien sûr.

Vikram(personne candidate) :

L’exactly-once de Kafka concerne Kafka. Le producteur n’écrit pas le même message deux fois quand il réessaie. Et avec les transactions, un traitement qui lit dans Kafka et réécrit dans Kafka peut faire les deux ensemble. C’est bien, on l’a utilisé. Mais notre doublon du mois dernier, d’où venait-il?

Esther(intervieweur) :

De la relance du traitement de nuit par lots.

Vikram(personne candidate) :

Oui. Ce traitement n’est pas du tout dans Kafka. L’exactly-once ne peut pas le voir. Et le système de collecte des compteurs. S’il perd la connexion et renvoie la même lecture, pour Kafka ce sont deux messages différents. Kafka ne peut pas savoir que c’est la même lecture. Seule la clé le sait : compteur et heure de lecture.

Esther(intervieweur) :

Et le flux de Kafka vers la table Delta brute? Celui-là est exactly-once, avec le point de contrôle.

Vikram(personne candidate) :

Oui, tant que le point de contrôle est intact. Si quelqu’un le supprime et relance le traitement depuis une position antérieure, pour ne rien perdre, il réécrit les mêmes lignes. À la banque, c’est arrivé une fois, après un changement de grappe. Donc je dirais : l’exactly-once dans Kafka, c’est bien de l’avoir. Mais la table doit se protéger elle-même. Dédoublonnage ou MERGE par clé, chaque fois qu’on écrit.

Esther(intervieweur) :

Pause. D’accord. Vous avez raison. Je pensais seulement à la partie en continu, de Kafka vers les données brutes. Pour la facturation, c’est la clé qui nous protège. Je vais aussi le dire à l’équipe plateforme.

Bien exprimer un désaccord

Esther a fait une affirmation que beaucoup d’ingénieurs croient : l’exactly-once de Kafka élimine les doublons « de bout en bout ». Vikram a d’abord demandé s’il pouvait être en désaccord. Ensuite, il n’a pas fait la leçon. Il a demandé d’où venait le doublon du mois dernier, et laissé Esther répondre. Ses points sont corrects :

• Les garanties de Kafka couvrent les écritures à l’intérieur de Kafka.
• Une lecture que le système de collecte renvoie est un nouveau message.
• Une relance de traitement par lots est en dehors de Kafka.
• Une table est protégée seulement si chaque écriture utilise la clé.

Il a terminé par ce qu’il faut faire, pas par « vous avez tort ». Esther a accepté et précisé exactement où son raisonnement s’arrêtait. Voir Les personnes qui mènent les entrevues n’ont pas toujours raison.

Vikram a ensuite demandé combien de lectures arrivent après trois jours. Très peu, a dit Esther, sauf après une grosse tempête. Peut-être un ou deux pour cent des compteurs, pendant une semaine au maximum. Alors la facturation ne devrait pas les attendre, a-t-il dit. Facturer avec ce qu’on a, estimer les heures manquantes, les marquer comme estimées et corriger sur la prochaine facture. Il espérait que les opérations de facturation, et non l’équipe de données, décident des règles d’estimation. Esther l’a confirmé : l’équipe de Rosa.

Minutes 40 à 50 : le rapprochement et la limite de ses connaissances

Esther(intervieweur) :

Et comment sauriez-vous que les données sont correctes avant le lancement de la facturation à 5 h?

Vikram(personne candidate) :

Les totaux de contrôle, comme à la banque. Donnez-moi une minute, je veux le dessiner.

Il écrit sur papier pendant environ une minute. Esther attend.

Vikram(personne candidate) :

D’accord. Trois points à vérifier, chaque nuit, par date de lecture. Les données brutes, les données nettoyées et les données d’entrée de la facturation. À chaque point, deux nombres : le nombre de lectures et le total des kWh.

Esther(intervieweur) :

Et entre les données brutes et nettoyées?

Vikram(personne candidate) :

Le nombre diminue seulement à cause des doublons et des lignes rejetées, et on consigne ces deux nombres. Entre les données nettoyées et la facturation, ça doit correspondre exactement. Et une troisième vérification : les lectures attendues. 1,2 million de compteurs fois 96, donc environ 115 millions par jour. Sauf les deux jours de changement d’heure.

Esther(intervieweur) :

92 et 100.

Vikram(personne candidate) :

Oui. Si la différence n’a pas de raison, la facturation attend, et une personne décide. Les données de facturation doivent concorder au cent près. À la banque, on faisait ça chaque jour. Je ne lancerais pas la facturation sans ça.

Esther(intervieweur) :

Les doublons et les rejets, en chiffres chaque jour. J’aime ça. Si ça augmente brusquement, quelque chose a changé en amont.

Vikram(personne candidate) :

Exactement. Ce nombre nous a dit deux fois que le système de cartes avait un problème, avant qu’ils nous le disent.

Pourquoi c'est la meilleure réponse de la journée

Vikram transforme « les données sont-elles correctes? » en vérifications qui s’exécutent chaque nuit. Chaque nombre a une raison de changer, et une différence sans raison arrête la facturation. Le décompte quotidien des doublons supprimés aurait détecté l’incident du mois dernier. Voilà ce que « 24 ans » signifie en pratique.

Esther(intervieweur) :

Encore une question sur le flux. L’équipe de prévision nous a demandé des totaux horaires directement à partir du flux, avec trois jours d’attente. Qu’arrive-t-il à l’état dans Spark?

Vikram(personne candidate) :

Désolé, pouvez-vous répéter la question? L’état de quoi?

Esther(intervieweur) :

L’état que le traitement en continu conserve. La fenêtre ouverte pour chaque compteur et chaque heure, pendant qu’il attend les lectures en retard.

Vikram(personne candidate) :

Ah. Honnêtement, je connais mal l’état du traitement en continu de Spark. Je n’ai pas utilisé Structured Streaming en production. À la banque, notre traitement en continu allait seulement de Kafka vers les tables brutes. Mon hypothèse : il garde chaque fenêtre ouverte jusqu’au passage du watermark. Donc trois jours de fenêtres pour 1,2 million de compteurs. Je voudrais mesurer la taille que ça atteint avant de lui faire confiance.

Esther(intervieweur) :

C’est à peu près ça. Il garde les fenêtres ouvertes dans un stockage d’état, et ça peut devenir gros.

Une réponse plus forte à la limite de ses connaissances

Vikram a été honnête sur sa limite, et son hypothèse était proche. Il pourrait aller un peu plus loin avec ce qu’il sait déjà :

« Est-ce qu’on a vraiment besoin de cet état? Si le flux ajoute seulement les lectures brutes, le traitement de nuit reconstruit les dates de lecture qui ont changé. Les données en retard sont alors traitées par lots. Le flux n’attend donc rien pendant trois jours. Je garderais le flux simple, et je placerais l’attente là où elle coûte peu. »

Quand vous arrivez à une fonction d’un outil que vous ne connaissez pas, demandez si la conception en a vraiment besoin.

Esther a ensuite posé des questions sur les remplacements de compteurs. Vikram a tout de suite vu un problème d’historique. À la banque, il conservait l’historique des comptes dans une dimension de type 2, avec des dates de début et de fin de validité. Comme le CRM ne garde aucun historique, il a demandé une autre trace des remplacements. Esther a nommé les ordres de travail sur le terrain. Sur l’assistant d’IA, il a posé une question : « Ses chiffres vont-ils correspondre à la facture? Si l’assistant dit 410 kilowattheures et la facture dit 412, le client appelle l’équipe de Rosa. » Il a proposé que l’assistant lise la même table vérifiée que la facturation.

Minutes 50 à 57 : les questions de Vikram

Vikram(personne candidate) :

J’en ai trois. Première : quand le système de collecte change son format d’exportation, comment l’apprenez-vous?

Esther(intervieweur) :

Petit rire. Habituellement, quand le traitement échoue. Le fournisseur ne nous le dit pas.

Vikram(personne candidate) :

D’accord. Ça, je l’ai déjà vu. Deuxième : à 5 h, si les vérifications échouent, qui peut décider de retarder la facturation? L’ingénieur de garde, ou quelqu’un à la facturation?

Esther(intervieweur) :

Bonne question. Aujourd’hui… ce n’est pas écrit. Le mois dernier, j’ai appelé Rosa chez elle.

Vikram(personne candidate) :

Je mettrais ça par écrit rapidement. La personne de garde ne devrait pas décider seule. Dernière question. De quoi l’équipe a-t-elle le plus besoin dans la prochaine année?

Esther(intervieweur) :

Honnêtement? Quelqu’un qui a déjà géré des données assez fiables pour la facturation. On est de bons ingénieurs, mais la plupart viennent de l’analytique.

Des questions tirées de l'expérience

Les questions de Vikram viennent d’incidents qu’il a vécus, et chaque réponse lui apprend quelque chose de concret. Aucun avertissement sur les changements de format, et personne n’est responsable de la décision de 5 h. Sa dernière question permet à Esther de dire ce dont l’équipe a besoin. Sa réponse correspond à son expérience, et il n’a pas eu à le dire lui-même.

Minutes 57 à 60 : la fin

Esther(intervieweur) :

Merci, Vikram. Vraiment. Et merci pour le point sur Kafka, je le pense sincèrement. Aisha vous contactera pour les prochaines étapes.

Vikram(personne candidate) :

Merci. Et bonne chance avec l’équipe plateforme. Sourit. Montrez-leur d’abord la relance du traitement par lots.

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

Vikram Rao, examen approfondi de la conception du pipeline

• Réexécutions et données tardives : preuves solides. Remplace les dates d’affaires complètes depuis 2011, après un incident réel. Reconstruit seulement les dates de relevé qui ont changé. Élimine les doublons par clé avant toute écriture.
• Qualité des données et rapprochement : preuves solides. Totaux de contrôle à trois étapes, nombre attendu tenant compte de l’heure avancée. Nombres de doublons supprimés et de lignes rejetées comme indicateur quotidien. Meilleure réponse sur ce sujet jusqu’ici.
• Kafka et traitement en continu : quelques preuves. M’a corrigée, à juste titre, sur la garantie de traitement exactement une fois. N’a pas utilisé Spark Structured Streaming en production et l’a dit.
• Outils actuels : quelques preuves. Expérience pratique de PySpark pour les tâches de rapprochement. N’a pas utilisé Delta MERGE, mais connaît bien le principe. Quelques termes plus anciens (high-water mark, repère maximal), expliqués clairement.
• Exploitation et garde : preuves solides. Dix ans à diriger la garde. A demandé qui peut retarder la facturation à 5 h : une lacune chez nous.
• Coût : quelques preuves. Partitionnement et filtres après une facture infonuagique inattendue. Ne se souvenait pas du montant et l’a dit.

Recommandation : oui sans hésitation. Il apporte ce qui nous manque le plus : une rigueur à la hauteur des exigences de facturation. Il apprendra les détails de Delta et du traitement en continu en quelques semaines. Son jugement s’est construit sur 24 ans.

La suite

L’entrevue de modélisation des données avec Pierre s’est très bien passée. Sans aide, Vikram a dessiné l’historique des liens entre comptes et compteurs comme une dimension de type 2. Il a posé de bonnes questions sur le niveau de détail de la table de prévisions. Rosa a donné un oui clair après son entrevue. Elle a écrit : « Il parle de la facture du client au cent près. Et il a demandé qui décide à 5 h avant moi. »

Pendant le bilan, une personne a demandé, avec prudence, si Vikram serait heureux dans un rôle sans gestion de personnel. Graham a dit que l’équipe ne devait pas le deviner. Aisha a posé la question directement à Vikram à l’appel suivant. Il a dit vouloir revenir au travail pratique et avoir choisi ce niveau volontairement.

Il y avait un seul poste vacant. Graham l’a offert à Vikram : ingénieur de données, 142 000 $ CA plus une prime. Vikram l’a remercié et a demandé un changement : le titre d’ingénieur de données principal. Il a expliqué ses raisons. Dès le départ, il serait responsable de la conception du rapprochement, dirigerait les bilans d’incidents et appuierait la rotation de garde. Chez Tidewell, ce sont des responsabilités de niveau principal. Graham a consulté les ressources humaines et a accepté. Il a aussi porté le salaire à 148 000 $ CA, toujours dans la fourchette affichée. Vikram a accepté.

Il a demandé ce qui correspondait au travail et l’a expliqué en fonction des besoins de l’équipe. C’est une issue réaliste, pas une promesse. Une autre entreprise aurait pu lire le même CV autrement. La chance joue aussi un rôle.

Ce qu’il faut retenir

• Votre expérience est une preuve, pas un âge. Vikram n’a jamais parlé de ses années d’expérience. Il a parlé de l’incident de 2011, de l’exécution en parallèle et de l’écart d’un cent. Les années se voyaient dans ses réponses.
• Décrivez l’idée, puis l’outil. « Remplacer la date d’affaires complète » est clair pour tout le monde. « Une transformation de stratégie de mise à jour » parle à peu de gens aujourd’hui.
• Quand un mot peut avoir plusieurs sens, expliquez le vôtre. Le repère maximal et le watermark (filigrane) désignaient des idées différentes. Des mots simples ont révélé la différence en deux échanges.
• Soyez précis sur les limites de votre expérience. « Je n’ai pas écrit de MERGE sur Delta; sur Teradata, plusieurs fois » est à la fois honnête et utile.
• Négociez en fonction du travail, pas de votre propre valeur. Vikram a demandé le titre à cause des responsabilités, et il les a nommées.

Si votre profil ressemble à celui de Vikram

1. Faites un petit dictionnaire reliant vos anciens termes aux nouveaux. Date d’affaires et heure de l’événement; suppression et rechargement et remplacement de partition; repère maximal et curseur incrémental; totaux de contrôle et vérifications de qualité des données. Exercez-vous à dire l’idée d’abord, avec des mots simples.
2. Réalisez un projet pratique avec un format de table actuel. Écrivez un MERGE et un remplacement de partition sur Delta ou Iceberg. Exécutez-les deux fois et comparez les totaux avec des vérifications écrites sous forme de code. Vous pourrez alors dire « Je l’ai fait » plutôt que « Je connais le principe ». Consultez Livrer un jeu de données réutilisable et Les règles de validation.
3. Apprenez les limites des garanties du traitement en continu. Lisez comment fonctionnent les transactions Kafka et un point de contrôle du traitement en continu. Écrivez un paragraphe sur ce qu’ils ne protègent pas. La plupart des personnes qui vous font passer une entrevue ne s’y attendront pas, et cela montre votre jugement.
4. Transformez vos incidents en courts récits. Ce qui s’est passé, comment vous l’avez découvert, les dégâts, ce qui a changé. Deux ou trois suffisent. Consultez Expliquer vos décisions.
5. Concentrez votre CV sur les 10 à 15 dernières années. Résumez les premiers postes en une ligne. Ce n’est pas cacher votre parcours; c’est présenter vos preuves les plus solides en premier. Consultez Les éléments d’un portfolio et Votre expérience est une longueur d’avance.