Lire l'offre avec lucidité

À la page précédente, vous avez trouvé le problème derrière l’offre : environ 115 millions de relevés de compteurs par jour. Trois groupes de personnes ont besoin de chiffres fiables. Maintenant, nous lisons l’offre ligne par ligne, comme le ferait un ingénieur de données expérimenté. Nous classons chaque ligne dans l’un de ces trois groupes :

• Vraiment exigé : l’équipe ne peut pas embaucher quelqu’un sans cette compétence, et les entrevues la vérifieront.
• Un souhait : l’équipe aimerait cette compétence, mais le travail n’en dépend pas. Les longues listes rassurent les personnes qui rédigent les offres. Les souhaits s’y accumulent donc.
• Manquant : l’offre ne le dit pas, mais le travail l’exige clairement. Ces éléments sont souvent les plus importants. Les entrevues les abordent, et beaucoup de candidats ne s’y préparent pas.

Notre lecture est une hypothèse réfléchie, pas un fait. Nous listons donc aussi les questions qui permettent de vérifier chaque hypothèse.

Le niveau et le salaire

« 5 ans ou plus » apparaît trois fois dans « Ce que vous apportez ». Les vraies offres font souvent cela. Généralement, quelqu’un a copié des lignes d’anciennes offres, plutôt que de compter les années avec soin.

La ligne la plus étrange est « 5 ans ou plus d’expérience dans la création de pipelines de traitement en continu à grande échelle ». La plupart des travaux sur les données se font par lots. Une tâche s’exécute selon un horaire, par exemple chaque nuit, et traite ce qui est arrivé depuis la dernière exécution. Le traitement en continu traite les données sans interruption, quelques secondes après leur arrivée. Très peu d’ingénieurs de données ont cinq ans d’expérience en traitement en continu. Cette ligne est donc un souhait.

Regardez maintenant le salaire et les responsabilités : de 120 000 à 150 000 $ CA à Vancouver, « créer et maintenir », « contribuer aux bonnes pratiques ». Cela correspond à un ingénieur de données de niveau intermédiaire. Cette personne prend en charge les pipelines et les répare sans aide étape par étape. Les mots comme « encadrer » ou « définir l’orientation technique », courants dans les offres de niveau supérieur, sont absents. Les années indiquent donc un niveau supérieur, et le salaire, un niveau intermédiaire. Demandez au recruteur : « Quel est le niveau de ce poste? Y a-t-il une marge pour une candidature plus expérimentée? » La réponse change le titre et le salaire que vous pouvez demander.

La fourchette figure dans l’offre à cause d’une loi. En Colombie-Britannique, depuis le 1er novembre 2023, la Pay Transparency Act exige cette information dans toute offre d’emploi publique. L’offre doit indiquer le salaire prévu ou une fourchette salariale. La même loi interdit à un employeur de demander votre salaire dans vos emplois précédents. Si quelqu’un demande « Combien gagnez-vous actuellement? », vous pouvez répondre avec la fourchette que vous attendez pour ce poste. Les autres provinces et pays ont des règles différentes.

Ce qui est vraiment exigé

Derrière les longues listes, le poste exige cinq choses. Les entrevues y consacreront la majeure partie du temps.

1. SQL et une réflexion sur la structure des données. SQL figurait dans les 10 vraies offres que nous avons étudiées. L’offre ajoute « concepts de modélisation des données et d’entreposage des données » dans une courte ligne. Cette ligne couvre pourtant plus qu’il n’y paraît. La modélisation des données consiste à décider comment structurer les tables. Que représente une ligne, c’est-à-dire quel est le niveau de détail? Quelles tables contiennent des faits, comme les relevés, et lesquelles contiennent des descriptions, comme les comptes et les compteurs? Un bon modèle facilite l’obtention de la bonne réponse. Un mauvais modèle facilite l’obtention d’une mauvaise réponse.

2. Python et Spark pour de grands volumes de données. Un seul portable ne peut pas traiter 115 millions de lignes par jour. C’est toutefois un volume normal pour Spark, un outil qui répartit le travail entre plusieurs ordinateurs. Vous devez savoir ce qui rend une tâche Spark lente ou coûteuse, et comment trouver la cause. Par exemple, elle peut lire tout l’historique alors que vous avez seulement besoin de trois jours.

