Les entretiens de data engineering ne sont pas des entretiens d'analyse avec un peu de Python greffé dessus. Le jury cherche à savoir si on peut vous confier le pipeline qui alimente chaque tableau de bord, chaque modèle et chaque rapport financier de l'entreprise, et si vous remarqueriez qu'il produit discrètement de mauvais chiffres. Les questions tournent donc autour de la conception, de l'exactitude et de l'exploitation, plutôt que d'algorithmes astucieux. Voici celles qui tombent vraiment, ce que chacune sonde, et comment se construit une bonne réponse.
Ce sont les schémas généraux du poste ; si vous voulez la liste courte pour un entretien précis, collez la vraie offre d'emploi dans le Question Predictor gratuit et obtenez les vingt questions les plus susceptibles de tomber dans ce processus précis.
Que testent vraiment les entretiens d'ingénieur data ?
Quatre choses : savez-vous concevoir un pipeline qui survit au contact de données amont sales, votre SQL va-t-il au-delà d'une jointure et d'un GROUP BY, modélisez-vous les données pour que les analystes n'aient pas à deviner vos intentions, et traitez-vous l'exactitude comme un problème d'ingénierie plutôt que comme un espoir. La connaissance des outils compte bien moins que le discernement.
Les pondérations changent selon l'entreprise : les équipes produit centrées entrepôt de données insistent sur la modélisation et le SQL, les équipes plateforme sur le débit et le coût, les startups veulent savoir si vous savez monter le tout seul et le garder pas cher. La génération de code a rendu l'écriture d'une transformation triviale, alors les jurys passent désormais leur temps sur les décisions qu'un générateur ne peut pas prendre : pourquoi cette granularité, pourquoi cette clé de partition, que se passe-t-il lors d'un rejeu.
À quoi ressemble le processus d'entretien d'ingénieur data ?
Un processus type compte quatre à six étapes sur deux à trois semaines : une préqualification recruteur, un test SQL, un tour de conception de pipeline, un tour de modélisation et un entretien comportemental. Les processus seniors ajoutent un tour systèmes plus poussé sur le débit, le coût et les pannes. Les exercices à rendre sont moins courants qu'avant mais apparaissent encore dans les petites entreprises.
- Préqualification avec le recruteur (20 à 30 minutes). Stack, échelle, fourchette de salaire. Décrivez votre plus gros pipeline en deux phrases : volume, latence, qui le consomme.
- Test SQL (45 à 60 minutes). Du SQL en direct dans un éditeur partagé, les fonctions de fenêtrage servant de filtre habituel.
- Tour de conception de pipeline (60 minutes). On vous donne une source, un consommateur et une attente de fraîcheur, puis vous concevez le chemin entre les deux et vous le défendez.
- Tour de modélisation des données (45 à 60 minutes). Conception de schéma pour une activité décrite, en général avec un piège sur l'historique ou les données en retard.
- Responsable du recrutement ou comportemental. Prise de responsabilité et parties prenantes. Les questions sur l'astreinte tombent souvent ici aussi.
Si vous connaissez déjà l'entreprise, les banques de questions par entreprise donnent une lecture plus rapide du style maison que de fouiller les forums.
Quelles questions de conception de pipeline tombent en entretien d'ingénieur data ?
Les questions de conception vous donnent une source, une destination et une contrainte, puis observent votre raisonnement. Le jury veut vous voir demander le volume, la fraîcheur, la stabilité du schéma et qui hurle quand ça casse, avant de dessiner la moindre boîte. Les bons candidats dimensionnent le problème à voix haute, puis conçoivent la chose la plus simple qui réponde au besoin et qu'on puisse relancer sans risque.
Racontez-moi un pipeline que vous avez construit, de bout en bout. Ce que ça sonde : avez-vous exploité quelque chose, ou seulement contribué une tâche au DAG de quelqu'un d'autre. Donnez la forme dans l'ordre (source, ingestion, stockage, transformation, mise à disposition), puis les chiffres : lignes par jour, latence, coût, qui en dépendait. Terminez par ce qui a mal tourné une fois et ce que vous avez changé, parce que ces détails vous achètent de la crédibilité pour le reste du processus.
Concevez un pipeline qui ingère environ 500 Go d'événements de clickstream par jour et les rend disponibles aux analystes pour 9 h. Ce que ça sonde : le dimensionnement, le partitionnement, et l'écart entre l'arrivée et la disponibilité. Clarifiez d'abord l'exigence de fraîcheur, parce que du quotidien pour 9 h est un problème de batch, pas de streaming. Déposez les événements bruts dans un stockage objet partitionné par date et par heure, transformez-les vers une table modélisée, et gardez la couche brute immuable pour pouvoir rejouer. Mentionnez la taille des fichiers ; des milliers de fichiers minuscules sont la blessure auto-infligée classique.
Comment gérez-vous les événements en retard ou dans le désordre ? Ce que ça sonde : avez-vous compris que les données n'arrivent pas poliment. Séparez le temps de l'événement du temps d'ingestion, définissez une fenêtre de retard que vous acceptez, et retraitez les partitions concernées plutôt que de rafistoler des lignes une par une.
Batch ou streaming : comment répondre à la question d'architecture ?
Répondez à partir des besoins, pas de vos préférences. Le streaming justifie son coût quand quelque chose agit sur la donnée en quelques secondes : contrôles de fraude, stock en direct, alerting. Le batch est la bonne réponse pour presque tout ce qui alimente un tableau de bord ou un rapport mensuel. Le piège ici, c'est l'enthousiasme, parce qu'un candidat qui dégaine une stack de streaming pour alimenter un rapport quotidien optimise l'intérêt plutôt que l'activité.
Quand choisiriez-vous le streaming plutôt que le batch, et qu'est-ce que ça vous coûte ? Ce que ça sonde : le discernement sur la charge opérationnelle. Nommez les coûts honnêtement : tests plus durs, reprises d'historique plus dures, de l'état à gérer, plus de surface d'astreinte, une équipe qui doit désormais comprendre les watermarks. Puis donnez la condition qui justifie tout ça : un consommateur qui agit sur la donnée plus vite que votre cadence de batch ne peut la livrer.
Quelle est la différence entre temps de l'événement et temps de traitement ? Ce que ça sonde : les fondamentaux du streaming. Le temps de l'événement, c'est le moment où la chose s'est produite ; le temps de traitement, c'est le moment où votre système l'a vue. Des agrégats fenêtrés sur le temps de traitement dérivent et finissent par contredire discrètement la source de vérité.
Comment obtiendriez-vous une sémantique exactly-once dans un pipeline de streaming ? Ce que ça sonde : répétez-vous du marketing ou expliquez-vous des mécanismes. De bout en bout, vous construisez une livraison at-least-once plus des écritures idempotentes, avec une clé déterministe pour qu'un rejeu écrase au lieu de dupliquer. Des sinks transactionnels et des offsets commités avec l'écriture rendent ça réel.
Quelles questions de modélisation faut-il attendre ?
Les tours de modélisation testent si vous concevez pour les questions que l'activité va poser plutôt que pour les données que vous avez sous la main. Attendez-vous à une activité décrite, à une demande de schéma, puis à une complication : historique, hiérarchie, ou un attribut qui change. La modélisation dimensionnelle reste le langage commun, même dans les équipes qui appellent leurs couches d'un nom plus à la mode.
Expliquez le schéma en étoile face à une seule grande table dénormalisée. Laquelle construiriez-vous ? Ce que ça sonde : le raisonnement sur la granularité et le changement. Traitez la simplicité des requêtes et le coût de stockage d'un côté, le coût des jointures et les attributs dupliqués de l'autre, puis choisissez selon le moteur et les consommateurs. Les entrepôts en colonnes ont rendu les grandes tables moins chères qu'avant, mais l'étoile gagne encore quand les dimensions changent indépendamment.
Comment modélisez-vous une dimension à évolution lente ? Ce que ça sonde : l'historique. Le type 1 écrase et perd le passé ; le type 2 ajoute une ligne par version avec des dates de validité et un indicateur de version courante, ce dont la plupart des équipes analytiques ont besoin pour du reporting à une date donnée.
Comment partitionneriez-vous une grande table, et qu'est-ce qui tourne mal ? Ce que ça sonde : la conception physique. Partitionnez sur la colonne que les consommateurs filtrent, en général une date, surveillez la taille des partitions, et gardez le partitionnement distinct du clustering ou des clés de tri. L'échec classique est de partitionner sur une colonne à forte cardinalité comme un ID utilisateur, ce qui produit des millions de fichiers minuscules et des requêtes plus lentes que sans partitionnement du tout.
Jusqu'où va le tour SQL pour les ingénieurs data ?
Plus loin que pour les analystes. Les jointures et l'agrégation sont supposées acquises ; le filtre, ce sont les fonctions de fenêtrage, la déduplication et le raisonnement sur un plan de requête. La plupart des tests enchaînent trois ou quatre questions de plus en plus vicieuses, et la dernière demande en général une fonction de fenêtrage ou une auto-jointure. Exposez votre approche avant de taper, parce que le raisonnement est plus lourdement noté que la syntaxe.
Trouvez la deuxième plus grande valeur par groupe, par exemple la deuxième personne la mieux payée de chaque service. Ce que ça sonde : l'aisance avec les fonctions de fenêtrage. Dégainez DENSE_RANK ou ROW_NUMBER dans une sous-requête et filtrez sur le rang à l'extérieur, puis dites lequel vous avez choisi et pourquoi, parce que les ex aequo se comportent différemment.
Dédupliquez une table pour que seule la dernière ligne par clé survive. Ce que ça sonde : la tâche réelle la plus courante du métier. ROW_NUMBER partitionné par la clé, trié par horodatage décroissant, filtré à 1. Puis demandez ce qui départage deux lignes partageant le même horodatage, parce que dans les vraies données ça arrivera.
Une requête sur une table partitionnée est devenue lente. Comment la diagnostiquez-vous ? Ce que ça sonde : un débogage guidé par les preuves. Lisez le plan, vérifiez si l'élagage de partitions a bien eu lieu (une fonction enroulée autour de la colonne de partition le tue en général), cherchez le skew, vérifiez les statistiques périmées, vérifiez si la disposition des fichiers a dégénéré en une multitude de petits fichiers.
Quelles questions d'orchestration les recruteurs posent-ils ?
Les questions d'orchestration testent si vos pipelines peuvent être relancés sans crainte. Le mot à avoir sous la main, c'est idempotence : lancer deux fois la même tâche pour la même date logique doit produire le même résultat, pas le doubler. Attendez-vous à des relances sur les dépendances, les reprises, l'alerting et la reprise d'un an d'historique sans faire fondre le cluster ni le budget.
Comment rendez-vous un job planifié idempotent et rejouable sans risque ? Ce que ça sonde : la maturité opérationnelle. Paramétrez chaque tâche par une date logique plutôt que par "maintenant", écrivez dans une partition clé sur cette date, et remplacez cette partition au relancement au lieu d'y ajouter.
Comment gérez-vous les dépendances entre pipelines détenus par des équipes différentes ? Ce que ça sonde : avez-vous travaillé dans une vraie organisation. Préférez un signal explicite (un jeu de données marqué comme terminé, un événement, un capteur avec un timeout) à un décalage d'horaire optimiste.
Comment les recruteurs testent-ils la qualité des données ?
Ils décrivent un chiffre faux et vous regardent enquêter. Le signal qu'ils veulent, c'est que vous traitiez l'exactitude comme testable : comptages de lignes, taux de valeurs nulles, unicité des clés, intégrité référentielle, contrôles de distribution par rapport à la veille, fraîcheur. Les candidats qui disent qu'ils regarderaient le tableau de bord à l'oeil perdent le tour ; ceux qui décrivent des assertions à l'intérieur du pipeline, capables de bloquer une mauvaise publication, le gagnent.
Comment savez-vous qu'un pipeline a produit des données correctes ? Ce que ça sonde : la qualité est-elle conçue dedans ou vérifiée après coup. Mettez les tests dans le pipeline lui-même : clés uniques, contraintes de non-nullité, plages acceptées, écarts de comptage de lignes par rapport à l'exécution précédente.
Une partie prenante dit que le chiffre d'affaires d'hier est faux. Racontez-moi l'enquête. Ce que ça sonde : un débogage structuré plus la communication. Définissez ce que veut dire faux (par rapport à quelle source, de combien), puis remontez couche par couche vers l'amont, en comparant comptages et totaux à chaque frontière pour isoler où le chiffre diverge.
Une source amont change le type d'une colonne sans prévenir. Comment gérez-vous ça ? Ce que ça sonde : gérer ce qui échappe à votre contrôle. Échouez tôt à l'ingestion avec un contrôle de schéma plutôt que de convertir silencieusement, mettez le lot fautif en quarantaine, puis corrigez en avant avec un rejeu.
Quelles questions comportementales pose-t-on aux ingénieurs data ?
Les tours comportementaux pour les métiers de la donnée se concentrent sur la confiance et les parties prenantes. Attendez-vous à une question sur un incident où vos données étaient fausses, et une sur une demande que vous avez repoussée. Répondez avec une structure serrée : la situation, ce que vous avez décidé, l'arbitrage que vous avez accepté, et le changement durable qui a suivi.
Parlez-moi d'une fois où vos données étaient fausses et où quelqu'un d'autre l'a remarqué en premier. Ce que ça sonde : la prise de responsabilité et l'honnêteté. Ne minimisez pas. Dites ce qui a cassé, combien de temps c'était faux, qui a agi dessus, comment vous avez communiqué, et le contrôle que vous avez ajouté pour que ça ne puisse pas se reproduire en silence.
Parlez-moi d'une demande que vous avez refusée, ou négociée à la baisse. Ce que ça sonde : savez-vous protéger une plateforme de cent demandes ponctuelles. Montrez que vous avez compris le besoin sous-jacent, proposé un chemin moins coûteux pour y répondre, et rendu visible le coût de la demande d'origine, plutôt que de dire non et de devenir l'équipe que tout le monde contourne.
Quelles erreurs coulent les candidats ingénieurs data ?
Surtout des défauts de discernement plutôt que des trous de connaissance. Les jurys rejettent rarement quelqu'un pour méconnaissance d'un outil précis ; ils rejettent ceux qui conçoivent avant de poser des questions, qui ne savent pas relancer leur propre pipeline, ou qui traitent un chiffre faux comme le problème de quelqu'un d'autre. Voici les schémas qui font perdre un tour.
- Concevoir avant de poser des questions. Volume, fraîcheur, stabilité du schéma et consommateurs doivent être établis avant de dessiner quoi que ce soit. Commencer par un nom d'outil fait perdre le tour de conception.
- Citer des outils au lieu de mécanismes. Dire que vous utiliseriez tel moteur n'explique rien. Dites ce que le job fait, comment il partitionne, où se produit le shuffle, ce que ça coûte.
- Ignorer le rejeu et la reprise d'historique. Une conception qu'on ne peut pas relancer sans risque pour une date passée n'est pas une conception de production, et les recruteurs seniors le vérifient délibérément.
- Traiter la qualité comme le travail d'un autre. Si votre réponse à un chiffre faux est que l'analyste aurait dû le repérer, le tour est terminé.
- Un SQL qui s'arrête aux jointures. Les fonctions de fenêtrage sont désormais le filtre standard, et les rater passe pour un manque de profondeur, aussi bonnes qu'aient été vos réponses d'architecture.
Comment se préparer à un entretien d'ingénieur data ?
Répétez un pipeline que vous connaissez par coeur, avec de vrais chiffres attachés, parce qu'il servira d'ancre à la moitié du processus. Travaillez les fonctions de fenêtrage et la déduplication jusqu'à ce qu'elles soient dans les doigts. Entraînez-vous à concevoir à voix haute avec un chrono, puisque le format punit ceux qui savent penser mais pas raconter. Préparez deux histoires d'incident et une histoire de partie prenante.
Avant le processus lui-même, collez la vraie offre d'emploi dans le Question Predictor gratuit et travaillez les vingt questions qu'il signale pour ce poste précis, parce qu'une équipe plateforme lakehouse et une équipe d'analytics engineering ne vous demanderont pas du tout la même chose.
Pour les tours en direct, GhostPilot est un copilote d'entretien en temps réel : un panneau latéral d'extension Chrome et une application de bureau Windows optionnelle qui transcrivent l'appel, attrapent la question au vol et ont une réponse structurée prête environ deux secondes plus tard. Il aide surtout sur les questions à piège, comme un énoncé de conception qui attend discrètement une stratégie de rejeu. C'est une suggestion, pas un script, et les détails viennent toujours de votre propre travail. L'offre gratuite vous donne 10 minutes d'entretien en direct par semaine, sans carte bancaire.
FAQ entretien ingénieur data
Combien de temps dois-je préparer un entretien d'ingénieur data ? Deux à trois semaines conviennent à la plupart des profils intermédiaires : une semaine sur le SQL et la modélisation, une semaine à s'entraîner à concevoir à voix haute, quelques jours sur les histoires. Les analystes qui basculent vers l'ingénierie doivent prévoir plus long, surtout sur la conception de pipeline.
Les entretiens d'ingénieur data comportent-ils encore des questions d'algorithmie ? Certaines grandes entreprises gardent un tour d'algorithmie, en général de facile à moyen. La plupart des équipes l'ont remplacé par du SQL et un exercice Python pratique sur du parsing ou de la transformation. Ne laissez pas le bachotage d'algorithmes prendre la place de la modélisation.
Quel tour pèse le plus lourd ? La conception de pipeline, pour les profils intermédiaires et seniors, parce qu'elle teste le discernement, la communication et la profondeur d'un seul coup. Pour les postes juniors, le test SQL est la vraie barrière, et c'est là que se produisent la plupart des refus.
Dois-je admettre que je n'ai jamais utilisé un outil qu'ils mentionnent ? Oui. "Je ne l'ai pas fait tourner en production, mais voilà comment je raisonnerais et ce que je vérifierais en premier" vaut mieux que du bluff, et les recruteurs data sont exceptionnellement doués pour repérer le flou artistique, puisqu'ils passent leurs journées à trouver ce qui cloche.