Que testent vraiment les entretiens d'analyste de données ?

Qui vous parle réellement à chaque étape

Un processus de recrutement d'analyste de données est rarement une seule conversation. C'est généralement trois ou quatre, chacune menée par quelqu'un avec un rôle différent et qui vérifie quelque chose de différent.

L'entretien de présélection avec le recruteur ne teste pas votre capacité d'analyse. Il confirme que vous pouvez parler de votre travail en langage clair, que vos attentes salariales et votre préavis correspondent au poste, et que vous n'avez pas mal lu l'intitulé (analyst, analytics engineer et data scientist s'utilisent vaguement, et les annonces veulent parfois l'un tout en s'intitulant autrement).

Le tour technique est généralement mené par quelqu'un qui fait le travail au quotidien — un analyste senior ou un manager analytics, parfois un data engineer si le poste touche beaucoup au travail de pipeline. C'est le tour SQL et statistiques, et c'est celui pour lequel les candidats se préparent insuffisamment parce qu'ils supposent que la séniorité signifie moins de code, ce qui est l'inverse : plus le poste est senior, plus vous devrez probablement écrire du SQL correct sous pression temporelle sans qu'un linter rattrape vos erreurs.

Le tour d'étude de cas ou « problème métier » est souvent mené par quelqu'un de l'équipe que vous supporteriez réellement — un product manager, un responsable marketing, un business partner finance. Ils ne notent pas votre syntaxe SQL. Ils vérifient si vous pouvez prendre une question vague comme « pourquoi les inscriptions ont-elles baissé le mois dernier » et la transformer en quelque chose de mesurable sans qu'on vous dise comment.

Un dernier tour avec un hiring manager ou un directeur porte généralement sur le jugement et l'adéquation : comment vous gérez le désaccord avec un stakeholder, comment vous priorisez quand trois personnes veulent des analyses contradictoires pour vendredi.

L'évaluation technique : à quoi elle ressemble réellement

Pour la plupart des postes d'analyste de données dans la tech, attendez-vous à un ou plusieurs de ces éléments :

• Un test SQL en direct ou enregistré. Pas des questions pièges sur la syntaxe, mais une requête sur un schéma avec des lignes dupliquées, des clés étrangères nullables, ou une jointure many-to-many qui gonflera silencieusement vos décomptes si vous vous trompez. Demandes courantes : fonctions de fenêtre (ROW_NUMBER() OVER (PARTITION BY ...) pour dédupliquer ou classer), une auto-jointure pour comparer le comportement d'un utilisateur d'une période à l'autre, et un GROUP BY avec une clause HAVING plutôt qu'un WHERE. Si vous pouvez écrire une requête correcte mais ne pouvez pas expliquer pourquoi vous avez dédupliqué avant d'agréger, cet écart se voit.
• Un exercice à faire chez soi avec un jeu de données réel ou réaliste. On vous demandera généralement de répondre à une question métier, pas seulement de produire des graphiques. Les interviewers lisent ceux-ci pour voir si vous avez énoncé vos hypothèses (comment avez-vous défini un « utilisateur actif » ?), si vous avez signalé les problèmes de qualité des données au lieu de les contourner discrètement, et si votre recommandation découle des chiffres que vous avez montrés ou semble avoir été décidée à l'avance.
• Une démonstration d'outil. Si le poste mentionne Looker, Tableau, Power BI ou Mode, on peut vous demander de partager votre écran et de construire quelque chose en direct, ou de critiquer un tableau de bord existant. Cela vérifie si vous pouvez choisir un type de graphique qui n'induit pas en erreur, pas si vous connaissez tous les menus.
• Statistiques légères. Pour les postes touchant à l'expérimentation, attendez-vous à des questions sur ce qu'une p-value signifie réellement, comment vous dimensionneriez un échantillon pour un test A/B, et ce qui arrive à votre confiance quand vous lancez cinq métriques sur un test et appelez la plus petite p-value la victoire.

Certaines entreprises sautent entièrement l'exercice à domicile et font tout cela en direct, sur un écran partagé, parce que les exercices à domicile peuvent être externalisés ou prendre six heures non payées aux candidats. Que ce soit mieux pour vous dépend de si vous pensez plus vite que vous n'écrivez ; il n'y a pas de consensus parmi les équipes de recrutement sur quel format est plus équitable, et vous devriez vous attendre à l'un ou l'autre.

Les questions qui testent vraiment quelque chose

Une poignée de questions qui semblent standard portent presque tout le signal. Voici ce qu'elles vérifient réellement.

« Parlez-moi d'une analyse qui a changé une décision. » Cela ne demande pas un résumé de projet. Cela vérifie si vous pouvez tracer une ligne depuis un chiffre spécifique, vers une personne spécifique, vers une action spécifique qu'elle a prise et qu'elle n'aurait pas prise autrement. Si votre réponse se termine à « et j'ai trouvé que la conversion était plus faible sur mobile », vous avez décrit une observation, pas un résultat. L'interviewer écoute ce qui s'est passé après que vous ayez envoyé l'analyse.

« Comment mesureriez-vous si cette fonctionnalité fonctionne ? » Cela teste si vous partez par défaut sur une métrique ou interrogez d'abord la question. Une réponse solide demande ce que « fonctionne » signifie pour le métier avant de nommer une métrique, signale au moins une façon plausible dont la métrique évidente pourrait être trompeuse (une fonctionnalité qui augmente l'engagement en rendant quelque chose plus difficile à trouver n'est pas une victoire), et nomme une métrique de garde aux côtés de celle principale. Une réponse faible saute directement à « je suivrais les utilisateurs actifs quotidiens ».

« Parlez-moi d'une fois où votre analyse était fausse, ou vous l'auriez faite différemment. » Cela vérifie l'honnêteté intellectuelle, et c'est plus difficile à simuler que les gens ne le pensent parce qu'une non-réponse répétée (« Je ne pense pas avoir eu tort, mais si je devais dire quelque chose... ») est instantanément reconnaissable pour quiconque a livré des analyses pour de vrai. Ce qu'ils veulent : ce qui était faux, comment vous l'avez découvert, et ce que vous avez changé dans votre façon de travailler en conséquence.

Un problème SQL en direct avec un piège — lignes dupliquées, une jointure qui se multiplie, un champ date avec des formats mixtes. Cela teste si vous vérifiez vos décomptes de lignes avant et après une jointure, à voix haute, sans qu'on vous le dise. Les analystes qui ont été échaudés par une jointure multiplicative le font automatiquement. Les analystes qui ne l'ont pas été ne le font pas, et l'interviewer sait généralement en trente secondes quel type il observe.

Ce qu'une réponse superficielle sonne comme

Pour quelqu'un qui fait ce travail, quelques schémas trahissent un candidat qui ne s'est pas réellement assis avec le désordre de vraies données.

Décrire l'outil au lieu de la décision — « J'ai construit un tableau de bord dans Tableau avec des filtres pour la région et la date » — et s'arrêter là. Personne n'a demandé à quoi ressemblait le tableau de bord ; ils ont demandé ce qui a changé à cause de lui.

Réciter la définition d'une p-value sans pouvoir dire ce qu'elle ne vous dit pas. Si quelqu'un ne peut pas expliquer, dans ses propres mots, pourquoi un résultat statistiquement significatif sur un échantillon minuscule ne vaut pas automatiquement la peine d'agir, il a mémorisé le terme plutôt que de l'utiliser.

Sauter directement à un graphique ou une requête dans une étude de cas sans d'abord demander ce que le métier entend réellement par le terme dans la question — « engagement », « churn », « actif » — signifient des choses différentes dans différentes entreprises, et les analystes qui ont travaillé avec de vrais stakeholders savent demander avant de construire.

Revendiquer la propriété d'une analyse sans mentionner que quelqu'un l'a contestée. Le vrai travail analytique implique que quelqu'un dans la pièce soit en désaccord avec votre chiffre ou votre cadrage. Une réponse sans friction dedans est soit un travail très facile soit une histoire édulcorée.

Et en SQL spécifiquement : écrire une requête qui compile mais double-compte silencieusement à cause d'une jointure non gérée, et ne pas le remarquer, et ne pas vérifier.

Ce qu'il faut réellement faire avant l'entretien

Choisissez un projet de votre propre historique — idéalement un avec des données vraiment désordonnées — et répétez son explication en moins d'une minute : la question, ce que vous avez trouvé, ce qui a changé. Si vous ne pouvez pas le faire en moins d'une minute, vous n'avez probablement pas fini de séparer la découverte du bruit autour d'elle.

Pratiquez le SQL sur un schéma avec des doublons et des nulls, pas des données de tutoriel propres. Exercez-vous spécifiquement aux auto-jointures, fonctions de fenêtre pour la déduplication et le classement, et à la vérification des décomptes de lignes avant et après une jointure.

Préparez une histoire honnête sur le fait d'avoir eu tort, avec la correction, pas seulement l'erreur.

Avant un tour d'étude de cas, écrivez deux ou trois questions que vous poseriez à un stakeholder avant de toucher aux données, et pratiquez à les poser à voix haute plutôt que de sauter à un graphique.

Si vous envoyez beaucoup de candidatures et recevez peu de retours, l'étape d'entretien ci-dessus n'est généralement pas le goulot d'étranglement — c'est d'être invité à celle-ci. jobmarket.pro lit chaque annonce en regard de votre profil réel et vous dit où vous correspondez vraiment avant de préparer quoi que ce soit en votre nom.