La développeuse en intelligence d'affaires

Pensez à la personne qui crée les rapports que l’équipe des finances ouvre chaque lundi. Quand un chiffre semble étrange, on appelle cette personne en premier. Au fil des ans, elle apprend d’où vient chaque chiffre, quelles tables sont trompeuses et quels termes d’affaires ont trois sens différents. C’est une développeuse en intelligence d’affaires (BI).

Beaucoup d’ingénieurs de données commencent ainsi. Une développeuse en intelligence d’affaires écrit déjà du SQL toute la journée, conçoit des tables d’entrepôt et vérifie les chiffres à la source. Ce qui est souvent nouveau, ce sont les données en continu, les très grands volumes et des outils comme Kafka et Spark. Elle postule donc avec une question : « Est-ce qu’on me verra seulement comme une personne qui fait des rapports? »

Fatima est cette candidate. L’anglais est sa troisième langue, après l’arabe et le français. Observez à quel point cela compte peu dans l’entrevue, et combien son expérience de l’historique des données compte. Observez aussi la fin de son histoire : elle décide elle aussi, pas seulement Tidewell.

FZ

La personne candidate

Fatima Zahra El Idrissi

Développeuse en intelligence d'affaires et ingénieure analytique, 9 ans d'expérience, en transition vers l'ingénierie de données

• 9 ans en intelligence d'affaires et en données
• SQL Server, dbt, Snowflake
• Au Canada depuis 5 ans
• Vancouver

• Ingénieure analytique, Cedarline Retail (Vancouver, de 2024 à aujourd’hui). Migration d’environ 140 rapports de SQL Server vers dbt et Snowflake. Responsable des modèles de ventes nocturnes pour environ 300 magasins.
• Reconstruction du chargement quotidien des ventes après un incident de double comptage : fusion incrémentale sur la clé de ligne de commande, fenêtre de 3 jours pour les envois tardifs des magasins, tests de rapprochement avec les totaux des points de vente.
• Développeuse en intelligence d’affaires, Assurances Belvédère (Montréal, de 2021 à 2024; bureau de Casablanca, de 2017 à 2021). Paquets SSIS et entrepôt SQL Server pour les polices et les réclamations. Power BI pour les équipes d’actuariat et de finances.
• Conception de la dimension des polices avec historique complet (SCD de type 2), utilisée par les actuaires pour 6 ans d’études tarifaires.
• Compétences : SQL (niveau expert), dbt, Snowflake, SQL Server, SSIS, Power BI, Python (pandas), Airflow (bases), Kafka (notions).
• Langues : arabe, français, anglais.

Ce qu’Esther voit avant l’appel

Esther Adeyemi lit le CV à côté de l’offre d’emploi. Les preuves de maîtrise de SQL et de la modélisation sont solides. Une ligne la fait sourire : un incident de double comptage, corrigé par une fusion. Tidewell a connu presque le même incident le mois dernier.

Les lacunes sont aussi claires : pas de Spark, et des volumes bien inférieurs à 115 millions de relevés par jour. Et « Kafka (notions) » peut vouloir dire beaucoup de choses. Esther note ce qu’elle veut découvrir :

• Jusqu’où va son récit du double comptage? Sait-elle pourquoi la correction fonctionne et ce qu’elle ne couvre toujours pas?
• Son expérience de l’historique (SCD de type 2) mène-t-elle à une conception pour le problème de remplacement des compteurs?
• Que veut dire avoir des « notions » de Kafka? Où ses connaissances s’arrêtent-elles, et que fait-elle à ce moment-là?

Termes utilisés dans cette page

• Idempotent : vous pouvez exécuter le traitement deux fois, ou dix fois, et obtenir le même résultat qu’après une seule exécution.
• MERGE (insertion ou mise à jour) : une instruction SQL qui met à jour une ligne si sa clé existe déjà, sinon l’insère.
• Clé naturelle : les colonnes qui identifient une chose réelle, par exemple l’identifiant du compteur et l’heure du relevé. Ce n’est pas un numéro que la base de données invente.
• Partition : une partie de table, souvent une journée de données, stockée séparément pour qu’une requête lise seulement les jours nécessaires. Kafka a aussi des partitions; elles sont différentes, et nous les expliquons dans l’entrevue.
• Position (offset) : dans Kafka, le numéro de position d’un message dans une partition.
• SCD de type 2 (dimension à évolution lente, type 2) : une table qui conserve chaque version d’un enregistrement, avec une date de début et de fin. Vous pouvez ainsi demander « qu’est-ce qui était vrai le 3 mars? »
• Modèle incrémental dbt : un modèle dbt qui traite seulement les lignes nouvelles ou modifiées à chaque exécution, plutôt que de reconstruire toute la table.
• Table Delta : un format de table sur le stockage infonuagique (utilisé par Databricks). Il ajoute aux fichiers les transactions, MERGE et l’accès aux versions antérieures.

