Questions d'entretien ingénieur data, par étape

Vous préparez peut-être cet entretien comme un entretien d'ingénieur logiciel classique, en vous demandant ce qui change. Cette section recense les étapes que ces entretiens réutilisent, pour que vous concentriez votre temps sur les deux qui séparent vraiment les candidats. Le filtre technique est rarement l'endroit où l'on perd une offre.

• SQL. Fonctions de fenêtrage, déduplication et performance des requêtes, souvent en direct.
• Modélisation des données. Concevoir des tables pour une activité décrite, et défendre le grain choisi.
• Conception de pipeline et d'ETL. Une étape de conception système ouverte, centrée sur le mouvement des données.
• Traitement distribué. Comment un framework exécute réellement votre job, et pourquoi il est lent.
• Codage. Python ou Scala, souvent plus léger qu'une étape d'ingénierie logicielle.
• Comportemental. Incidents d'astreinte, tableaux de bord cassés, et parties prenantes qui voulaient le chiffre hier.

Les intitulés de poste chevauchent fortement l'analytics engineering et les rôles de plateforme, donc le mix varie. Les banques de questions par rôle apparentées se trouvent sur le hub questions d'entretien par rôle.

SQL

• Dédupliquer une table en ne gardant que la ligne la plus récente par clé.
• Écrire une requête renvoyant le nombre de sessions de chaque utilisateur avec un intervalle d'inactivité de 30 minutes.
• Calculer un total cumulé et une variation d'un mois sur l'autre dans une seule requête.
• Trouver les lignes présentes dans le snapshot d'hier mais absentes de celui d'aujourd'hui.
• Que fait QUALIFY, et qu'écririez-vous sans lui ?
• Cette requête scanne un milliard de lignes et prend vingt minutes. Comment la diagnostiquez-vous ?
• Expliquez la différence entre partitionnement et clustering, et quand chacun aide.

Modélisation des données

• Concevez les tables pour l'historique des commandes d'une marketplace en ligne. Quel est le grain de votre table de faits ?
• Expliquez un schéma en étoile, et quand vous dénormaliseriez délibérément davantage.
• Qu'est-ce qu'une dimension à évolution lente, et comment implémentez-vous le type deux ?
• Une partie prenante veut que le reporting historique reflète la région actuelle d'un client. Qu'est-ce qui casse ?
• Comment modéliseriez-vous un flux d'événements qui arrive dans le désordre ?
• Quand choisiriez-vous une table large plutôt qu'un modèle normalisé ?

L'étape de modélisation récompense le fait de s'engager sur un grain et de le défendre. Les candidats qui décrivent trois designs possibles sans en choisir un obtiennent un moins bon score que ceux qui choisissent un design raisonnable et en nomment la faiblesse.

Conception de pipeline et d'ETL

• Concevez un pipeline qui charge les transactions quotidiennes dans un entrepôt pour le reporting.
• La source amont renvoie à nouveau les données d'hier. Que se passe-t-il pour votre job ?
• Comment rendez-vous un pipeline idempotent, et pourquoi est-ce important pour les relances ?
• Comment feriez-vous un backfill de deux ans d'historique sans perturber le chargement quotidien ?
• Des données en retard apparaissent trois jours après la fermeture de la partition. Que faites-vous ?
• Comment détecteriez-vous qu'un pipeline a réussi mais a produit des données erronées ?
• Que surveillez-vous, et qu'est-ce qui déclenche un appel à trois heures du matin ?

Traitement distribué et streaming

• Qu'est-ce qui cause un shuffle, et pourquoi est-il coûteux ?
• Votre job est lent et une tâche prend bien plus de temps que les autres. Que se passe-t-il ?
• Expliquez le data skew et deux façons de le traiter.
• Quand choisiriez-vous le streaming plutôt qu'un job batch planifié ?
• Que garantit réellement le traitement exactly once, et où cela ne tient-il pas ?
• Comment les watermarks gèrent-ils les événements désordonnés dans une agrégation fenêtrée ?

Remarquez combien peu de ces questions vous demandent de nommer un outil. En nommer un est le début de la réponse, pas la réponse. La relance est toujours pourquoi, et ce qui casse.

Lire ces listes crée de la reconnaissance. Les étapes de conception testent autre chose : garder un système en tête pendant que quelqu'un vous interrompt avec un cas de panne. Cela ne s'acquiert qu'en énonçant les designs à voix haute.

• Dessinez et racontez un pipeline en quinze minutes. Source, atterrissage, transformation, mise à disposition, plus comment chaque étape échoue.
• Attaquez votre propre design. Après chaque entraînement, demandez ce qui se passe en cas de relance, de données en retard et de changement de schéma.
• Ayez un chiffre prêt pour l'échelle. Lignes par jour, taille, budget de latence. Énoncer d'abord votre échelle supposée est valorisé.
• Écrivez du SQL à la main. Les étapes en direct utilisent souvent un simple éditeur, sans autocomplétion ni exécution.
• Répétez correctement une histoire d'incident. Ce qui a cassé, comment vous l'avez trouvé, ce que vous avez changé pour que cela ne se reproduise pas.

Une ingénieure data avec six ans d'expérience sur des pipelines batch s'est préparée en révisant les internes des frameworks, puis a calé sur « la source amont a renvoyé le fichier d'hier », parce qu'elle ne l'avait géré qu'à la main, sans jamais l'expliquer. Le savoir était là ; la réponse orale ne l'était pas. S'entraîner à l'étape de conception avec des relances, c'est exactement ce pour quoi le mode entretien simulé est conçu.