Questions d’entretien pour Data Analyst – Préparez un plan de réponse solide

Un entretien Data Analyst ressemble souvent à un parcours en plusieurs étapes : screening RH (autour de 30 minutes), évaluation technique SQL (environ 1 heure), puis discussion avec le hiring manager ou le responsable BI (45 minutes). Dans certains cas, un cas pratique ou un take-home est proposé (2 à 4 heures), avec une restitution attendue. Le point clé : le recruteur ne cherche pas uniquement du SQL “propre”, il cherche surtout votre capacité à produire un résultat fiable et actionnable, mesuré par des KPI métier. Sur des questions type cohorte, rétention ou churn, vous devez être capable de justifier vos choix de grain et de calcul.

Pour maximiser vos chances, préparez 2 à 3 scénarios complets que vous savez raconter de bout en bout : question métier, hypothèse, approche analytique, requêtes SQL (CTE, window functions), et traduction en recommandation. Par exemple, un scénario “COMEX” exige souvent des comparaisons temporelles (YTD, MoM) et des alertes de seuils (ex : marge sous 10% sur un segment). Côté outils, soyez prêt à expliquer comment vous mapperiez vos mesures dans Power BI ou Tableau : modèle sémantique, filtres cohérents, et gestion des définitions (CA net vs CA brut). Enfin, entraînez-vous à répondre en termes de métriques : conversion, LTV, churn, MRR/ARR, CAC, taux de rétention.

Si l’annonce mentionne un environnement moderne, parlez sans surcharger : DB (PostgreSQL/BigQuery/Snowflake), orchestration (Airflow) et transformation (dbt) si pertinent. Le recruteur apprécie lorsque vous savez proposer une logique réutilisable : créer une couche de “métriques” (views SQL ou tables consolidées) plutôt que recalculer à chaque dashboard. Pour un KPI comme la conversion, vous devez expliciter la fenêtre (ex : D+1, D+7) et la définition des événements. En entretien, l’objectif est d’aligner votre méthode avec le besoin décisionnel : “quoi regarder”, “comment interpréter”, “quoi faire ensuite” avec une cadence (hebdo, mensuelle, temps réel).

Sur les questions SQL, attendez-vous à des requêtes qui combinent logique métier et techniques avancées : CTE (WITH), JOIN multi-tables, agrégations avec HAVING, et fonctions de fenêtre (ROW_NUMBER, RANK, LAG/LEAD). Une bonne réponse n’est pas seulement “ça marche”, c’est “ça se maintient” : lisibilité, étapes logiques distinctes, et gestion claire des doublons (COUNT DISTINCT vs COUNT). Par exemple, pour calculer un taux de réachat par cohorte, vous devez montrer comment vous associez le mois M à M+1 et comment vous évitez de gonfler les comptes. C’est aussi là que des index ou des filtres en amont peuvent être mentionnés pour prouver votre sens de l’optimisation.

Quand vous parlez de performance en entretien, restez concret : proposez des actions simples plutôt que du tuning obscur. Par exemple, pré-filtrer sur une période (WHERE order_date >= …), utiliser un grain cohérent pour éviter les cartésiens, et privilégier des agrégations avant jointures lorsque cela réduit la volumétrie. Si vous utilisez BigQuery ou Snowflake, vous pouvez évoquer l’intérêt de tables de staging partitionnées et la réduction des scans (filtrer sur la partition). Pour PostgreSQL, mentionner des index sur (client_id, order_date) ou sur les clés de jointure est perçu comme un bon signal. Le recruteur veut savoir que vous produisez des résultats corrects dans un temps raisonnable, surtout si le KPI alimente des dashboards quotidiens.

Enfin, soyez prêt à expliquer vos choix de logique de données : traitement des NULL, normalisation des dates (date_trunc), cohérence des fuseaux horaires et gestion des annulations/remboursements si le CA est “net”. Pour un KPI comme churn, le “comment” compte autant que le “quoi” : définition d’un client actif, fenêtre d’observation, et règles en cas de données manquantes. Dans la restitution, rattachez toujours le SQL au dashboard attendu : quelles colonnes servent de dimensions, quelles mesures sont agrégées, et comment les filtres utilisateur doivent influencer les calculs.

Pour la partie BI, le recruteur évaluera votre capacité à organiser une page pour qu’un décideur comprenne en moins de 60 secondes. Un bon dashboard COMEX se structure souvent en 3 niveaux : vue exécutive (quelques KPIs clés + tendance), vue détaillée (par segment : canal, géographie, produit) et vue temporelle (12 mois glissants, comparaison N-1). Sur chaque KPI, vous devez intégrer une logique de comparaison et, idéalement, des indicateurs de signal (ex : variation % et statut vert/jaune/rouge). Côté outils, mentionnez Power BI ou Tableau et montrez que vous savez gérer des filtres dynamiques et des mesures robustes.

Le storytelling data passe aussi par les “questions que le dashboard doit résoudre”. Par exemple : “Pourquoi la marge baisse ?”, “Quel segment tire la performance ?”, “L’évolution est-elle structurelle ou ponctuelle ?”. Vous pouvez proposer des contrôles : détection de ruptures (variation anormale), segmentation par cohortes, et annotations de campagnes/événements. Un KPI comme la conversion doit être interprété avec le contexte du funnel : si l’acquisition baisse mais la conversion monte, la recommandation ne sera pas la même. Le recruteur veut voir que vous comprenez les effets de levier et pas seulement la visualisation.

Pour prouver la maturité, parle de cadence et de fiabilité. Exemple : un rafraîchissement quotidien, un suivi hebdomadaire des anomalies, et un suivi mensuel de tendance avec seuils. Vous pouvez aussi citer un bon réflexe : définir une “source of truth” (table de métriques gold) et éviter les divergences de calcul entre équipes. En entretien, donnez un exemple de correction : “unifiez la définition CA net”, “corriger la fenêtre churn”, ou “stabiliser la règle de dédoublonnage”. Cette approche inspire confiance et augmente la probabilité que votre recommandation soit adoptée.