L’entrevue

Minutes 0 à 5 : l'ouverture

Esther(intervieweur) :

Bonjour Fatima. Je suis Esther, ingénieure de données principale dans l’équipe plateforme. Alors, voici le plan. Vous me parlez d’abord d’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 dans cette entrevue, mais le papier est permis. Je vais beaucoup utiliser le tableau blanc. J’aime les boîtes.

Fatima(personne candidate) :

D’accord, bien. Une chose avant de commencer. L’anglais est ma troisième langue. Parfois, je pense en français et j’ai besoin d’une seconde pour trouver le mot. Je vous le dirai si ça arrive.

Esther(intervieweur) :

Aucun problème. Prenez le temps qu’il vous faut. J’écoute votre raisonnement, pas vos mots.

Le dire dès le début

Fatima ne s’excuse pas. Elle explique à Esther ce qui pourrait arriver et ce qu’elle fera. Maintenant, une pause pour trouver un mot ressemble à ce qu’elle est : une pause.

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

Esther(intervieweur) :

Alors, parlez-moi d’un pipeline que vous avez construit ou dont vous êtes responsable.

Fatima(personne candidate) :

D’accord. Chez Cedarline, le chargement quotidien des ventes. On a environ 300 magasins. Chaque magasin envoie un fichier des caisses chaque nuit, avec toutes les lignes de vente de la journée. Il arrive dans une zone de chargement dans Snowflake. Ensuite, dbt construit les tables de ventes, et les finances consultent le tableau de bord le lundi matin.

Le problème, c’était… on a eu un mauvais lundi. Les ventes du dimanche étaient en double. Six millions de dollars au lieu de trois. Le directeur des finances l’a vu avant nous. Ce n’était pas un bon matin.

Esther(intervieweur) :

Rit. Je connais ce sentiment. Quelle était la cause?

Fatima(personne candidate) :

Le modèle était incrémental, mais il faisait seulement des ajouts. Airflow passait la date d’affaires, et le modèle insérait toutes les lignes pour cette date. Le dimanche soir, une tâche suivante a échoué. Quelqu’un a réinitialisé toute l’exécution et l’a relancée. Alors le modèle a inséré le dimanche une deuxième fois.

Ce que l’intervieweur vérifie

Esther veut voir si Fatima comprend la cause, pas seulement le symptôme. « Une nouvelle exécution a ajouté les mêmes données » correspond exactement à l’incident de double facturation chez Tidewell. Fatima l’explique en quatre phrases courtes, avec le vrai mécanisme : un ajout, un filtre de date et une personne qui a tout relancé.

Esther(intervieweur) :

Et qu’avez-vous changé?

Fatima(personne candidate) :

J’ai remplacé l’ajout par une fusion (merge). La clé unique est l’identifiant de la ligne de commande venant de la caisse. Donc, si la même ligne revient, le modèle la met à jour, il ne l’insère pas. Et le filtre prend les trois derniers jours, pas seulement hier, parce que certains magasins envoient leurs fichiers en retard. Les petits magasins dans le nord, parfois le réseau ne fonctionne pas. Une fois, un magasin a envoyé toute une semaine d’un coup.

Esther(intervieweur) :

Donc, avec une fenêtre de trois jours, cette semaine…

Fatima(personne candidate) :

Oui, les jours plus anciens sont hors de la fenêtre. Le modèle ne les voit pas. On a un test pour ça. Chaque matin, il compare le total par magasin et par jour dans notre table avec celui des fichiers bruts. Si c’est différent, le test échoue et je reçois un message. Ensuite, je fais un chargement rétroactif pour ce magasin, à la main. Avec la fusion, le chargement rétroactif est sûr. Je peux le faire deux fois, rien ne change.

Esther(intervieweur) :

D’accord. Un détail sur la fusion. Et si la même ligne de commande apparaît deux fois dans les nouvelles données? Pas dans la table, dans le nouveau fichier.

