L'experte du domaine

Imaginez une mécanicienne qui apprend à écrire des logiciels pour les garages. Elle connaît moins bien le code que les développeurs. Mais elle sait quels voyants donnent de fausses alertes et quels problèmes les clients oublient de mentionner. Les développeurs ont besoin d’années pour apprendre cela.

On trouve aussi des personnes comme elle en ingénierie de données. Elles travaillaient en facturation ou sur le terrain et voyaient chaque jour des erreurs dans les données. Elles ont appris SQL et Python le soir pour les corriger. Quand elles postulent, elles pensent souvent : « Je ne suis pas vraiment ingénieure. » Notre leçon Votre expérience est une longueur d’avance explique pourquoi elles apportent plus qu’elles ne le pensent.

Mais une entrevue sérieuse vérifie les deux côtés : votre connaissance des données et votre capacité à construire à l’échelle de l’entreprise. Suivez Nicole pendant l’examen approfondi de la conception d’un pipeline mené par Esther. Observez comment ses questions changent la conception, et ce qu’elle fait lorsqu’elle atteint les limites de ses connaissances.

NT

La personne candidate

Nicole Tremblay

Coordonnatrice des opérations de comptage, 7 ans chez un fournisseur d'électricité au Québec, a appris SQL et Python le soir

• 7 ans dans les opérations de comptage
• SQL et Python, environ 4 ans (le soir)
• Français langue première, anglais langue seconde
• Vancouver, Colombie-Britannique (depuis 2025)

• Coordonnatrice des opérations de comptage, Nordet Énergie (2021 à 2025). Planifiait les remplacements de compteurs et les visites sur le terrain pour environ 180 000 compteurs dans une région. Travaillait avec les équipes sur le terrain, la facturation et le service à la clientèle.
• Technicienne en données de comptage, Nordet Énergie (2018 à 2021). Vérifiait les relevés estimés et manquants avant la facturation.
• A construit un pipeline de données automatisé qui repère les compteurs dont les relevés sont manquants. A réduit de 40 % le nombre de compteurs sans relevé depuis 30 jours ou plus.
• Python (pandas), SQL (PostgreSQL), Spark (notions de base), Git.
• Cours en ligne sur SQL, Python et l’ingénierie de données (2022 à 2026).

Ce qu’Esther voit avant l’appel

Nicole ne répond pas aux principales exigences de l’offre : aucune année comme ingénieure de données, aucun Kafka, aucun Spark en production, aucun dbt. « Spark (notions de base) » signifie probablement un tutoriel. Si on lisait son CV comme une liste de critères à cocher, elle n’obtiendrait pas d’appel.

Mais Graham y a écrit une phrase : « Elle connaît les compteurs mieux que nous tous. » Les problèmes à résoudre chez Tidewell concernent les relevés tardifs, les remplacements de compteurs et les journées de changement d’heure. Ce sont des problèmes de comptage avant d’être des problèmes de Spark. Esther note ce qu’elle veut découvrir :

• Qu’est-ce que Nicole a vraiment construit? Où cela fonctionne-t-il, et que se passe-t-il en cas de panne?
• « Réduit de 40 % » : comment sait-elle que son pipeline a causé cette réduction?
• Pour le problème de Tidewell, sa connaissance du domaine se traduit-elle en décisions de conception?
• Où s’arrêtent ses compétences en ingénierie? Esther s’attend à une limite liée au volume : 115 millions de relevés par jour.

Termes utilisés dans cette page

• Relevé par intervalle : l’énergie qu’un compteur a mesurée sur une courte période, ici 15 minutes. Une journée normale en compte 96.
• Relevé du registre : le total affiché sur le compteur, comme les kilomètres d’une voiture. Il ne fait qu’augmenter. La différence entre deux relevés du registre correspond à l’énergie utilisée entre les deux.
• Relevé estimé : une valeur que le fournisseur d’électricité calcule quand le relevé réel manque. Il peut utiliser, par exemple, la même période de l’année précédente. Un relevé réel ultérieur la corrige.
• Remplacement de compteur : une équipe sur le terrain remplace un compteur. Le nouveau compteur a un nouvel identifiant et un nouveau registre.
• Système de collecte (head-end system) : le système du fabricant qui collecte les relevés des compteurs par le réseau.
• VEE (validation, estimation et correction) : le processus habituel du fournisseur d’électricité qui vérifie les données de comptage et comble les lacunes avant la facturation.
• Idempotent : exécuter le traitement deux fois avec les mêmes données d’entrée donne le même résultat qu’une seule exécution.
• MERGE (ou upsert, mise à jour ou insertion) : une écriture qui met à jour une ligne si sa clé existe déjà, sinon qui l’insère.
• SCD Type 2 (dimension à évolution lente, type 2) : une table qui conserve l’historique d’un lien, plutôt que seulement sa valeur actuelle. Chaque ligne contient une date de « début de validité » et une date de « fin de validité ».