3. Des pipelines que vous pouvez relancer sans risque. L’offre ne le dit pas, mais c’est la partie la plus importante du travail. Un pipeline est une chaîne d’étapes qui déplace les données de leur source vers les personnes qui les utilisent. Les pipelines échouent, puis quelqu’un relance la tâche. La deuxième exécution donne-t-elle le même résultat qu’une seule exécution réussie, ou ajoute-t-elle les mêmes données deux fois? Une tâche que vous pouvez relancer avec le même résultat est dite idempotente. Quand une facture dépend du résultat, cette propriété n’est pas un simple avantage.

4. Des données tardives et désordonnées. Les compteurs perdent leur connexion réseau. Quand la connexion revient, ils envoient les anciens relevés. Un relevé du lundi peut donc arriver le mercredi. Un compteur peut aussi être remplacé, l’heure change deux fois par année, et un système source peut changer son format de fichier. L’offre dit « assurer la qualité des données dans toute la plateforme », une ligne vague. Attendez-vous à des questions sur vos vérifications, leur emplacement et ce qui arrive lorsqu’une vérification échoue.

5. Collaborer avec les personnes qui utilisent les données. « Collaborer avec les équipes de facturation, de science des données et de service à la clientèle » semble une formule habituelle. Chez Tidewell, c’est un vrai travail. L’équipe de facturation décide ce qu’est une facture correcte. L’équipe de prévision sait quelles lacunes nuisent à son modèle. Vous devez leur expliquer un problème de données sans jargon et les écouter quand elles vous expliquent une règle de facturation.

Ce qui est probablement un souhait

La plupart des outils de la liste. Dix outils sur une seule ligne, dont plusieurs font le même travail. Notre hypothèse pour Tidewell : Kafka, Databricks avec Spark, Airflow et dbt sont les outils du quotidien. Snowflake, BigQuery, Flink, Dagster et Fivetran ne le sont probablement pas. N’apprenez pas dix outils avant l’entrevue. Apprenez les idées derrière eux : traitement par lots et en continu, planification, transformation, stockage. Demandez ensuite au recruteur quels outils l’équipe utilise vraiment.

Le traitement en continu comme travail principal. L’offre dit « temps réel » deux fois et nomme trois outils de traitement en continu. Mais pensez aux utilisateurs. Une facture est calculée une fois par mois, et un modèle de prévision apprend à partir de plusieurs mois d’historique. Ni l’un ni l’autre n’a besoin des données en quelques secondes. L’assistant d’IA a besoin de données récentes. Mais pour une question de facturation, « récentes » veut probablement dire « d’aujourd’hui ». Notre hypothèse : les relevés arrivent par Kafka, une tâche en continu les écrit dans le stockage. Ensuite, la plupart des tâches se font par lots. Si quelqu’un demande « La facturation a-t-elle besoin de traitement en continu? », répondre « non, et voici pourquoi » montre un bon jugement.

Les bases de données vectorielles. « Expérience des bases de données vectorielles et des pipelines de plongements » figure dans « Un atout ». Une base de données vectorielle stocke des listes de nombres qui représentent le sens d’un texte. Un système d’IA peut ainsi trouver des documents de sens semblable. Aucune des 10 vraies offres que nous avons étudiées ne demandait cette compétence. L’assistant de Tidewell a besoin de la consommation d’un client : des nombres dans des tables, trouvés par numéro de compte. Il ne cherche pas du texte selon son sens. Cette ligne vient donc probablement d’un article sur les tendances en IA, pas du travail de l’équipe. Consacrez votre temps de préparation à autre chose.

Le diplôme. « Un diplôme en informatique, en génie ou dans un domaine connexe » figure dans la liste des exigences. Pourtant, aucune responsabilité n’en dépend. Beaucoup de bons ingénieurs de données viennent de l’informatique décisionnelle, des opérations ou d’autres domaines.

La « maîtrise de l’IA ». Sept des 10 vraies offres demandaient une forme de compétence en IA. Cette ligne est donc normale en 2026. Cela ne signifie pas que les entrevues autorisent les outils d’IA. L’équipe veut une personne qui utilise l’IA et vérifie quand même chaque ligne. Une jointure incorrecte dans une table de facturation coûte cher. Préparez-vous à expliquer comment vous vérifiez le code écrit par un assistant.

Ce qui manque et compte

Des « données prêtes pour l’IA » sans définition. L’offre dit « prêtes pour l’IA » deux fois, sans jamais expliquer ce que cela signifie. Dans une vraie offre, cela désignait un ensemble commun de définitions des mesures. Les outils d’IA et les personnes calculent ainsi les mêmes chiffres. Pour l’assistant de Tidewell, nous pensons que cela signifie :