Fatima(personne candidate) :

Ah oui, c’est arrivé! Si la ligne est déjà dans la table, la fusion échoue. Snowflake dit, comment on dit, « duplicate row detected »… une ligne en double détectée, quelque chose comme ça. Mais si c’est une nouvelle ligne, c’est pire. Il insère les deux, sans erreur. Alors, avant la fusion, je garde une seule ligne par clé. Je prends la plus récente, avec ROW_NUMBER, selon l’heure du fichier.

Esther a posé des questions sur la taille et le coût. Fatima pensait que la table des ventes contenait « environ deux millions de lignes par jour, plus en décembre ». Elle estimait le total à environ un milliard et demi de lignes, sans en être certaine. Son gestionnaire avait posé des questions sur le coût. La fusion parcourait d’abord toute la table, alors elle a ajouté la date à la condition de fusion. Snowflake lisait alors seulement les jours récents, et l’exécution est passée d’environ 25 minutes à 4 ou 5.

Pourquoi cela fonctionne

C’est un récit de pipeline solide, et pas parce qu’il est gros. Chaque élément a une raison :

• une fusion sur une clé naturelle, pour les nouvelles exécutions;
• une fenêtre de 3 jours, pour les fichiers en retard;
• un test de rapprochement, pour ce que la fenêtre manque;
• une déduplication avant la fusion et une date dans la condition de fusion, pour le coût.

Elle connaît aussi la limite de sa solution : les fichiers en retard hors de la fenêtre nécessitent encore une intervention humaine.

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 et les relevés 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, nous avons relancé le traitement et un client a été facturé deux fois. Et l’équipe de prévision dit qu’il manque des données dans son historique. Comment concevriez-vous le pipeline des relevés pour que ça ne se reproduise pas?

Fatima(personne candidate) :

Sourit. C’est mon lundi matin, mais avec de l’électricité.

Esther(intervieweur) :

Oui, un peu. Quel est le volume? On a 1,2 million de relevés par jour. Non, pardon, 1,2 million de compteurs. Les relevés, c’est environ 115 millions par jour.

Fatima(personne candidate) :

D’accord, 115 millions. Alors, d’abord, la date. Lire par date d’arrivée, c’est le problème. Le relevé a sa propre heure, celle du compteur. Je partitionnerais la table nettoyée par date du relevé, pas par date d’arrivée. Alors un relevé en retard va dans sa vraie journée. Et le traitement de nuit lit tout ce qui est arrivé depuis la dernière exécution. Ensuite, il regarde quelles dates de relevé sont présentes. Surtout hier, mais aussi quelques jours avant. Et il reconstruit seulement ces journées. Avec une fusion sur l’identifiant du compteur et l’heure du relevé, comme ma ligne de commande.

Esther(intervieweur) :

Une fusion, ou le remplacement de toute la journée?

Fatima(personne candidate) :

Hmm. Les deux peuvent fonctionner. Remplacer la journée, c’est simple, et c’est idempotent. Mais alors le traitement doit avoir tous les relevés de cette journée, dans la table brute, pas seulement les nouveaux. Si je remplace avec seulement les nouveaux, je perds les anciens. La fusion est plus sûre si l’entrée contient seulement les nouvelles lignes. Je pense que je choisirais la fusion, avec la date du relevé dans la condition, comme pour le coût.

Pourquoi cela fonctionne

Fatima voit le piège dans « remplacer la partition ». C’est sûr seulement si vous reconstruisez la journée avec toutes les données d’entrée. Les deux réponses sont correctes avec les bonnes données d’entrée. Esther veut qu’elle fasse un choix et explique pourquoi.

Esther(intervieweur) :

Bien. Maintenant, les données brutes. Avant le traitement de nuit, les relevés viennent de Kafka. Un traitement en continu lit Kafka et écrit dans la table Delta brute. Votre CV dit « familiar » pour Kafka, donc que vous le connaissez un peu. Qu’est-ce que ça veut dire?

Fatima(personne candidate) :

Rit. Ça veut dire que j’ai suivi un cours la fin de semaine et fait un petit test chez moi. Je ne l’ai jamais utilisé en production. Honnêtement, je connais l’idée : les producteurs écrivent des messages, les consommateurs les lisent. Mais les détails, non.

Esther(intervieweur) :

D’accord, merci d’être claire. Alors je vais poser la question comme ça. Imaginez que le traitement en continu plante au milieu. Quand il redémarre, comment sait-il où reprendre?