L’entrevue

Minutes 0 à 5 : l'ouverture

Esther(intervieweur) :

Bonjour Nicole, vous m’entendez bien? Je suis Esther, ingénieure de données principale dans l’équipe Data Platform. Alors, voici le plan. D’abord, un pipeline que vous avez construit, et je vais poser beaucoup de questions. Ensuite, un vrai problème chez nous. Puis vos questions. Pas d’outils d’IA pour cette étape, s’il vous plaît. Le papier, c’est permis.

Nicole(personne candidate) :

Oui, je vous entends. Désolée, ma caméra a pris du temps à démarrer. J’ai du papier. Et juste pour vous prévenir, ma langue maternelle est le français. Si je dis quelque chose de bizarre, posez-moi la question.

Esther(intervieweur) :

Bien sûr. J’ai grandi avec le yoruba et l’anglais, alors je comprends. Allons-y.

Minutes 5 à 25 : le pipeline des relevés manquants, puis les questions approfondies

Esther(intervieweur) :

Alors, parlez-moi du pipeline.

Nicole(personne candidate) :

D’accord. Alors, chez Nordet, ma région avait environ 180 000 compteurs. Chaque matin, les coordonnateurs cherchaient les compteurs sans relevés. Parce que sans relevé, la facture est estimée, et ensuite les clients appellent. Avant, c’était un rapport dans Excel, très lent. On trouvait le problème après un ou deux mois.

Ce que j’ai fait, c’est un script Python. Chaque matin, il prend l’export de notre système de données de compteurs. C’est un CSV avec le relevé quotidien du registre de chaque compteur. Seulement les relevés quotidiens, parce que l’informatique disait que les intervalles de 15 minutes étaient trop volumineux pour ma base. Le script met ça dans PostgreSQL. Ensuite, SQL trouve les compteurs sans relevé depuis trois jours ou plus, et prépare une liste pour les équipes sur le terrain.

Esther(intervieweur) :

Hum-hum. Et si les relevés d’une journée arrivent en retard, qu’est-ce qui se passe?

Nicole(personne candidate) :

L’export contient toujours les 14 derniers jours. Alors chaque matin, je supprime les 14 derniers jours dans ma table et je les charge à nouveau. Si un relevé arrive en retard, il est dans l’export suivant, et il va dans la bonne journée.

Esther(intervieweur) :

Et qu’est-ce qui se passe si le script s’exécute deux fois?

Nicole(personne candidate) :

Deux fois… il supprime encore et recharge encore. Alors, la même table. Oui. Le même résultat.

Esther(intervieweur) :

La suppression et le chargement sont dans une seule transaction?

Nicole(personne candidate) :

Hum. Non, je ne pense pas. Donc si ça échoue au milieu, il me manque 14 jours. C’est arrivé une fois, je pense. La liste était vide. Les équipes étaient contentes ce jour-là.

Comment Esther approfondit les questions

Nicole a rendu son chargement idempotent sans connaître le mot : elle remplace une fenêtre de 14 jours. Les relevés en retard vont donc à la bonne journée, et une deuxième exécution ne change rien. Ensuite, Esther pousse la vérification un peu plus loin. Sans transaction unique, un échec au milieu laisse un trou. Nicole le voit elle-même. Dans son outil, c’est une petite lacune. Dans une table de facturation, cela peut coûter de l’argent.

Esther(intervieweur) :

D’accord. Comment saviez-vous que la liste était correcte? Qu’elle trouvait les bons compteurs?

Nicole(personne candidate) :

Les équipes. Après une visite, elles écrivent ce qu’elles ont trouvé : un modem mort, un compteur brisé, personne qui habite là. Au début, la liste était mauvaise. Peut-être 300 compteurs par jour, et beaucoup n’avaient rien. À cause des zéros.

