10 questions d'interview pour le job de Analytics Engineer
On te le disait dans un article de blog précédent que le métier de Analytics Engineer est de plus en plus demandé.
On t'expliquait dans cet article, entre autres choses, que le métier d'Analytics Engineer n'est pas auss bien établi et que donc les exigences des entreprises de ces nouveaux profils peuvent beaucoup varier.
Ceci dit, on peut tout de même identifier les tâches les plus récurrentes pour un Analytics Engineer et créer un ensemble de questions auxquelles on s'attend lors d'une interview.
Dans cet article, on t'en a compilé 10 de ces questions! Et si jamais tu en rencontres plus, n'hésite pas à nous les partager en commentaire ici ou sur notre serveur Discord gratuit
1. Quelles mesures de qualité des données mettrais-tu dans projets analytics?
Cette question est éminemment importante pour un Analytics Engineer vu que ton travail sera d'ingérer et de transformer les données dans la warehouse analytics. Tu seras donc responable de la qualité de ces données!
Les mesures de qualité qu'on peut mettre en place peuvent être divisées en 2 catégories.
La qualité à l'ingestion
- S'assurer que ces données se conforment au schéma attendu: plus spécifiquement qu'on reçoit les bonnes colonnes et le type de données de chacune est correct aussi.
- S'assurer qu'on reçoit les données à temps
- S'assurer que les sont complètes
- Ajouter des méta-données (heure de réception + nom du fichier d'origine si utile) à la table des données brutes. Ceci aidera avec le diagnostic des erreurs plus tard.
- S'assurer qu'on n'introduit pas de données dupliquées, surtout si le schéma définit une clé primaire
La qualité post-ingestion
- Mettre en place un monitoring des valeurs des données: par exemple, la moyenne mobile d'une colonne peut permettre d'identifier une anonamlie plus tard
- Mettre en place un monitoring du volume de données reçues ce qui nous permettra d'identifier les anomalies de livraison
- Mettre en place un archivage des données trop vieilles ou trop peu utilisées.
- Mettre en place le linéage des données qui nous permettra de comprendre comment nos données évoluent dans notre warehouse.
2. Quelles mesures mettrais-tu en place pour te conformer à la régulation du RGPD?
Cette question fait appel au concept plus fondamental de la data gouvernance. En effet, ce n'est qu'en mettant en place un tel processus qu'on peut vraiment s'assurer notre conformité avec le Règlement Général de Protection des Données.
Ceci dit, on peut lister plusieurs mesures qui découleront du process de la data gouvernance:
- Identification des tables et colonnes contenant des PII ou données personnelles identifiables. Cet inventaire est une première étape extrêmement importante pour le reste du processus.
- Restreindre l'accès à ces données grâce au masquage des données. La plupart des warehouse analytics modernes (type BigQuery, Redshift, Snowflake) permettent de créer des groupes d'utilisateurs avec différents types d'accès aux données. Ainsi un data analyste qui travaille sur les métriques du site (nombre de visiteurs par ex), n'aura pas accès aux adresses IP, celles-ci étant inutiles pour ce travail.
- Mettre en place le linéage des données, c'est-à-dire identifier les dépendances entre les différentes tables. Ceci nous permet de comprendre l'évolution de nos données et de continuer à mettre la restriction des données selon les nécessités.
- Mettre en place un processus simple et automatisé pour permettre de répondre rapidement aux requête d'accès, modification et suppressions des données faites par les utilisateurs.
- Qui dit RGPD dit consentement: on a donc besoin d'un moyen simple et automatisé de stocker le consentement des utilisateurs vis-à-vis de l'usage de leurs données.
Visualisation d'un arbre de dépendances entre plusieurs tables avec l'interface de DBT
3. Si une ligne dans le fichier de données que t’as reçu n’est pas correcte, que fais-tu?
Cette question est, à mon avis, philosophique! En effet, dans cette situation trois options s'offrent à nous:
- Ignorer tout le fichier
- Ingérer le reste des lignes correctes
- Ingérer tout le fichier sans trop se soucier
La bonne réponse dépendra des contraintes spécifiques à ton projet mais on peut identifier quelques idées.
Si les données sont destinées à du reporting financier, leur véracité est évidemment super importante. Il peut être donc plus prudent d'ignorer tout le fichier et de lancer une investigation immédiatement. En effet, notre monitoring a identifié une erreur mais on n'a aucune assurance qu'il n'y en a pas d'autres ailleurs dans le fichier.
Si les données sont destinées à des data scientistes ou analystes qui les utiliseront pour leurs modèles, on peut vouloir leur livrer les données le plus rapidement possible pour ne pas les ralentir. Dans ce cas, on identifie les lignes litigieuses et on lance l'investigation aussi tôt que possible.
On peut être dans le cas où le volume des données est si gros (par exemple les données de visite d'un grand site) qu'un pourcentage contrôlé de données incorrectes est acceptable. Dans ce cas, on vérifie qu'on reste dans les limites et si oui on continue notre pipeline.
Tu as peut-être remarqué qu'au moins dans les 2 premiers cas, on veut pouvoir comprendre ce qui se passe. Il est donc important d'envisager une table qui contiendra les données problématiques pour permettre un accès rapide.
4. Comment t’assurer que le code SQL ou Python que t’écris est correcte avant de le déployer en production?
La réponse à cette question tient en 2 concepts: tests-unitaires et CI/CD.
Les tests-unitaires, en gros, nous permettent de tester notre code et de nous assurer qu'il produit le résultat escompté.
La CI/CD correspond à un pipeline qu'on définit dans un outil tel que GitHub actions, GitLab-CI, Jenkins...etc qui nous permet de lancer à chaque commit dans notre repository, entre autres, des tests unitaires. Une fois ces tests passés, le pipeline de CI/CD procède au déploiement du code dans les environnements de DEV puis de PROD.
Image représentant un pipeline CI/CD avec quelques étapes importantes comme le linting, les tests unitaires et le déploiement au différents environnements
5. Comment t’assurer que la connexion à la BDD est fermée quelque soit l’état d’exécution de ton code Python?
Cette question sert à s'assurer que tu n'es pas un cowboy ou cowgirl de la programmation! En tant qu'utilisateur de la plateforme, tu dois faire attention aux ressources et ne pas utiliser plus que nécessaire.
L'une des techniques pour ceci est de t'assurer que ta connexion à la BDD est toujours fermée, que ton code ait une erreur ou pas. Pour cela, tu as 2 options
- Tu utilises le bloc try-except-finally où tu mets dans le finally le code qui ferme la connexion
- Tu utilises un "context manager" qui s'assurera automatiquement de la libération des ressources
Illustration d'un code utilisant le bloc try-except-finally
Illustration d'un code utilisant un context manager pour ouvrir une connexion à Snowflake
6. C’est quoi une classe en programmation orientée objet?
Oof cette question a tellement de niveaux de réponses!
Pour ce qui nous intéresse, une classe est un concept en programmation qui nous permet de représenter les objets avec lesquels on travaille.
Cet objet peut être la data qu'on reçoit, le profil d'un client ou la configuration pour notre pipeline de données.
La classe nous permet de définir des attributs (variables) et méthodes (fonctions) qui nous permettront ensuite de simplifier notre code.
7. Si tu as le choix entre plusieurs formats de fichiers pour la livraison des données, lequel préférerais-tu et pourquoi?
S'il devait y avoir une seule réponse et sans refléchir: Parquet.... mais évidemment la vie est plus compliquée!
Tout dépend de ta BDD d'origine et de ta source: que ce soit une autre BDD ou une API.
Il faut savoir par contre que les datawarehouse analytics telle que Snowflake, BigQuery ou Redshift organisent les données en colonnes par opposition à un stockage par ligne. C'est d'ailleurs pour cela qu'un SELECT * n'est jamais une bonne idée!
Parquet est un format de fichier binaire qui organise aussi les données en colonnes. Sa lecture sera donc plus performante! Donc si on a le choix, c'est parfait.
Le pire format (à mon humble avis) est XML: trop de textes, trop de balises et il m'est déjà arrivé de trouver un CSV dans un XML 🤯
Exemple de fichier XML. Remarque la quantité de texte et de balises nécessaires pour repréesnter 3 lignes de données
8. Dans un projet DBT, à quoi sert en général le dossier analyses?
Dans ce dossier, on met en général les requêtes ad-hoc, celles qu'on utiliserait pour une analyse mais on ne veut pas forcément stocker leur résultat dans une table ou une vue.
9. Quelle est la différence entre les approches Slowly Changing Dimensions de type 0, 1 et 2?
Déjà il faut savoir qu'il en existe plus des SCD.
Le SCD 0 est un format de table où la table (ou certaines colonnes en particulier) ne changent jamais. Par exemple la date de naissance d'un client.
Le SCD 1 est un format de table où tout le contenu de la table est rafraîchi à chaque chargement de données sans qu'on ne soucie de l'histoire.
Le SCD 2, tu l'auras deviné, essaie de stocker l'histoire en attribuant à chaque ligne d'une table une date de début de validité et une date de fin de validité.
Extrait de notre cours DBT dans lequel on montre comment créer des tables au format SCD2 avec DBT.
10. À quoi servent les fichiers .gitignore et .gitkeep?
Comme leur nom l'indique, le premier sert à indiquer à Git quels fichiers et dossiers peuvent être ignorés.
Le second indique à Git quels dossiers garder. En général, on doit utiliser un fichier .gitkeep par dossier
Illustration du contenu du fichier .gitignore et de l'usage du fichier .gitkeep
Si tu cherches à te lancer dans le monde merveilleux de l'Analytics Engineer, jette un coup d'oeil à nos offres de formation.
Pour savoir ce que nos étudiants pensent de notre formation, direction notre page TrustPilot
Abonnez-vous
Abonnez-vous à notre newsletter et recevez les actualités directement dans votre boite email
CATÉGORIES
NOUS SUIVRE
À PROPOS
Analytics Engineer & Data Analyst, on partage des conseils, des outils et des bonnes pratiques pour optimiser tes projets