Fatima(personne candidate) :

Je ne sais pas comment Kafka fait ça. Pouvez-vous l’expliquer un peu? Ensuite, j’essaie de raisonner.

Esther(intervieweur) :

Bien sûr. Un sujet Kafka est divisé en partitions. Chaque partition est un journal, comme un fichier où on ajoute seulement à la fin. On utilise l’identifiant du compteur comme clé. Tous les relevés d’un compteur vont donc dans la même partition. Chaque message d’une partition a un numéro, le décalage. 0, 1, 2, et ainsi de suite. Le consommateur enregistre le dernier décalage qu’il a terminé. Après une panne, il reprend au décalage enregistré.

Fatima(personne candidate) :

D’accord. Donc, un signet dans un livre. Pause. Alors l’ordre est important. S’il écrit d’abord dans Delta, puis plante avant d’enregistrer le signet… après le redémarrage, il relit les mêmes messages. Donc on a des doublons.

Esther(intervieweur) :

Oui. Et dans l’autre ordre?

Fatima(personne candidate) :

Il enregistre le signet d’abord, puis plante avant l’écriture. Alors… les relevés sont perdus? Non, attendez. Ils sont encore dans Kafka. Mais le traitement pense les avoir terminés, alors il ne les relit jamais. Pour nous, ils sont perdus. Et personne ne le sait. Alors j’écrirais d’abord. Les doublons, je peux les trouver, et la fusion sur le compteur et l’heure les élimine de toute façon. Un relevé perdu, je ne peux pas le trouver, parce que je ne sais pas qu’il existe. Seulement plus tard, quand il manque des données pour le client.

La limite, et ce que Fatima fait à ce moment-là

Fatima atteint ici la limite de ses connaissances. Elle n’invente pas de réponse. Elle demande une explication, trouve une image du quotidien, un signet, et raisonne jusqu’à la bonne règle. Écrire d’abord, enregistrer la position ensuite. Cela donne une livraison au moins une fois. L’étape suivante doit donc éliminer les doublons. Esther en a appris plus ici qu’avec une définition correcte donnée rapidement.

Esther(intervieweur) :

Exactement. Dans notre traitement, Spark conserve les décalages dans son propre dossier de points de contrôle. L’écriture Delta et le point de contrôle fonctionnent ensemble, donc un redémarrage normal est sûr. Mais notre nouvelle exécution du mois dernier concernait le traitement de nuit par lots, pas celui en continu. Kafka ne peut pas aider là.

Fatima(personne candidate) :

D’accord. Une question. Les relevés en retard, d’un compteur sans réseau. Dans la partition Kafka, où sont-ils? À la bonne place selon l’heure?

Esther(intervieweur) :

Non. Ils sont à la fin, quand ils arrivent.

Fatima(personne candidate) :

Donc l’ordre dans Kafka, c’est l’ordre d’arrivée. Il faut toujours prendre l’heure à l’intérieur du relevé. Jamais celle de Kafka, jamais celle du fichier.

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

Fatima a bien raisonné. Pour aller plus loin, elle pourrait faire le lien avec la taille de la table et l’attente :

« Si les relevés peuvent arriver trois jours en retard, le traitement de nuit doit couvrir au moins trois jours de dates de relevé. C’est environ 115 millions fois 3, donc autour de 350 millions de lignes dans la fenêtre de fusion. C’est gros pour moi, beaucoup plus gros que ma table de ventes. Je demanderais combien de temps prend le traitement Spark aujourd’hui, avant de promettre quoi que ce soit. »

Cela montre le coût de sa propre conception et précise ce qu’elle ne connaît pas encore, de façon utile.

Esther(intervieweur) :

Maintenant, la facturation. Elle s’exécute à 5 h. Si les relevés arrivent trois jours en retard, que fait la facturation?

Fatima(personne candidate) :

La facturation doit finaliser la facture à un moment donné. Elle ne peut pas attendre pour toujours. Alors… pardon, j’ai perdu mon idée. Je recommence.

Esther(intervieweur) :

Bien sûr, aucun problème.

Fatima(personne candidate) :

La facturation a besoin d’une règle : attendre combien de jours? Trois, cinq? Après ça, elle utilise une estimation pour les relevés manquants et les marque comme estimés. Quand les vrais relevés arrivent plus tard, la prochaine facture corrige la différence. Mais c’est une règle d’affaires. Je demanderais à l’équipe de facturation, je ne déciderais pas moi-même. Elle connaît les exigences de l’organisme de réglementation.