Ma première version disait : aucune consommation pendant trois jours, c’est un problème. Mais en janvier, la moitié de ma liste, c’était des chalets. Hum, des maisons de vacances? Des maisons d’été dans la forêt. Personne n’est là en hiver, le compteur indique zéro. C’est un vrai zéro. Alors j’ai envoyé des équipes à des chalets vides dans la neige. Elles n’étaient pas contentes de moi.

Esther(intervieweur) :

Rit. Je vous crois. Alors, qu’avez-vous changé?

Nicole(personne candidate) :

J’ai séparé les zéros. Un zéro peut être réel, comme au chalet. Un zéro peut venir d’un compteur qu’on a déconnecté à distance. Réel aussi, mais la facturation doit le savoir. Et parfois, le système écrit un zéro quand il n’y a pas de relevé. Celui-là, ce n’est pas un zéro, c’est une valeur manquante. Alors j’ai utilisé les indicateurs dans l’export, et le type de client. Après, la liste était plutôt de 100, 120 par jour. Et les équipes disaient que la plupart étaient de vrais problèmes. Peut-être sept sur dix.

Trois sortes de zéro

C’est une connaissance du domaine qui devient une règle dans les données. Sans elle, un ingénieur de données voit un seul nombre, 0. Il traite de la même façon un vrai zéro, un compteur déconnecté et une valeur manquante remplacée par zéro.

Esther pose aussi une question sur les 40 % du CV. Nicole est honnête : la même année, un programme a remplacé de vieux modems dans les compteurs. Les 40 % concernent donc toute la région, et elle ne connaît pas sa propre contribution. « Les équipes allaient plus vite, ça, j’en suis sûre. Mais les 40 %, ce n’est pas juste moi. Je devrais mieux l’écrire. » Ensuite, Esther demande quelle a été la pire journée. Après une mise à niveau du système de données de compteurs, deux colonnes du CSV ont changé d’ordre. Personne n’a prévenu Nicole. Son script lisait les colonnes selon leur position. La liste a donc été fausse pendant deux jours, et les équipes ont fait environ 40 visites aux mauvais compteurs. Maintenant, le script lit les colonnes par leur nom et s’arrête en envoyant un courriel si une colonne manque. « Je préfère pas de liste à une mauvaise liste », dit-elle. Sur les coûts, elle est honnête : le serveur appartenait à l’informatique, et elle n’a jamais vu de facture. Personne n’a révisé son code. Elle a quelques tests pytest pour les règles sur les zéros, aucun pour le chargement.

Où cela tourne mal

Ici, la lacune concerne l’ingénierie de production. L’outil fonctionnait sur un seul serveur, sans révision, avec peu de tests et une seule personne qui le connaissait. Cela convenait à une équipe. Le traitement de facturation de Tidewell s’exécute à 5 h pour 1,2 million de compteurs, avec une personne de garde. Esther ne pénalise pas Nicole pour avoir travaillé seule. Mais elle note que Nicole n’a jamais travaillé sur une base de code partagée avec des révisions.

Minutes 25 à 50 : le problème de Tidewell

Esther(intervieweur) :

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. Notre traitement de nuit 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 de prévision dit que son historique a des trous. Comment concevriez-vous le pipeline de relevés de compteurs pour éviter que cela se reproduise?

Nicole(personne candidate) :

D’accord. Est-ce que je peux poser une question sur la facturation d’abord? Quand des relevés sont en retard le jour de facturation, la facturation attend ou fait une estimation? Et vous facturez à partir des intervalles ou du relevé du registre?

Esther(intervieweur) :

Bonnes questions. La facturation s’exécute à 5 h à partir de nos modèles dbt, avec les intervalles. S’il manque des relevés, le système de facturation fait une estimation. Les relevés du registre… je pense que le système central en envoie un par jour, mais nous ne l’utilisons pas. Il reste simplement dans la table brute.

Nicole(personne candidate) :

D’accord, intéressant, je vais revenir là-dessus. Alors, première chose. Vous stockez le relevé selon l’heure de la mesure, pas l’heure de son arrivée. La relève… pardon, le relevé du lundi reste un relevé du lundi, même s’il arrive le jeudi.

Esther(intervieweur) :

Dessine une boîte au tableau. L’heure de l’événement. Donc la table est partitionnée par date de relevé. Ensuite, que fait le traitement de nuit?

Nicole(personne candidate) :

Comme mes 14 jours? Chaque nuit, il reprend les derniers jours et les remplace. Trois jours, ou plus. Après la tempête de verglas de 2023, certains de nos compteurs avaient une semaine de retard.

