Entretien analyste de données : SQL, études de cas et ce qu'on évalue vraiment

La plupart des candidats analystes de données se préparent pour un entretien qui n'existe pas. Ils pratiquent la syntaxe SQL jusqu'à écrire une fonction fenêtre dans leur sommeil, construisent des tableaux de bord dans Tableau, et mémorisent la différence entre une table de faits et une table de dimension. Puis ils s'assoient en entretien et passent la plupart de leur temps à répondre à un problème métier auquel ils n'ont jamais réfléchi — qu'est-ce qui provoque une chute du taux de conversion, comment mesurer l'impact d'un changement produit, que feriez-vous si les données vous disaient quelque chose que l'équipe ne voulait pas entendre.

Le SQL est nécessaire mais pas suffisant. Ce qui distingue les candidats analystes de données qui obtiennent des offres de ceux qui n'en obtiennent pas n'est pas la compétence technique — c'est la réflexion commerciale. Ce guide se concentre sur ce que les recruteurs évaluent vraiment, et comment le démontrer.

Ce que les intervieweurs évaluent vraiment

Pouvez-vous transformer des données en décisions ?

La chose la plus importante qu'un analyste de données fait n'est pas d'interroger des bases de données. C'est de traduire des données en décisions sur lesquelles les parties prenantes peuvent agir. Les intervieweurs veulent savoir si vous l'avez fait en pratique — si vous avez jamais changé l'avis de quelqu'un ou modifié un plan d'action grâce à une analyse que vous avez menée. Si chaque réponse à des questions comportementales se termine par « j'ai construit un tableau de bord » ou « j'ai lancé l'analyse », vous vous arrêtez avant ce qui compte.

En entretien, cela transparaît dans la façon dont vous cadrez votre travail. « J'ai identifié que l'abandon du panier était 18 % plus élevé pour les utilisateurs mobiles que les utilisateurs de bureau, ce qui a conduit l'équipe produit à reprioriser la refonte du checkout mobile » est un signal complètement différent de « j'ai construit une analyse d'entonnoir ».

Savez-vous à quoi ressemblent de bonnes données ?

Les analystes qui ont travaillé avec des données réelles — par opposition aux jeux de données d'enseignement propres — ont des cicatrices liées à la qualité des données. Les recruteurs expérimentés sondera cela en demandant ce que vous faites quand les données ne semblent pas correctes, comment vous avez validé votre analyse, ou si vous avez déjà repéré une métrique rapportée incorrectement. Les candidats qui disent faire confiance aux données qu'ils reçoivent semblent naïfs. Les candidats qui décrivent leur processus de validation semblent comme quelqu'un qui a déjà été pris en défaut et a appris.

Pouvez-vous expliquer votre travail à un public non technique ?

C'est un vrai facteur différenciateur que de nombreux candidats techniquement solides échouent. Pouvoir expliquer une analyse de cohorte à un directeur financier, ou décrire ce qu'une p-value signifie en langage courant à un directeur marketing, est une partie essentielle du travail. En entretien, cela apparaît souvent comme une question sur la façon dont vous avez communiqué des résultats ou géré une partie prenante qui n'était pas d'accord avec votre analyse.

Êtes-vous curieux, ou simplement diligent ?

Les meilleurs analystes de données sont curieux d'une façon qui se manifeste comme un instinct à remettre en question les chiffres plutôt qu'à simplement les rapporter. Les intervieweurs le perçoivent en observant si vous explorez des résultats inattendus plutôt que de les lisser, si vous demandez pourquoi quelque chose se passe plutôt que seulement ce qui se passe, et si vous cherchez proactivement des histoires dans les données plutôt que d'attendre qu'on vous les demande.

Les questions qu'on vous posera vraiment

« Écrivez une requête pour trouver le deuxième salaire le plus élevé dans une table d'employés. »

