1. Compétences Techniques (40 points)
12 pts SQL & Optimisation
❓ Expliquez la différence entre une window function et un GROUP BY. Donnez un cas d'usage concret.
✅ Réponse Attendue :
• GROUP BY : agrégation qui réduit le nombre de lignes
• Window function : agrégation qui garde toutes les lignes
• Cas d'usage : calcul de moyenne glissante, ranking, cumul
• Exemple : ROW_NUMBER(), LAG(), LEAD(), SUM() OVER()
• Performance : window functions souvent plus efficaces
• Window function : agrégation qui garde toutes les lignes
• Cas d'usage : calcul de moyenne glissante, ranking, cumul
• Exemple : ROW_NUMBER(), LAG(), LEAD(), SUM() OVER()
• Performance : window functions souvent plus efficaces
🚩 Red Flags :
Confond les deux, pas d'exemple concret, ignore les aspects performance
❓ Comment optimiseriez-vous une requête SQL lente qui joint 3 tables de 100M+ lignes ?
✅ Réponse Attendue :
• EXPLAIN ANALYZE pour identifier bottlenecks
• Indexation appropriée (B-tree, bitmap selon cardinalité)
• Partitioning des tables (range, list, hash)
• Filtrer tôt (WHERE avant JOIN)
• Choisir bon type de JOIN (INNER vs LEFT)
• Matérialiser sous-requêtes complexes
• Statistiques à jour (ANALYZE)
• Indexation appropriée (B-tree, bitmap selon cardinalité)
• Partitioning des tables (range, list, hash)
• Filtrer tôt (WHERE avant JOIN)
• Choisir bon type de JOIN (INNER vs LEFT)
• Matérialiser sous-requêtes complexes
• Statistiques à jour (ANALYZE)
🚩 Red Flags :
Répond "ajouter des index" sans analyse, ignore partitioning
12 pts Python & Data Processing
❓ Quelle est votre expérience avec PySpark ? Expliquez les concepts de transformation lazy vs action.
✅ Réponse Attendue :
• Transformations (lazy) : map, filter, select → construit DAG
• Actions : collect, count, show → déclenche exécution
• Avantages : optimisation du plan d'exécution, évite calculs inutiles
• Exemple pratique : chaînage de transformations avant .collect()
• Connaît : broadcast variables, repartition, caching
• Actions : collect, count, show → déclenche exécution
• Avantages : optimisation du plan d'exécution, évite calculs inutiles
• Exemple pratique : chaînage de transformations avant .collect()
• Connaît : broadcast variables, repartition, caching
🚩 Red Flags :
Jamais utilisé Spark en production, confond avec Pandas
❓ Comment gérez-vous le traitement de fichiers CSV de 50 GB en Python ?
✅ Réponse Attendue :
• Streaming avec chunks (pd.read_csv avec chunksize)
• Utiliser Dask ou Polars pour out-of-core processing
• PySpark pour distributed processing
• Compression (gzip, parquet) pour réduire I/O
• Schema enforcement dès la lecture
• Parallélisation avec multiprocessing/asyncio
• Utiliser Dask ou Polars pour out-of-core processing
• PySpark pour distributed processing
• Compression (gzip, parquet) pour réduire I/O
• Schema enforcement dès la lecture
• Parallélisation avec multiprocessing/asyncio
🚩 Red Flags :
Tente de tout charger en RAM, ignore les solutions distribuées
10 pts Orchestration & Workflow
❓ Décrivez votre expérience avec Airflow. Qu'est-ce qu'un DAG idempotent ?
✅ Réponse Attendue :
• Idempotence : réexécuter le DAG produit même résultat
• Important pour retry, backfill, debugging
• Techniques : DELETE + INSERT, MERGE/UPSERT, partition overwrite
• Éviter : INSERT sans filtre, UPDATE sans WHERE
• Connaît : XCom, sensors, branching, sub-DAGs
• Alternatives : Prefect, Dagster, Temporal
• Important pour retry, backfill, debugging
• Techniques : DELETE + INSERT, MERGE/UPSERT, partition overwrite
• Éviter : INSERT sans filtre, UPDATE sans WHERE
• Connaît : XCom, sensors, branching, sub-DAGs
• Alternatives : Prefect, Dagster, Temporal
🚩 Red Flags :
Ignore l'idempotence, DAGs non-rejouables, pas de gestion d'erreurs
6 pts Cloud Data & Architecture
❓ Quelle est la différence entre un Data Warehouse et un Data Lake ? Qu'est-ce qu'un Data Lakehouse ?
✅ Réponse Attendue :
• Data Warehouse : données structurées, schéma défini, SQL, BI (Snowflake, Redshift)
• Data Lake : données raw (structurées/non-structurées), schema-on-read (S3, ADLS)
• Data Lakehouse : fusion des deux (Delta Lake, Iceberg, Hudi)
• Avantages lakehouse : ACID, time travel, schema evolution, coûts
• Cas d'usage : ML + BI sur mêmes données
• Data Lake : données raw (structurées/non-structurées), schema-on-read (S3, ADLS)
• Data Lakehouse : fusion des deux (Delta Lake, Iceberg, Hudi)
• Avantages lakehouse : ACID, time travel, schema evolution, coûts
• Cas d'usage : ML + BI sur mêmes données
🚩 Red Flags :
Confusion entre concepts, ignore les formats modernes (Delta, Iceberg)
2. Soft Skills & Adaptabilité (35 points)
12 pts Résolution de Problèmes
❓ Décrivez un pipeline de données complexe que vous avez debuggé en production.
✅ Réponse Attendue :
• Contexte clair : impact business, volumétrie, stack
• Démarche méthodique : logs, monitoring, reproduction
• Root cause analysis : SQL explain, Spark UI, métriques
• Solution : optimisation concrète avec résultats mesurables
• Learnings : prévention future, documentation, alerting
• Démarche méthodique : logs, monitoring, reproduction
• Root cause analysis : SQL explain, Spark UI, métriques
• Solution : optimisation concrète avec résultats mesurables
• Learnings : prévention future, documentation, alerting
🚩 Red Flags :
Problème trivial, approche anarchique, pas de résultat mesurable
10 pts Collaboration & Communication
❓ Comment collaborez-vous avec des Data Scientists, Analysts, et Product Managers ?
✅ Réponse Attendue :
• Data Scientists : fourniture de données propres, pipelines ML
• Analysts : création de tables agrégées, documentation
• PM : traduction besoins business en specs techniques
• Outils : Slack, JIRA, dbt docs, data catalog
• Exemple concret de projet cross-fonctionnel réussi
• Analysts : création de tables agrégées, documentation
• PM : traduction besoins business en specs techniques
• Outils : Slack, JIRA, dbt docs, data catalog
• Exemple concret de projet cross-fonctionnel réussi
🚩 Red Flags :
"Je travaille seul", manque d'empathie, jargon technique excessif
8 pts Data Quality & Governance
❓ Comment assurez-vous la qualité des données dans vos pipelines ?
✅ Réponse Attendue :
• Tests automatisés : Great Expectations, dbt tests, custom checks
• Validation schéma : schema enforcement, type checking
• Monitoring : métriques data (nulls, duplicates, freshness)
• Alerting : alertes automatiques sur anomalies
• Documentation : data catalog, lineage (Atlan, DataHub)
• Validation schéma : schema enforcement, type checking
• Monitoring : métriques data (nulls, duplicates, freshness)
• Alerting : alertes automatiques sur anomalies
• Documentation : data catalog, lineage (Atlan, DataHub)
🚩 Red Flags :
Pas de tests, validation manuelle, ignore data observability
5 pts Veille Technologique
❓ Quelles sont les dernières évolutions de l'écosystème data engineering que vous suivez ?
✅ Réponse Attendue :
• Formats : Delta Lake 3.0, Iceberg, Hudi
• Orchestration : Dagster, Prefect, Temporal
• Transformation : dbt Core/Cloud, SQLMesh
• Observability : Monte Carlo, Metaplane, Elementary
• Sources : Data Engineering Weekly, blogs (dbt, Databricks)
• Orchestration : Dagster, Prefect, Temporal
• Transformation : dbt Core/Cloud, SQLMesh
• Observability : Monte Carlo, Metaplane, Elementary
• Sources : Data Engineering Weekly, blogs (dbt, Databricks)
🚩 Red Flags :
Connaissances datées, pas de veille active
3. Fit Culturel & Motivation (15 points)
8 pts Alignement avec Pyl.Tech
❓ Pourquoi rejoindre Pyl.Tech ? Qu'est-ce qui vous attire dans notre projet data ?
✅ Réponse Attendue :
• Recherche effectuée sur Pyl.Tech : valeurs, projets, stack
• Alignement : souveraineté numérique, data moderne, impact
• Intérêt technique : stack moderne (Snowflake, dbt, Airflow)
• Envie de construire : architectures data from scratch
• Motivation intrinsèque : passion pour data engineering
• Alignement : souveraineté numérique, data moderne, impact
• Intérêt technique : stack moderne (Snowflake, dbt, Airflow)
• Envie de construire : architectures data from scratch
• Motivation intrinsèque : passion pour data engineering
🚩 Red Flags :
Réponse générique, aucune recherche, motivation uniquement salariale
7 pts Autonomie & Ownership
❓ Comment gérez-vous l'ownership d'un projet data de A à Z ?
✅ Réponse Attendue :
• Cadrage : besoins, specs, architecture, estimation
• Développement : code quality, tests, revues
• Déploiement : CI/CD, monitoring, rollback plan
• Maintenance : documentation, alerting, amélioration continue
• Exemple concret de projet piloté end-to-end
• Développement : code quality, tests, revues
• Déploiement : CI/CD, monitoring, rollback plan
• Maintenance : documentation, alerting, amélioration continue
• Exemple concret de projet piloté end-to-end
🚩 Red Flags :
Besoin d'être encadré en permanence, fuite de responsabilités
4. Cas Pratiques Suggérés (10 points)
🧪 Cas Pratique 1 : Architecture Data Warehouse
Contexte : E-commerce avec 10M utilisateurs, 500K commandes/jour. Besoin de BI temps réel + ML.
Tâche : Concevoir l'architecture data complète (ingestion → transformation → serving).
Points d'évaluation :
- Choix technologiques justifiés (ingestion, storage, transformation, BI)
- Modélisation des données (star schema, data vault)
- Stratégie CDC (Change Data Capture)
- Gestion de la latence et du throughput
- Estimation des coûts (compute + storage)
🧪 Cas Pratique 2 : Debugging Pipeline Airflow
Contexte : DAG Airflow qui charge des données depuis une API externe. Échec récurrent depuis 3 jours.
Tâche : Identifier la cause et proposer une solution robuste.
Points d'évaluation :
- Démarche de debugging (logs, retry logic, monitoring)
- Gestion des erreurs (API rate limit, timeout, data quality)
- Solution : retry avec backoff exponentiel, alerting, idempotence
- Prévention : tests, documentation, SLA monitoring
🧪 Cas Pratique 3 : Optimisation Coûts Cloud
Contexte : Facture AWS Redshift : 10K€/mois. Direction demande réduction de 50% sans perte de performance.
Tâche : Proposer un plan d'optimisation concret.
Points d'évaluation :
- Analyse des coûts (compute, storage, data transfer)
- Stratégies : compression, partitioning, reserved instances, migration S3
- Trade-offs : performance vs coût
- Mesure de l'impact : avant/après avec métriques
5. Tableau de Scoring
| Catégorie | Critère | Points Max | Score Candidat |
|---|---|---|---|
| Compétences Techniques (40) | SQL & Optimisation | 12 | |
| Python & Data Processing | 12 | ||
| Orchestration & Workflow | 10 | ||
| Cloud Data & Architecture | 6 | ||
| Soft Skills (35) | Résolution de Problèmes | 12 | |
| Collaboration & Communication | 10 | ||
| Data Quality & Governance | 8 | ||
| Veille Technologique | 5 | ||
| Fit Culturel (15) | Alignement avec Pyl.Tech | 8 | |
| Autonomie & Ownership | 7 | ||
| Cas Pratiques | 10 | ||
| SCORE TOTAL | 100 | ||
📊 Interprétation du Score
- 85-100 : ⭐⭐⭐ Excellent - Recommandé fortement
- 70-84 : ⭐⭐ Bon - À considérer sérieusement
- 55-69 : ⭐ Moyen - Avec réserves
- < 55 : ❌ Insuffisant - Ne pas retenir