Esther(intervieweur) :

Nous avons eu la même chose après une tempête de vent l’hiver dernier. Mais pensez à notre volume. 115 millions de relevés par jour. Si nous remplaçons 14 jours chaque nuit, ça fait combien?

Nicole(personne candidate) :

115 fois 14… attendez. Environ 1 600 millions? Donc 1,6 milliard de lignes, chaque nuit. Hum. C’est beaucoup, juste pour quelques compteurs en retard. Alors… dans PostgreSQL, je ferais un upsert, une insertion ou une mise à jour. On insère, et en cas de conflit, on met à jour. La clé, c’est le compteur et l’heure du relevé. Alors seulement les nouveaux relevés sont traités. Et si ça s’exécute deux fois, la deuxième fois, rien ne change, parce que les clés sont déjà là.

Esther(intervieweur) :

Sur les tables Delta, c’est un MERGE, une fusion, même idée. Et cette clé règle aussi notre double facturation. La nouvelle exécution avait ajouté les mêmes lignes encore une fois. Avec un MERGE sur le compteur et l’horodatage, une deuxième exécution met seulement à jour les mêmes lignes.

Ce que l’intervieweur vérifie

Esther vérifie si Nicole peut passer de son petit outil au volume de Tidewell. Nicole fait la multiplication à voix haute, voit le coût et passe à une écriture par clé. L’identifiant du compteur et l’horodatage du relevé forment exactement la clé qui empêche la double facturation. Elle y arrive à partir de PostgreSQL, un outil qu’elle connaît.

Nicole(personne candidate) :

Est-ce que je peux demander si l’horodatage est en UTC? J’espère que oui. À cause du changement d’heure.

Esther(intervieweur) :

Pourquoi est-ce important?

Nicole(personne candidate) :

En UTC, chaque journée a 96 relevés, parfait. Mais la journée du client est en heure locale. En mars, quand on avance l’heure, la journée locale a 23 heures, donc 92 relevés. En novembre, 25 heures, donc 100. Si une vérification dit « chaque compteur doit avoir 96 relevés par jour », ces deux jours-là, tous les compteurs sont en erreur. Chez Nordet, chaque année, le même courriel : « pourquoi tous les compteurs sont en erreur? »

Esther(intervieweur) :

Rit brièvement. Oui, UTC. Et nous avons exactement un traitement qui suppose 96 relevés. En mars dernier, il a signalé tous nos compteurs. D’accord. Maintenant, la partie coûteuse. Le MERGE se fait dans une table avec cinq ans d’historique. Comment l’empêchez-vous de lire toute la table chaque nuit?

Nicole(personne candidate) :

Est-ce que je peux prendre une minute?

Esther(intervieweur) :

Prenez votre temps.

Nicole(personne candidate) :

Environ 40 secondes de silence. Nicole écrit sur sa feuille.

D’accord. Honnêtement, c’est là que je m’arrête. Je n’ai jamais utilisé Spark sur de vraies données. J’ai fait le tutoriel dans la version gratuite de Databricks, peut-être un million de lignes. C’était rapide, et je n’ai rien appris sur ce problème. Dans PostgreSQL, j’aurais un index sur la clé. Ici, je ne sais pas comment Spark trouve les lignes sans tout lire. Combien de machines, ce qui est lent… je ne sais pas. Je préfère le dire.

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

Nicole a été honnête, et c’est bien. Elle pourrait aussi pousser son raisonnement un peu plus loin avec ce qu’elle sait déjà. Elle n’a pas besoin de Spark pour cela :

« Je ne connais pas Spark, mais laissez-moi réfléchir. Les relevés en retard concernent seulement les derniers jours. Alors le nouveau lot contient peut-être trois ou quatre dates de relevé, parfois une semaine. Si la table est divisée par date de relevé, est-ce que le MERGE peut regarder seulement ces dates? Alors le coût dépend des jours dans le lot, pas de cinq ans d’historique. Est-ce possible dans Delta? »

C’est possible. Si la condition du MERGE limite aussi les dates de relevé, Delta ignore les partitions des autres dates. Cela s’appelle l’élagage des partitions. (Pour les nouvelles tables, Databricks recommande maintenant le liquid clustering, un regroupement flexible des données, plutôt que des partitions par date. Un filtre de date dans le MERGE aide aussi dans ce cas.) Nicole n’a pas besoin du nom; son raisonnement l’amène près de la solution.