• Correctes : aucun relevé en double, et aucune journée manquante sans indication claire.
• Récentes : la consommation d’aujourd’hui, pas celle de la semaine dernière.
• Bien décrites : l’assistant et les personnes qui le créent savent ce que signifie chaque colonne.
• Protégées : l’assistant peut lire seulement les données du client avec qui il parle.

Le dernier point est le plus sérieux. La consommation d’électricité est un renseignement personnel. Elle indique quand une famille est à la maison, quand elle dort et quand elle part en vacances. Attendez-vous à une question sur les personnes qui peuvent voir chaque donnée.

La garde. L’offre ne la mentionne pas, même si cinq des 10 vraies offres le faisaient. Un pipeline de facturation qui échoue la nuit doit être réparé avant l’envoi des factures. Demandez au recruteur : « Y a-t-il une rotation de garde? À quelle fréquence, et à quelle heure les tâches les plus importantes s’exécutent-elles? » La réponse touche votre vie plus que la plupart des lignes de l’offre.

Les coûts. Pas un mot à ce sujet. Mais avec 115 millions de nouvelles lignes par jour, lire tout l’historique chaque nuit devient très coûteux. Il faudrait plutôt lire seulement les jours récents. Quelqu’un paie cette facture. Demandez : « Qui est responsable du coût de la plateforme? A-t-il changé cette année? » Si la réponse est « personne », ou s’il y a une longue pause, vous avez appris quelque chose d’utile.

Qui peut changer les sources. Les données des compteurs passent par le système du fournisseur de compteurs. Les données des comptes viennent d’un système de gestion de la relation client (CRM). Si leurs responsables changent un format sans prévenir, l’équipe de données l’apprend lorsqu’un pipeline tombe en panne. Demandez : « Quand un système source change son format, comment l’équipe l’apprend-elle? »

Le déroulement des entrevues. Aucune des 10 vraies offres ne décrivait le processus, et celle-ci ne le fait pas non plus. Demandez au recruteur dès le premier appel.

Les mots qui décrivent la culture

Certains mots d’une offre décrivent la culture : « passionné », « grand sens des responsabilités ». Ils peuvent signifier de la confiance et un travail que les gens utilisent vraiment. Ils peuvent aussi signifier qu’une petite équipe est responsable de trop de choses, chaque nuit de la semaine. Posez donc une question neutre : « Que s’est-il passé la dernière fois qu’un pipeline a échoué avant le lancement de la facturation? » Une équipe saine répond facilement, avec un exemple réel, et explique ce qu’elle a changé.

Qui devrait postuler

Personne ne répond à chaque ligne de cette offre, et personne ne s’y attend. Utilisez les cinq exigences ci-dessus, pas la liste complète :

• Vous développez en informatique décisionnelle ou en analytique, maîtrisez SQL et la modélisation, et avez transféré du travail vers dbt ou un entrepôt infonuagique : postulez. La modélisation est votre force, et beaucoup d’entrevues lui donnent le plus de poids. Préparez les bases de Spark et de Kafka sans exagérer vos compétences.
• Vous êtes ingénieur backend et avez créé des services fiables : postulez si vous avez travaillé avec de grands volumes de données. Votre réflexe de relancer les tâches sans risque est précieux. Préparez la modélisation analytique : niveau de détail, schémas en étoile, tables d’historique.
• Vous avez un à trois ans d’expérience avec un ensemble d’outils modernes et gérés : cette offre dépasse probablement un peu votre niveau. Postulez si vous pouvez expliquer ce qui se passe derrière vos outils. Par exemple, comment ils traitent les données tardives et les nouvelles exécutions.
• Vous avez plusieurs années d’expérience en données, avec des outils plus anciens, et avez déjà effectué une migration vers le nuage : postulez, et demandez le niveau. Votre expérience des incidents et des chiffres qui doivent correspondre au cent près manque à cette équipe. Apprenez les noms actuels des idées que vous connaissez déjà.
• Vous avez des années d’expérience en exploitation de compteurs, en facturation ou ailleurs dans un service public, et savez maintenant développer : votre connaissance du domaine vaut plus pour cette équipe que « un atout » le suggère. Ce poste précis représente peut-être un trop grand pas aujourd’hui. Mais une conversation peut mener à un poste mieux adapté. Soyez honnête sur l’écart d’échelle.