Esther(intervieweur) :

Bien. C’est le domaine de Rosa; vous la rencontrerez plus tard. Une autre question. L’équipe de prévision voit des données manquantes et des sauts quand on remplace un compteur. Le nouveau compteur reçoit un nouvel identifiant. Le lien entre le compte et le compteur est dans une table CRM, et le CRM garde seulement l’état actuel.

Fatima(personne candidate) :

Donc, quand le compteur change, l’ancien lien est remplacé? Alors c’est un problème d’historique. C’est mon SCD de type 2 chez l’assureur. La police changeait, et les actuaires devaient savoir ce qui était vrai à chaque date. Ici, une ligne par lien : compte, compteur, début de validité, fin de validité. Quand on remplace un compteur, on ferme l’ancienne ligne et on en ouvre une nouvelle. Ensuite, on joint les relevés au compte quand leur heure se trouve entre le début et la fin de validité.

Esther(intervieweur) :

Comment construisez-vous cet historique si le CRM ne le garde pas?

Fatima(personne candidate) :

On prend un instantané chaque jour. Dans dbt, il y a des instantanés pour ça. Mais deux problèmes. D’abord, l’historique commence le jour où on commence. Avant ça, il faut le trouver ailleurs. Est-ce qu’il y a un système pour les travaux sur le terrain, les ordres de remplacement?

Esther(intervieweur) :

Oui, les ordres de travail sur le terrain. Ils ont une date et une heure. Mais l’heure n’est pas toujours celle du remplacement réel. Parfois, c’est le moment où l’équipe a fermé l’ordre.

Fatima(personne candidate) :

C’est quand même mieux que l’instantané. Un instantané quotidien connaît seulement la journée. Et… on a les relevés. L’ancien compteur arrête d’envoyer, le nouveau commence. Alors les relevés peuvent nous donner l’heure réelle, et on compare avec l’ordre de travail. S’ils ne concordent pas, quelqu’un vérifie.

Pourquoi c'est la meilleure partie de l'entrevue

Esther n’a jamais dit « dimension à évolution lente ». Fatima a entendu « seulement l’état actuel » et a immédiatement vu un problème d’historique, parce qu’elle en a déjà résolu un. Ensuite, elle a trouvé elle-même les deux points faibles d’un instantané quotidien. Aucun historique avant le premier jour, et une précision limitée à la journée. Elle a aussi utilisé les données comme deuxième source : les relevés montrent quand l’ancien compteur s’est arrêté.

Esther(intervieweur) :

Dernière chose, rapidement. Comment sauriez-vous que la table est correcte chaque matin? Avant la facturation.

Fatima(personne candidate) :

Comme mon test des ventes. Par compteur et par jour, on attend 96 relevés. Moins veut dire des données manquantes, plus veut dire des doublons. Aussi, aucune valeur négative, et l’heure du relevé ne doit pas être dans le futur.

Esther(intervieweur) :

Toujours 96?

Fatima(personne candidate) :

Oh. Non. Le changement d’heure. En mars, la journée a 23 heures, donc 92. En novembre, 25 heures, 100. Alors le test doit compter selon la journée locale et connaître les deux journées spéciales. En UTC, chaque journée a 96 relevés, mais la facturation utilise la journée locale.

Esther a ensuite posé quelques questions sur l’assistant d’IA du service à la clientèle. Fatima a d’abord pensé au client au téléphone. L’assistant devrait afficher « estimated » (estimé) à côté des relevés estimés et utiliser les mêmes définitions d’affaires que la facture. « Sinon, le client entend deux chiffres différents. » Esther a demandé si la facturation avait besoin d’un traitement en continu. Fatima a répondu non : la facturation s’exécute une fois par jour, et l’exactitude compte plus que la rapidité. Elle était moins certaine pour l’assistant : « Peut-être que des données d’il y a une heure suffisent? Je demanderais à l’équipe du service à la clientèle. »

Minutes 50 à 57 : les questions de Fatima

Fatima(personne candidate) :

J’ai trois questions. D’abord, la garde. Aisha a dit une semaine sur sept. À quoi ressemble une mauvaise semaine?

Esther(intervieweur) :