Esther(intervieweur) :

C’est bien, merci d’être claire. Version courte, parce que c’est utile : si le MERGE précise aussi les dates de relevé à consulter, Delta ignore les autres dates. L’élagage des partitions.

Nicole(personne candidate) :

D’accord. Bon à savoir.

Esther(intervieweur) :

Deuxième problème : les remplacements de compteurs. Le nouveau compteur a un nouvel identifiant. Le lien entre le compte et le compteur est dans une table CRM qui conserve seulement l’état actuel. Alors l’équipe de prévision voit des trous et des sauts. Pour l’historique, nous utiliserions la date du bon de travail sur le terrain.

Nicole(personne candidate) :

Hum. Attention à cette date. C’est quelle date? D’habitude, c’est la date de fermeture du bon de travail. Pas le jour où le compteur a été changé. L’équipe change le compteur le mardi, et ferme tous les bons le vendredi. Parfois une semaine plus tard.

Esther(intervieweur) :

Hum-hum. Alors où est la vraie date?

Nicole(personne candidate) :

Dans les compteurs. L’ancien arrête d’envoyer, le nouveau commence. Souvent, le système central envoie aussi un événement de remplacement. Et le lien CRM change seulement quand le bon est fermé. Alors pendant quelques jours, l’ancien compteur est parti et le nouveau n’est pas encore lié. C’est votre trou. Si la date du compteur est loin de celle du bon de travail, vous faites confiance au compteur et vous prévenez l’équipe sur le terrain.

Bien exprimer un désaccord

Esther a dit que l’équipe utiliserait la date du bon de travail sur le terrain. Nicole la remet en question à partir de son expérience sur le terrain. Cette date correspond à la fermeture du bon, parfois plusieurs jours après le remplacement réel. Elle ne dit pas « vous avez tort ». Elle demande de quelle date il s’agit, explique et donne une meilleure source. Esther change sa conception. Voir Les personnes qui font passer les entrevues n’ont pas toujours raison.

Esther(intervieweur) :

Ah. Je pensais que la date du bon de travail était la vraie. D’accord. Et les sauts?

Nicole(personne candidate) :

Le registre. L’ancien compteur était à, disons, 48 000 kWh. Le nouveau commence près de zéro. Si quelqu’un calcule la consommation par différence entre les registres avant et après le remplacement, il obtient un énorme nombre négatif. Alors : le dernier relevé de l’ancien compteur, le premier relevé du nouveau. Deux compteurs, et vous les reliez au compte, avec des dates.

Esther(intervieweur) :

Donc un historique avec des dates de début et de fin, une table SCD de type 2. D’accord. Dernier utilisateur : depuis l’été, un assistant d’IA du service à la clientèle lit la consommation d’un client pour expliquer une facture élevée. Qu’est-ce qui pourrait mal tourner pour l’assistant?

Nicole(personne candidate) :

Hum, laissez-moi réfléchir. Des données anciennes, des données fausses, bien sûr. Pause. Ah. Le même problème d’historique. Quand un locataire part et qu’un nouveau arrive, le compteur reste. Même compteur, deux comptes. Si l’assistant lit la consommation par compteur, le nouveau locataire peut voir la consommation de l’ancien. Quand il était chez lui, quand il était absent. Alors il doit lire par compte, avec les dates où ce compte avait ce compteur.

Esther(intervieweur) :

Pause. Nous n’avons pas testé les départs de locataires. Je le note.

Une table, trois problèmes

Nicole relie trois problèmes qui semblaient distincts : les trous dans les prévisions, les sauts lors d’un remplacement et un risque pour la confidentialité dans l’assistant d’IA. Une table, l’historique des liens entre comptes et compteurs avec les vraies dates, règle les trois. Cela vient de sept ans à planifier des remplacements de compteurs.

Dans les dernières minutes, Esther demande comment Nicole vérifierait que les données sont correctes avant la facturation. Nicole énumère des vérifications tirées de son travail en VEE. Les relevés par compteur et par journée locale (92, 96 ou 100), les longues séries de zéros par type de client, les valeurs négatives. Ensuite, elle ajoute une vérification à laquelle Esther n’avait pas pensé. Comparer la somme des intervalles d’une journée avec la différence entre deux relevés du registre. « Si ça ne correspond pas, l’un des deux est faux, et la facturation doit le savoir avant 5 h. » Elle demande aussi ce que le client voit quand une facture estimée est corrigée plus tard. « La facture suivante est différente, et il faut qu’il voie pourquoi, sinon il appelle. »