Dans la partie 3, vous suivez cinq candidats, un pour chacune de ces situations. Chaque personne passe la même entrevue.

Transformer l’offre en plan de préparation

Reliez chaque exigence à une question probable et à une preuve que vous pouvez présenter.

Élément de l’offre	Question probable	Preuve nécessaire
SQL et modélisation des données	« Que représente une ligne dans cette table? Comment conservez-vous l’historique des liens entre compteurs et comptes? »	Un modèle que vous avez conçu, et une raison pour son niveau de détail
Python et Spark pour de grands volumes	« Votre tâche est deux fois plus lente qu’hier. Que regardez-vous en premier? »	Une tâche que vous avez rendue plus rapide ou moins coûteuse, avec des chiffres
Relances sans risque	« Que se passe-t-il si votre tâche s’exécute deux fois? »	Un pipeline que vous avez rendu idempotent, et comment vous l’avez testé
Données tardives et désordonnées	« Un relevé arrive avec trois jours de retard. Où va-t-il? »	Un récit sur des données tardives, en double ou incorrectes, et ce que vous avez changé
Collaboration avec les utilisateurs des données	« Parlez-moi d’une fois où un utilisateur a dit que vos chiffres étaient faux. »	Un vrai désaccord, et comment vous avez trouvé la vérité
Garde (manquante)	« Parlez-moi de votre pire incident. »	Un récit d’incident clair : ce qui a échoué, comment vous l’avez trouvé, ce que vous avez changé
Coûts (manquants)	« Cette requête lit cinq ans de données chaque nuit. Que changeriez-vous? »	Un exemple de réduction des coûts, même modeste
Données protégées (manquantes)	« L’assistant d’IA lit la consommation par compte. Qu’est-ce qui pourrait mal tourner? »	Des règles claires : qui peut voir quoi, et comment vous les faites respecter

Si vous n’avez pas encore de preuve pour une ligne, préparez cet élément. Notre leçon Se préparer aux candidatures montre la même méthode pour toute offre.

Questions à poser à l’équipe

Une entrevue va dans les deux sens (nos conseils). Ces questions transforment nos hypothèses en faits. Posez chacune au moment le plus approprié.

• Recruteur : « Quels outils l’équipe utilise-t-elle chaque jour? » « Quel est le niveau de ce poste? » « Y a-t-il une rotation de garde, et à quelle fréquence? » « Combien y a-t-il d’entrevues, et que couvre chacune? »
• Entrevue SQL et Python : « Est-ce proche du SQL que l’équipe écrit chaque jour? » « Comment l’équipe révise-t-elle le SQL avant sa mise en production? »
• Entrevue de conception de pipelines : « Quel a été le pire incident de données cette année, et qu’avez-vous changé ensuite? » « Comment l’équipe traite-t-elle les relevés qui arrivent en retard? » « Qui est responsable du coût de la plateforme? »
• Entrevue de modélisation des données : « Comment conservez-vous l’historique des comptes et des compteurs? » « Avez-vous une entente sur les changements de format avec les équipes responsables des systèmes sources? »
• Entrevue sur les valeurs, avec la facturation : « Quand la facturation et l’équipe de données sont en désaccord sur un chiffre, comment tranchez-vous? » « En pratique, que signifie une facture correcte pour votre équipe? »

Une réponse claire avec un exemple est un bon signe. Une réponse vague à une question simple donne aussi de l’information.

À vous de jouer : lire une offre qui vous intéresse

Trouvez une vraie offre d’ingénieur de données pour un poste qui vous intéresse. Faites ensuite quatre choses :

1. Décrivez le problème derrière l’offre en une phrase, sans nommer d’outils.
2. Comptez les outils. Regroupez-les selon leur fonction (stockage, traitement, planification, transformation, chargement). Dans chaque groupe, estimez lequel l’équipe utilise vraiment.
3. Classez les autres lignes dans les catégories vraiment exigé, souhait et manquant. Vérifiez surtout la garde, les coûts, les données tardives et les relances.
4. Créez le tableau de préparation pour les principales exigences, et écrivez une question pour chaque étape d’entrevue.

Si vous hésitez entre une exigence et un souhait, transformez cette ligne en question pour le recruteur.

La suite

À la prochaine page, nous examinons les cinq entrevues du processus de Tidewell. Nous verrons qui mène chacune, ce qu’elle vérifie et comment un intervieweur sérieux explore les limites de vos connaissances.