La facturation s’exécute à 5 h. Alors, si le traitement de nuit échoue, le téléphone sonne à 4 h. J’étais de garde pour la double facturation. J’ai travaillé jusqu’à midi, puis on a appelé le client. Honnêtement, la plupart des semaines sont tranquilles. Certaines ne le sont pas.

Fatima(personne candidate) :

Merci, c’est important pour moi. Deuxième question : l’équipe CRM. Avez-vous une entente avec elle sur le format? Ou peut-elle changer la table quand elle veut?

Esther(intervieweur) :

Pause. Pas d’entente. Elle la change, et on le découvre quand quelque chose ne fonctionne plus. C’est sur notre liste.

Fatima(personne candidate) :

D’accord. Et la dernière, plus pratique. Quel est le délai pour la décision? Je suis aussi dans un autre processus, et ils sont à la fin.

Esther(intervieweur) :

Merci de me le dire. Je ne sais pas exactement. Il vous reste l’entrevue de modélisation avec Pierre et la conversation avec Rosa. Parlez de l’autre processus à Aisha aujourd’hui, s’il vous plaît. Elle peut essayer d’accélérer les choses.

Des questions qui aident à décider

Chaque question donne à Fatima un fait nécessaire pour décider : la réalité de la garde, l’absence d’entente sur les données et le calendrier. La dernière question n’est pas impolie. Dire à l’entreprise que vous avez un autre processus est normal et utile pour les deux côtés. Une entrevue est une conversation dans les deux sens.

Ce qui pourrait mal se passer

Fatima a demandé le calendrier seulement à la fin de la troisième entrevue. Si elle avait posé la question à Aisha pendant l’appel de recrutement, Tidewell aurait pu planifier les entrevues plus rapidement. Demandez le calendrier tôt, et dites tôt si une autre entreprise est plus avancée.

Minutes 57 à 60 : la conclusion

Esther(intervieweur) :

Merci, Fatima. J’ai vraiment aimé cette conversation. Le signet, je vais utiliser cette image avec les nouvelles personnes.

Fatima(personne candidate) :

Rit. Vous pouvez. Merci d’avoir expliqué Kafka. Je vais lire davantage ce soir.

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

Esther rédige ses notes le même après-midi, à côté de l’offre d’emploi.

Fatima Zahra El Idrissi, examen approfondi de la conception de pipelines

• SQL et modélisation des données : preuves solides. A reconnu le problème de remplacement de compteur comme un SCD de type 2 avant que je le nomme. A trouvé elle-même les deux points faibles d’un instantané quotidien et proposé les bons de travail, vérifiés avec les relevés.
• Pipelines idempotents et réexécutions : preuves solides. A dirigé une vraie correction de double comptage : fusion sur une clé naturelle, déduplication avant la fusion, date dans la condition de fusion, tests de rapprochement. Sait ce que la correction ne couvre pas.
• Données tardives : preuves solides. Partitionner par date de relevé, reconstruire les jours touchés, prévoir une fenêtre et un test pour ce qu’elle manque.
• Qualité des données : preuves solides. 96 par compteur par jour, et s’est corrigée sur le changement d’heure.
• Kafka et traitement en continu : aucune preuve d’expérience. L’a dit clairement. Avec une explication, a raisonné correctement jusqu’à « écrire d’abord, enregistrer la position ensuite ».
• Spark à notre volume : aucune preuve. Sa plus grosse table compte environ 2 millions de lignes par jour. Elle aura besoin de temps et de soutien ici.
• Compréhension des besoins d’affaires : preuves solides. Veut que la facturation et le service à la clientèle définissent la règle d’attente et la fraîcheur des données. A posé les bonnes questions sur les gardes et le CRM.

Recommandation : oui sans hésitation. Ses lacunes sont Spark et Kafka. Ils sont plus faciles à enseigner que son jugement en modélisation. La jumeler avec quelqu’un sur le traitement en continu pendant les deux premiers mois. Note : elle est à l’étape finale d’un autre processus. Merci d’agir vite.

Ce qui s’est passé ensuite

Fatima a parlé de l’autre processus à Aisha le soir même. Pierre a mené l’entrevue de modélisation deux jours plus tard et écrit « la meilleure discussion sur la granularité cette année ». La conversation avec Rosa a été fixée à la semaine suivante, à sa première disponibilité.

Mais Tidewell n’attendait pas seulement Rosa. Graham avait un poste à pourvoir et plusieurs finalistes solides, dont une personne avait encore deux entrevues à passer. Il voulait comparer tout le monde avant de décider.