Minutes 50 à 60 : les questions de Nicole et la conclusion

Nicole(personne candidate) :

J’en ai trois. Première : qui est responsable de la table des liens entre comptes et compteurs? Si l’équipe CRM la change, est-ce qu’elle vous prévient?

Esther(intervieweur) :

Réponse honnête : non. Nous n’avons pas d’entente avec elle. Elle a renommé une colonne au printemps dernier, et nous l’avons découvert parce qu’un modèle ne fonctionnait plus.

Nicole(personne candidate) :

Comme mon CSV. Deuxième : Aisha m’a parlé de la garde. À quoi ressemble une mauvaise semaine, après une tempête?

Esther(intervieweur) :

Elle est longue. Après la tempête de vent, les relevés sont arrivés en retard pendant une semaine. La personne de garde vérifiait les journées en retard chaque matin avant la facturation. La plupart des semaines sont calmes. Celle-là ne l’était pas.

Nicole(personne candidate) :

D’accord, bon à savoir. Dernière : si je me joins à l’équipe et que je ne connais pas Spark, comment les gens l’apprennent ici? Il y a du temps au travail, ou seulement le soir?

Esther(intervieweur) :

Les nouvelles personnes travaillent en binôme avec une personne expérimentée pendant les premiers mois. Mais honnêtement, l’équipe est occupée, et apprendre Spark à notre échelle prend du temps. Graham pourra vous en dire plus. Et nous arrivons presque à la fin. Merci, Nicole. Vraiment. Grâce à vous, j’ai une liste de choses à vérifier demain. La prochaine étape est la modélisation des données avec Pierre, et Aisha vous écrira.

Nicole(personne candidate) :

Merci. Et je vais mettre la suppression et le chargement dans une seule transaction. Ce soir, peut-être.

Des questions qui révèlent ce que l'offre ne dit pas

La première question de Nicole révèle un fait absent de l’offre d’emploi : il n’y a aucun contrat de données avec l’équipe CRM. Sa deuxième question porte sur la réalité de la garde, pas seulement sur sa fréquence. Sa troisième demande comment elle apprendrait, ce qui est sa vraie question. C’est l’entrevue comme conversation dans les deux sens.

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

Esther rédige ses notes ce soir-là, en se basant sur l’offre d’emploi.

Nicole Tremblay, examen approfondi de la conception de pipelines

• Domaine des compteurs et de la facturation : preuves solides. A trouvé le bogue du changement d’heure sans aide, comme le problème de date de remplacement dans l’ordre de travail. A repéré le risque pour la confidentialité au départ d’un client à partir d’une seule question. A proposé la vérification des relevés par intervalle par rapport aux relevés du registre.
• Qualité des données : preuves solides. Trois types de zéro, vérifications des colonnes après un incident, « mieux vaut aucune liste qu’une liste erronée ».
• Conception de pipelines : quelques preuves. Heure de l’événement, fenêtre pour les données en retard, insertion ou mise à jour selon le compteur et l’horodatage. Y est arrivée à partir de son propre outil, avec un peu d’aide.
• SQL et Python : quelques preuves. Un vrai outil utilisé chaque jour depuis environ deux ans. L’entrevue de programmation nous en dira plus.
• Spark, Kafka, passage à grande échelle : aucune preuve. Niveau tutoriel. L’a dit clairement. Ne savait pas comment éviter un MERGE sur toute la table.
• Ingénierie en production : préoccupation. Aucune révision de code, peu de tests, suppression et chargement hors d’une même transaction, jamais de garde.

Recommandation : non pour ce poste, pour l’instant. Nous avons besoin de quelqu’un qui pourra bientôt prendre en charge les tâches Spark nocturnes. Elle n’en est pas encore capable. Mais nous ne devrions pas la perdre. Ses vérifications auraient détecté la double facturation et l’alerte liée au changement d’heure. Je parlerai à Graham de la qualité des données de facturation.

La suite

L’entrevue de modélisation des données avec Pierre a mené au même constat, autrement. Nicole a très bien modélisé l’historique des liens entre comptes et compteurs. Elle a eu du mal à estimer la taille des tables et les coûts. Graham était d’accord avec Esther : le seul poste d’ingénieur de données exigeait quelqu’un prêt à gérer les tâches Spark dès maintenant. Une autre personne l’a obtenu.

