Imaginez que votre voisine affiche une note sur la porte de votre immeuble : « Recherche une personne pour des travaux. Plomberie, électricité, carrelage, menuiserie, peinture. Au moins 5 ans d’expérience. Au moins 5 ans avec les tuyaux. » Vous frappez à sa porte et lui demandez quel est le problème. Elle vous montre la cuisine. De l’eau coule sous l’évier, mais seulement certains jours, et seulement après l’utilisation de la laveuse. Vous connaissez maintenant le vrai travail à faire. Il y a une fuite. La difficulté, c’est de comprendre pourquoi elle survient seulement parfois.
Une offre d’emploi ressemble souvent à cette note. L’équipe a un vrai problème. Puis quelqu’un rédige l’offre, ajoute tous les outils dont l’entreprise a déjà parlé et demande plusieurs années d’expérience avec chacun. Si vous lisez seulement la liste, vous poserez la mauvaise question : « Est-ce que je maîtrise tous ces outils? » La meilleure question est : « Où est la fuite, et est-ce que je sais comment en trouver la cause? »
Dans ce guide, nous lisons ensemble une offre d’emploi d’ingénieur de données. Nous cherchons le problème derrière l’offre, relevons ce qu’elle omet et décidons quoi demander à l’équipe.
L’offre ci-dessous concerne une entreprise qui n’existe pas. Nous l’avons créée à partir de 10 offres réelles d’ingénieur de données dans différents secteurs. Elles provenaient d’entreprises d’énergie, de commerce de détail, de technologies financières et d’entreprises en démarrage. Nous avons conservé leurs tendances réelles : les parties claires, les parties vagues et les petits problèmes des vraies offres. Puis nous les avons réunies dans une seule entreprise. Ainsi, tout le guide peut utiliser la même équipe et les mêmes données.
Tidewell Energy vend de l’électricité aux ménages et aux entreprises en Colombie-Britannique, au Canada, et aide à équilibrer le réseau électrique. Le siège social est à Vancouver, et environ 900 personnes y travaillent. Chaque client de Tidewell possède un compteur intelligent. Ce petit appareil installé à la maison mesure la consommation d’électricité et transmet le chiffre par un réseau. Tidewell en compte environ 1,2 million.
Chaque compteur envoie un relevé toutes les 15 minutes. Cela représente 96 relevés par jour par compteur, soit environ 115 millions de relevés par jour au total (1,2 million × 96). Les compteurs envoient aussi des événements, par exemple « le courant a été coupé » ou « quelqu’un a ouvert le boîtier du compteur ». Ces relevés déterminent la facture de chaque client. Ils alimentent aussi une équipe qui prévoit la consommation d’électricité du lendemain. Depuis cet été, ils alimentent également un assistant d’IA qui explique les factures aux clients. Une petite équipe Data Platform de sept ingénieurs de données déplace toutes ces données, les nettoie et les prépare pour leurs utilisateurs.
Tidewell Energy fournit de l’électricité à plus d’un million de ménages et d’entreprises partout en Colombie-Britannique. Nous construisons les fondations de données d’un réseau plus propre et plus intelligent. Les données sont au cœur de tout ce que nous faisons.
Nous recherchons un ingénieur de données passionné pour rejoindre notre équipe Data Platform. Vous concevrez, construirez et ferez évoluer des pipelines de données en temps réel et par lots. Ils transformeront chaque mois des milliards de relevés de compteurs intelligents en données fiables, prêtes pour l’IA. Ces données serviront à la facturation, aux prévisions de la demande et à nos nouveaux produits d’IA destinés aux clients.
Le salaire de base prévu pour ce poste se situe entre 120 000 et 150 000 $ CA par année. L’offre finale dépend de votre expérience et de votre niveau. Si vous avez besoin d’une mesure d’adaptation à une étape du processus, dites-le à notre responsable du recrutement.
Offre d'emploi composite pour une entreprise fictive, créée à partir de 10 offres réelles d'ingénieur de données.
Avant de comparer l’offre à votre CV, répondez à trois questions à son sujet. Notez vos réponses. Cela prend environ dix minutes. Comparez-les ensuite aux nôtres ci-dessous.
Quel problème l’équipe a-t-elle? Répondez en une phrase, avec des mots simples, sans nommer d’outils.
Qui utilise les données que cette personne déplace? Et que se passe-t-il pour ces personnes quand les données sont erronées?
Comptez les outils dans la liste « Votre profil ». À votre avis, combien de ces outils une équipe de sept personnes utilise-t-elle chaque jour? Sur lesquels poseriez-vous des questions?
Nos réponses
1. Le problème. Tidewell reçoit un très grand nombre de petits relevés provenant de compteurs. Elle doit les transformer en chiffres fiables : une facture exacte, un historique complet, la bonne réponse à un client. L’offre mentionne une fois « fiables » et une fois « qualité des données ». Tout le reste porte sur les outils et la vitesse. C’est un petit indice que la fiabilité est le vrai problème et qu’il n’est pas encore résolu.
2. Les utilisateurs et le coût d’une erreur. Il y a trois groupes, et une erreur nuit à chacun de façon différente :
La facturation. Si un relevé est compté deux fois ou oublié, un vrai client reçoit une facture erronée. Les gens remarquent les erreurs de facturation, appellent et, parfois, portent plainte auprès de l’organisme de réglementation.
L’équipe de prévision de la demande. Si l’historique est incomplet, son modèle apprend à partir de données erronées, et les prévisions se dégradent. Personne ne le remarque pendant des semaines.
L’assistant d’IA du service à la clientèle. Il consulte la consommation d’un client pour expliquer une facture élevée. Si les données sont anciennes ou erronées, il donne au client une mauvaise explication de sa facture. Si les règles d’accès sont incorrectes, il pourrait montrer les données d’un client à un autre. C’est un problème de confidentialité, pas seulement de qualité.
3. Les outils. La liste contient dix outils. Plusieurs font le même travail. Snowflake et BigQuery sont deux entrepôts de données infonuagiques, et Databricks peut aussi en être un. Airflow et Dagster sont deux outils qui planifient et exécutent des pipelines. Spark Structured Streaming et Flink sont deux moteurs de traitement en continu. Une équipe de sept personnes choisit généralement un outil de chaque type et le conserve. Notre hypothèse : l’équipe utilise réellement Kafka, Databricks avec Spark, Airflow et dbt. Le reste vient d’autres offres ou d’anciens plans. Pour le savoir, posez la question. Nous y revenons à la page suivante.
Si vos réponses sont différentes, ce n’est pas un problème. Ce qui compte, c’est l’habitude : partez des données et des personnes qui les utilisent, pas de la liste d’outils. Dans les entrevues, la conversation porte sur le problème. Les outils sont abordés seulement comme des moyens de le résoudre.
À la page suivante, nous lisons l’offre ligne par ligne et expliquons franchement ce que chaque partie signifie. Nous distinguons les exigences des simples souhaits. Nous examinons aussi ce que l’offre ne dit pas : qui répare le pipeline à 5 h, et qui paie l’entrepôt. Ensuite, nous examinons les cinq entrevues du processus de Tidewell. Puis nous suivons cinq candidats différents dans la même entrevue de conception de pipeline.