Quatre jours avant l’entrevue avec Rosa, l’autre entreprise a fait une offre à Fatima. C’était un poste d’ingénieure de données dans une entreprise de logistique à Burnaby, à 152 000 $ CA. Elle devait répondre dans les trois jours. Aisha a demandé à Graham si Tidewell pouvait décider plus tôt. Graham a dit qu’il ne pouvait pas prendre une décision équitable en trois jours. Fatima a accepté l’autre offre. Elle a écrit à Aisha et à Esther :

« Chère Aisha, chère Esther, merci pour les entrevues. J’ai beaucoup appris, surtout sur Kafka. J’ai accepté une autre offre aujourd’hui, parce qu’ils pouvaient décider plus tôt et que le poste me convient très bien. Ce n’était pas un choix facile. J’ai vraiment aimé l’équipe et le problème des compteurs. J’espère qu’on se reverra. Fatima »

Esther a répondu en une ligne : « Bonne chance, et restons en contact. Le signet est maintenant dans nos notes d’accueil. » Deux semaines plus tard, Tidewell a fait sa seule offre à une autre personne finaliste.

Fatima n’a rien fait de mal. Elle a choisi une bonne offre au moment où elle est arrivée. Tidewell a perdu une candidate solide parce que son processus était plus lent. Les deux parties décident, et les deux peuvent dire non. Voir une entrevue est une conversation dans les deux sens.

Ce qu’il faut en retenir

• Votre ancien domaine offre souvent la réponse. Fatima a résolu le problème de remplacement de compteur avec une approche utilisée en assurance. Cherchez les problèmes de la nouvelle entreprise que vous avez déjà résolus ailleurs.
• Un petit pipeline bien justifié vaut mieux qu’un gros sans justification. Sa table était 50 fois plus petite que celle de Tidewell. Cela n’avait pas d’importance, car elle pouvait expliquer la raison de chaque décision.
• À la limite de vos connaissances, posez des questions, puis raisonnez. « Pouvez-vous expliquer un peu? Ensuite, j’essaie de raisonner » est une phrase forte. Elle transforme une lacune en conversation.
• Dites quelles décisions ne vous reviennent pas. Le délai d’attente pour la facturation est une règle d’affaires. Dire « je demanderais à l’équipe de facturation » montre du jugement, pas une faiblesse.
• Gérez votre propre échéancier. Informez l’entreprise tôt si vous êtes dans un autre processus et demandez combien de temps le sien prend. Vous pourrez alors prendre une bonne décision quand une offre arrivera.
• Votre anglais peut être simple. Esther a noté les idées de Fatima, pas sa grammaire.

Si votre profil ressemble à celui de Fatima

1. Rédigez le récit d’un pipeline en expliquant chaque choix. Pour votre plus gros chargement, répondez : que se passe-t-il s’il s’exécute deux fois? Si deux exécutions se chevauchent? Si des données arrivent tard? Si la même clé apparaît deux fois dans un lot? Comment savez-vous chaque matin que tout est correct? Voir Expliquer vos décisions.
2. Apprenez Kafka à partir des questions posées en entrevue. Vous n’avez pas besoin d’expérience en production pour comprendre les partitions, les clés, les groupes de consommateurs et les positions. Exécutez une petite instance locale de Kafka dans Docker, arrêtez votre consommateur en plein traitement et observez vous-même les doublons.
3. Essayez Spark à plus grande échelle. Chargez un jeu de données public de quelques centaines de millions de lignes et partitionnez-le par date. Exécutez ensuite une opération MERGE sur les trois derniers jours. Notez le temps nécessaire.
4. Transformez votre travail sur l’historique en une approche générale. Exercez-vous au SCD de type 2 dans un nouveau domaine : compteurs, employés, prix. Écrivez la jointure avec une date de début et une date de fin de validité, puis testez les limites de l’intervalle. Notre leçon Le temps et le classement présente les fonctions de fenêtre que vous utiliserez.
5. Exercez-vous à expliquer les règles de qualité des données à voix haute. Pour toute table, énoncez le nombre attendu, les valeurs impossibles et les exceptions, comme les jours de changement d’heure. Voir Les règles de validation.
6. Posez des questions sur l’échéancier dès le premier appel. Notre leçon Se préparer aux candidatures vous aide à suivre plusieurs processus à la fois.