Mais Rosa Delgado, la directrice des opérations de facturation, avait rencontré Nicole pendant l’entrevue sur les valeurs. Elle avait aussi lu elle-même la plainte de double facturation de Kamloops. Graham et Rosa ont créé un nouveau poste dans l’équipe de Rosa : analyste de données, qualité des données de facturation. Le poste consiste à prendre en charge les vérifications des tables de facturation et de l’historique des liens entre comptes et compteurs. Il comprend aussi le rapprochement entre les relevés par intervalle et les relevés du registre. Nicole travaillerait chaque jour avec l’équipe de la plateforme de données, et en binôme avec Esther pendant les premiers mois.

Aisha a appelé Nicole et lui a expliqué franchement la situation. Ce n’était pas le poste d’ingénieur de données, mais un nouveau poste créé autour des compétences qu’elle avait démontrées. L’offre était de 95 000 $ CA. Nicole a demandé deux choses : un plan écrit pour passer à l’ingénierie de données dans 18 mois. Ce plan comprendrait une formation Spark et l’observation du travail de garde pendant la deuxième année. Elle voulait aussi un bilan avec Graham à 6 et à 12 mois. Elle a également demandé 100 000 $ CA. Tidewell a accepté le plan par écrit et un salaire de 98 000 $ CA. Elle a accepté.

C’est une issue réaliste, pas une promesse. Beaucoup d’entreprises diraient simplement non. Tidewell a créé un poste parce que les circonstances s’y prêtaient : un incident de facturation récent et une directrice avec un budget. La chance joue aussi un rôle.

Ce qu’il faut retenir

• La connaissance du domaine fait la différence quand elle devient une règle ou une conception. Nicole n’a pas dit « je connais les compteurs ». Elle a dit : cette date correspond à la fermeture de l’ordre par l’équipe, ce zéro est réel, cette journée compte 92 relevés.
• Posez vos questions sur le domaine tôt et corrigez la personne qui vous interviewe sur votre domaine au besoin. Appuyez-vous sur ce que vous avez vu, posez d’abord une question et proposez une meilleure source.
• Raisonnez à partir des outils que vous connaissez. Nicole est arrivée à une écriture fondée sur une clé grâce à l’insertion ou mise à jour de PostgreSQL. Face aux limites de ses connaissances de Spark, la même approche aurait pu l’aider à aller plus loin.
• Corrigez les chiffres de votre CV avant l’entrevue. Le « 40 % » avait aussi une autre cause. Nicole a répondu honnêtement, mais mieux vaut l’écrire correctement.
• Un « non » peut s’accompagner d’une autre offre. L’entrevue a montré ses forces si clairement que l’entreprise a créé un poste pour les mettre à profit.

Si votre profil ressemble à celui de Nicole

1. Transformez vos règles du domaine en vérifications des données. Pour chaque règle connue (« un zéro dans un chalet en janvier est réel »), écrivez la requête SQL qui trouve les lignes non conformes. Les règles de validation et Profiler avant de modifier montrent comment faire.
2. Rendez votre outil sûr à exécuter deux fois. Regroupez les suppressions et les chargements dans une transaction, ou utilisez une insertion ou mise à jour fondée sur une clé. Expliquez ensuite le fonctionnement à voix haute avec le mot « idempotent ». Consultez Une extraction reproductible.
3. Faites réviser et tester votre code. Ajoutez des tests pour le chargement, pas seulement pour les règles (Des tests ciblés). Si personne au travail ne peut réviser votre code, publiez une copie sans données privées. Demandez à un développeur d’une communauté de la réviser (Lire et réviser les différences).
4. Apprenez à travailler à une échelle supérieure à celle de votre outil. Chargez un jeu de données public de dizaines de millions de lignes dans Spark sur une plateforme gratuite. Écrivez la même insertion ou mise à jour sous forme de MERGE Delta. Examinez ensuite les données lues avec et sans condition sur la date. Vous pourrez alors dire clairement où s’arrêtent vos connaissances.
5. Transformez vos expériences du domaine en décisions de conception. Pour chaque expérience, décrivez le problème, pourquoi il coûte cher et ce que le pipeline devrait faire. Votre expérience est une longueur d’avance et La connaissance du domaine en pratique vous aident à les mettre par écrit. Expliquer vos décisions vous aide à les exprimer à voix haute.