Question SQL classique. Il existe plusieurs approches correctes : utiliser une sous-requête avec MAX, utiliser DENSE_RANK() comme fonction fenêtre, ou utiliser LIMIT/OFFSET. Ce que les intervieweurs regardent vraiment : connaissez-vous plusieurs façons de résoudre ce problème, pouvez-vous expliquer les compromis de performance, et gérez-vous les cas limites (que se passe-t-il s'il n'y a pas de deuxième salaire, s'il y a des ex-æquo) ?

Pensez à voix haute. « J'utiliserais DENSE_RANK ici parce qu'il gère correctement les ex-æquo, et je filtrerais WHERE rank = 2 dans un CTE. L'approche par sous-requête fonctionne aussi mais devient plus complexe si vous devez généraliser au nième salaire. » Ce type de réflexion à voix haute signale une vraie expérience, pas une syntaxe mémorisée.

« Notre taux de conversion à l'inscription a chuté de 15 % le mois dernier. Comment enquêteriez-vous ? »

C'est le type de question le plus important dans un entretien d'analyste de données : la question d'investigation structurée. Ne sautez pas directement à une hypothèse. Parcourez une décomposition systématique à voix haute.

Cadre : Validez d'abord (la mesure est-elle correcte, le code de suivi a-t-il changé ?), puis segmentez (la baisse concerne-t-elle tous les utilisateurs ou une cohorte spécifique — mobile vs bureau, organique vs payant, nouveau vs récurrent ?), puis la chronologie (quand exactement a-t-il chuté — est-ce en corrélation avec un déploiement, une campagne, un événement externe ?), puis la vérification croisée (cette baisse est-elle isolée à la conversion ou les métriques en amont sont-elles également affectées ?). Ce n'est qu'après tout cela que vous devriez formuler une hypothèse.

Les réponses solides se terminent par : « Sur cette base, mon hypothèse principale est X, et voici la requête que j'écrirais pour la tester. »

« Comment mesureriez-vous l'impact d'une nouvelle fonctionnalité que nous venons de lancer ? »

C'est une question de conception de mesure. Commencez par clarifier : y avait-il un test A/B ? Si oui, expliquez comment vous analyseriez les résultats de l'expérience — validation de la taille de l'échantillon, significativité statistique, métriques de garde-fous, segmentation. Si non, discutez des méthodes quasi-expérimentales : différences-en-différences, analyse avant/après avec des mises en garde sur les facteurs confondants, ou l'utilisation d'un groupe de retenue s'il en a été préservé un.

L'important est de signaler ce que vous pouvez et ne pouvez pas conclure de chaque approche. Un analyste qui dit « nous ne pouvons pas établir la causalité à partir de ces données » est plus digne de confiance qu'un analyste qui rapporte une corrélation comme un résultat.

« Parlez-moi d'une fois où votre analyse a conduit à une décision avec laquelle vous n'étiez pas d'accord. »

C'est une question comportementale sur le jugement et la dynamique professionnelle. La réponse que l'intervieweur cherche : vous avez soulevé votre préoccupation avec des preuves, vous avez présenté une interprétation alternative, et vous avez finalement soutenu la décision même si vous aviez encore des réserves — tout en signalant peut-être que vous souhaiteriez revenir dessus après le prochain cycle de données.

La réponse à éviter : soit vous avez suivi en silence (pas de colonne vertébrale), soit vous avez refusé d'avancer jusqu'à ce qu'ils soient d'accord avec vous (pas de collaboration). Ce que les intervieweurs écoutent, c'est si vous comprenez que votre travail est d'éclairer les décisions, pas de les prendre unilatéralement.

Comment se préparer la veille

Travaillez cinq problèmes SQL à partir de zéro. Pas les difficiles — les classiques. Agrégations, jointures, fonctions fenêtre, arithmétique de dates, auto-jointures. L'objectif est de s'assurer que vos mains se souviennent de la syntaxe sous une légère pression. Les erreurs sur du SQL simple lors d'un partage d'écran en entretien ont l'air plus graves qu'elles ne le sont, alors entraînez-vous sur les bases.

Préparez une histoire d'investigation. Pensez à une fois où vous avez trouvé quelque chose d'inattendu dans des données — une métrique qui ne semblait pas correcte, une tendance qui contredisait les attentes, un résultat qui a changé un plan. Structurez-la : que regardiez-vous, qu'est-ce qui semblait anormal, comment avez-vous enquêté, qu'avez-vous trouvé, et qu'est-ce qui s'est passé ensuite. Cette histoire vous sera utile dans plusieurs types de questions.

Révisez les métriques publiques et le modèle économique de l'entreprise. Comprendre comment l'entreprise gagne de l'argent et quels sont ses principaux moteurs de performance vous permet d'ancrer vos réponses dans leur contexte. Un candidat qui cadre son analyse d'une chute de conversion en termes du modèle de revenus réel de l'entreprise ressemble à quelqu'un qui a fait attention.

La fonctionnalité de fiche de préparation de NextCV génère un guide de préparation ciblé à partir de la description de poste spécifique — incluant les thèmes de questions probables, les domaines techniques à réviser, et des invitations d'histoires comportementales alignées sur le poste de données en question. Utile pour structurer votre préparation finale la veille.

Notez trois choses qui pourraient mal tourner avec la métrique clé de l'entreprise. Avant l'entretien, prenez ce que leur KPI principal est probablement (DAU, GMV, taux de conversion, rétention) et réfléchissez à ce qu'une baisse de cette métrique pourrait signifier — erreur de mesure, problème produit, facteur externe, changement d'attribution. Cela vous prépare aux questions d'investigation et rend vos réponses moins robotiques.

Erreurs courantes pour les candidats analystes de données

Rapporter les résultats sans les interpréter

« Les données montrent que le taux de conversion a chuté de 15 % en mars » est une description. « Les données montrent que le taux de conversion a chuté de 15 % en mars, concentré sur les utilisateurs mobiles, à partir du lendemain du déploiement du nouveau flux de checkout — ce qui suggère une régression dans l'expérience mobile » est une analyse. Les candidats qui s'arrêtent à la description inquiètent les recruteurs parce que la traduction des données en insights, c'est le travail. Montrez que vous n'êtes pas qu'un narrateur — vous interprétez.

Ignorer la validation des données

Passer directement à l'analyse sans discuter de la façon dont vous valideriez la qualité des données est un signal d'alarme. Les données réelles sont désordonnées : le suivi se casse, les définitions changent, les pipelines de données ont des bugs. Les analystes expérimentés ont des frameworks pour vérifier leur travail — ils cherchent des nulls inattendus, des valeurs invraisemblables et des totaux qui ne s'additionnent pas. Mentionner cet instinct dans vos réponses, même brièvement, signale une expérience réelle.

Être trop confiant sur la causalité

Dire « cette fonctionnalité a causé l'amélioration » quand tout ce que vous avez sont des données corrélationnelles d'un déploiement non contrôlé est un problème de crédibilité. Les analystes solides sont précis sur ce qu'ils peuvent et ne peuvent pas affirmer. Utiliser un langage comme « ceci est cohérent avec l'hypothèse que... » ou « nous pouvons observer une corrélation, bien que nous aurions besoin d'une expérience contrôlée pour établir la causalité » signale la maturité analytique. Cela vous rend également plus digne de confiance quand vous affirmez quelque chose avec force.

Sur-ingéniérer la réponse technique

Quand un intervieweur pose une question SQL, il cherche souvent la solution la plus simple et lisible, pas la plus optimisée. Les candidats qui se précipitent immédiatement vers des fonctions fenêtre complexes là où un GROUP BY suffirait peuvent signaler qu'ils optimisent pour la sophistication plutôt que la clarté. Écrivez d'abord un SQL propre et lisible. Si la performance est une préoccupation, mentionnez-la et discutez des compromis.

Les entretiens d'analyste de données portent fondamentalement sur le jugement : le jugement d'investiguer systématiquement avant de conclure, le jugement de communiquer les résultats honnêtement même quand ils sont gênants, et le jugement de savoir ce que les données supportent réellement par rapport à ce que vous voulez qu'elles disent. Les compétences techniques vous amènent à l'entretien. Ces habitudes vous valent l'offre.