Les métriques SQL qui intéressent vraiment les recruteurs (d'après des entretiens réels)

Après quelques entretiens SQL, il est facile de supposer que chaque entreprise teste quelque chose de différent. Après 11 entretiens, cette hypothèse ne tenait plus. Malgré les différences entre les entreprises et les formats, les mêmes questions sur les métriques revenaient sans cesse. Cet article résume ce que j'ai vu le plus souvent et ce que ces modèles révèlent sur le fonctionnement réel des entretiens SQL.

Entre novembre 2023 et avril 2025, j'ai participé à 11 entretiens d'analyste de données qui comprenaient des tests techniques SQL. Bien que les entreprises et les formats variaient, les questions SQL elles-mêmes suivaient des modèles clairs et répétitifs. Les mêmes types de métriques apparaissaient sans cesse, quelle que soit la taille de l'entreprise ou le secteur d'activité.

Dans cet article, j'analyse les questions d'entretien SQL issues de ces entretiens et je les classe à l'aide des modèles métriques SQL présentés dans des articles précédents, notamment la série « Exploration d'un ensemble de données sur la croissance des vente ». Au lieu d'explorer les métriques au sein d'un seul ensemble de données, cet article se concentre sur la manière dont les questions d'entretien SQL s'articulent autour de types de métriques spécifiques.

L'objectif de cet article est simple : montrer quelles métriques SQL apparaissent le plus souvent dans les entretiens réels afin que vous puissiez hiérarchiser votre préparation plus efficacement. Plutôt que d'essayer de couvrir tous les sujets SQL possibles, cette analyse met en évidence les domaines dans lesquels le temps d'étude tend à offrir le meilleur retour sur investissement. C'est également la raison pour laquelle une pratique structurée du SQL axée sur des problèmes de reporting réels, comme les exercices utilisés dans les cours LearnSQL.fr, tend à correspondre davantage à ce qui est réellement testé lors des entretiens qu'une préparation SQL ad hoc ou de type puzzle.

Au fil de cet article, j'aborde également la manière dont le SQL est testé lors des entretiens, comment les réponses sont évaluées et pourquoi certains modèles de métriques apparaissent beaucoup plus fréquemment que d'autres. Il ne s'agit pas d'un guide sur la stratégie d'entretien par entreprise ou par secteur, et il ne contient pas de questions exactes ni de noms d'entreprises. L'accent est mis sur les modèles récurrents et ce qu'ils révèlent sur les compétences SQL fondamentales que les recruteurs testent systématiquement.

Si vous vous préparez à des entretiens d'analyste de données axés sur le SQL et que vous souhaitez vous concentrer sur ce qui apparaît réellement dans la pratique, cet article résume les modèles que j'ai rencontrés à plusieurs reprises et les leçons qu'ils impliquent.

Méthodes de test SQL rencontrées lors des entretiens

Au cours des 11 entretiens, le SQL a été évalué à l'aide de trois formats de test distincts. Si les compétences SQL sous-jacentes étaient similaires, le format du test a considérablement influencé la manière dont les réponses ont été jugées et les priorités apparentes des recruteurs.

Portails en ligne chronométrés

Le premier format était un portail en ligne chronométré, généralement hébergé sur des plateformes telles que HackerRank. Ces tests étaient limités à environ 20 à 50 minutes et comprenaient généralement une ou deux questions SQL. L'environnement étant standardisé et sans assistance, les questions ont tendance à être plus simples dans leur structure, mais strictes dans leur exécution. La justesse et la rapidité sont les critères les plus importants, et les solutions sont généralement évaluées comme réussies ou échouées.

Entretiens SQL en direct à l'aide d'un IDE partagé

Le deuxième format était un entretien SQL en direct mené dans un IDE partagé lors d'une session virtuelle. Lors de ces entretiens, j'étais souvent autorisé à écrire du code SQL sans l'exécuter, ce qui réduisait l'importance accordée à la syntaxe exacte et mettait l'accent sur l'exactitude logique et le raisonnement. Les erreurs de syntaxe étant moins coûteuses, les recruteurs avaient tendance à poser davantage de questions ou à introduire de l'ambiguïté, parfois en ajoutant des questions complémentaires à la question initiale. L'évaluation dans ce format était rarement binaire et reflétait plutôt la clarté avec laquelle le raisonnement était communiqué.

Devoirs SQL à faire à la maison

Le troisième format consistait en un devoir SQL à faire à la maison, généralement remis sous la forme d'un document contenant des schémas, des instructions de création de tables et plusieurs questions. Ces devoirs devaient généralement être rendus dans un délai d'un à deux jours et comprenaient un plus grand nombre de questions, souvent entre cinq et dix. Si les questions individuelles n'étaient pas toujours plus difficiles sur le plan conceptuel, elles étaient plus détaillées et prenaient plus de temps. Comme les entretiens en direct sur IDE, les tests à faire à la maison étaient notés de manière subjective, la structure, l'explication et les hypothèses jouant un rôle plus important dans l'évaluation finale.

Dans les trois formats, la méthode de test déterminait directement ce que signifiait une « bonne performance ». Les portails chronométrés récompensaient les solutions rapides et précises. Les formats en direct et à faire chez soi accordaient une importance supplémentaire à la manière dont les réponses étaient structurées, expliquées et adaptées à des énoncés de problèmes vagues ou imparfaits. Cette différence dans le contexte d'évaluation devient importante lorsqu'il s'agit d'interpréter les modèles de métriques SQL qui apparaissent le plus fréquemment dans les entretiens.

Comment les réponses SQL ont été évaluées

La manière dont les réponses SQL ont été évaluées variait considérablement en fonction du format du test. Dans les évaluations sur portail chronométrées, la notation était généralement binaire. Les requêtes produisaient soit le résultat attendu dans les limites de la plateforme, soit elles ne le produisaient pas. Il y avait peu de place pour les crédits partiels, les approches alternatives ou les explications. Dans ces conditions, l'exactitude et la rapidité l'emportaient sur toutes les autres considérations.

Les entretiens SQL en direct et les devoirs à faire à la maison ont été évalués différemment. Dans les deux cas, les réponses étaient rarement jugées comme étant simplement bonnes ou mauvaises. L'évaluation s'inscrivait plutôt dans un spectre qui tenait compte de la manière dont la solution était construite, dont les hypothèses étaient traitées et dont le raisonnement était communiqué clairement. Les examinateurs recherchaient souvent des signaux au-delà de la requête finale, par exemple si le candidat comprenait le grain des données, traitait les cas limites ou choisissait une approche raisonnablement évolutive.

Au cours de plusieurs entretiens, j'ai rencontré des systèmes de notation qui s'apparentaient davantage à un système informel qu'à un système strict de réussite ou d'échec. Une solution qui répondait aux exigences de base pouvait être considérée comme acceptable, tandis qu'une performance plus élevée exigeait de démontrer une approche alternative, de discuter des compromis ou d'identifier les problèmes potentiels liés aux données. Dans certains cas, deux candidats pouvaient arriver à des résultats corrects, mais être évalués différemment en fonction de la qualité de l'explication de leurs décisions.

Un autre facteur était que les performances SQL n'étaient pas toujours évaluées isolément. Certains processus d'entretien comprenaient plusieurs épreuves techniques, et les décisions finales étaient prises en tenant compte de l'ensemble de ces épreuves. Un entretien SQL solide pouvait être contrebalancé par des performances plus faibles dans d'autres domaines, et l'inverse était également vrai. De ce fait, il était souvent difficile de déterminer si un refus reflétait spécifiquement les performances SQL ou le résultat global de l'entretien.

Dans l'ensemble, ces différences d'évaluation expliquent pourquoi les résultats positifs ou négatifs ne constituent pas à eux seuls un moyen fiable d'évaluer les performances lors d'un entretien SQL. Elles permettent également de comprendre pourquoi il est plus utile d'étudier les modèles métriques SQL récurrents que les questions individuelles. La section suivante présente le cadre de modèles métriques utilisé pour classer les questions d'entretien dans cette analyse.

Bref récapitulatif du cadre des modèles métriques SQL

Dans cette analyse, j'ai classé les questions d'entretien SQL à l'aide du cadre des modèles métriques SQL présenté dans un article précédent sur la résolution de problèmes SQL basée sur les métriques. Ce cadre regroupe les questions SQL par type de métrique calculée plutôt que par fonctionnalités ou fonctions SQL spécifiques.

Les modèles utilisés dans cet article sont les suivants :

• KPI – métriques à valeur unique qui résument les performances globales
• Ventilation – métriques segmentées selon une ou plusieurs dimensions
• Ratio – métriques formées en divisant deux agrégats liés
• Classement – métriques classées au sein d'un groupe
• Cumulatif / Total courant – mesures qui s'accumulent au fil du temps
• Moyenne mobile – mesures lissées sur une fenêtre glissante
• Variation / croissance en pourcentage – mesures comparant les valeurs entre différentes périodes

Le regroupement des questions par modèle de métrique permet d'identifier plus facilement ce que les entretiens testent systématiquement : non pas la syntaxe ou des astuces SQL isolées, mais la capacité à définir, calculer et raisonner à partir de métriques commerciales.

Une explication complète du cadre, y compris des exemples et des pièges courants, est présentée dans l'article original : Exploration de l'ensemble de
données sur la croissance des ventes – Utilisation de la fiche de référence de l'analyste de données sur les données de vente réelles.

Une fois ce cadre mis en place, la section suivante indique la fréquence à laquelle chaque modèle de métrique est apparu au cours des entretiens.

Résultats : échantillon d'entretiens et répartition des questions

Cette analyse est basée sur 11 entretiens avec des analystes de données menés entre novembre 2023 et avril 2025, qui comprenaient des questions techniques sur le langage SQL. Seuls les entretiens comportant une évaluation explicite du langage SQL ont été pris en compte. Au cours de ces entretiens, plusieurs questions sur le langage SQL ont été posées, ce qui a permis d'obtenir un ensemble suffisamment large pour observer une répétition claire des types de mesures.

Répartition des entretiens par groupe d'entreprises

Les entretiens ont porté sur des entreprises de tailles et de domaines variés. Afin d'éviter de mettre trop l'accent sur certaines entreprises, les entretiens ont été regroupés par catégorie.

Nombre total d'entretiens : 11

Bien que l'échantillon soit limité et concentré géographiquement, la répétition des types de questions SQL dans différents groupes d'entreprises suggère que les modèles observés ne sont pas isolés à une seule catégorie.

Questions SQL par modèle métrique

Chaque question SQL a été classée à l'aide du cadre de modèles métriques SQL décrit précédemment. Le tableau ci-dessous montre la fréquence d'apparition de chaque modèle dans les entretiens.

La distribution montre une forte concentration dans un petit nombre de modèles métriques, les questions de type « Breakdown » (répartition) et « Ratio » (ratio) apparaissant beaucoup plus fréquemment que toutes les autres. Les métriques plus avancées basées sur le temps et les fenêtres sont rarement apparues dans cette série d'entretiens.

La section suivante interprète ces résultats et explique pourquoi certains modèles métriques dominent les entretiens SQL.

Interprétation : pourquoi certains modèles métriques dominent les entretiens SQL

La répartition des modèles métriques SQL dans ces entretiens montre une concentration claire autour des questions de ventilation et de ratio. Ce n'est pas un hasard. Ces deux modèles représentent la base de la manière dont les entreprises posent des questions analytiques et dont les analystes de données sont censés raisonner sur les performances.

Les questions de ventilation apparaissent le plus souvent car elles permettent de tester si un candidat est capable de passer d'une métrique de haut niveau à une vue segmentée. Dans la pratique, cela signifie comprendre comment définir le grain de données correct, appliquer des jointures sans gonfler les résultats et regrouper les métriques par dimensions pertinentes telles que le temps, la région, le produit ou le type d'utilisateur. Une requête de ventilation correcte démontre que le candidat comprend non seulement la syntaxe SQL, mais aussi le comportement des métriques lorsqu'elles sont découpées en dimensions.

Les questions de ratio apparaissent fréquemment pour des raisons similaires. Les ratios nécessitent un alignement minutieux entre le numérateur et le dénominateur, un filtrage cohérent et la prise en compte des cas limites tels que la division par zéro ou les données manquantes. Du point de vue de l'entretien, les mesures de ratio révèlent rapidement si un candidat comprend ce que représente une mesure ou s'il se contente d'agréger mécaniquement des colonnes. Même lorsque le SQL est relativement court, le raisonnement qui le sous-tend ne l'est souvent pas.

Les questions sur les KPI et les classements apparaissent moins fréquemment, mais restent régulières. Les KPI à valeur unique permettent de tester si un candidat est capable de définir clairement une métrique et de l'agréger correctement, tandis que les questions sur les classements introduisent les concepts d'ordonnancement et de partitionnement qui sont courants dans le reporting, mais secondaires par rapport à la construction des métriques de base.

Les modèles plus avancés, tels que les totaux cumulés, les moyennes mobiles et les variations en pourcentage, apparaissent beaucoup moins souvent dans cette série d'entretiens. Ces modèles s'appuient généralement sur des fonctions de fenêtre et une logique de séries chronologiques, qui sont des compétences importantes mais qui ne sont pas essentielles pour la plupart des tâches quotidiennes de reporting des analystes de données. Leur faible fréquence suggère que les entretiens privilégient l'exactitude et la clarté de la logique métrique fondamentale plutôt que les fonctionnalités SQL avancées.

Dans l'ensemble, la répartition des modèles indique que les entretiens SQL mettent l'accent sur la définition, la segmentation et la comparaison des métriques plutôt que sur la complexité syntaxique. Les recruteurs semblent utiliser le SQL comme un moyen d'évaluer la façon dont les candidats abordent les questions relatives aux données et à l'entreprise, et non le nombre de techniques SQL avancées qu'ils sont capables d'appliquer de manière isolée.

Conclusions

Cette analyse est basée sur un échantillon limité de 11 entretiens avec des analystes de données de la région de la baie de San Francisco, mais la concentration des types de questions était suffisamment cohérente pour faire ressortir des priorités claires.

Les questions de ventilation et de ratio ont dominé l'ensemble des entretiens. Il est préférable de consacrer le temps de préparation à bien maîtriser ces questions : définir les métriques à la bonne échelle, joindre les tables sans gonfler les résultats et regrouper les données d'une manière qui corresponde à la question commerciale. Ces compétences sont renforcées dans des cours fondamentaux axés sur le reporting, tels que SQL pour les débutants , Fonctions SQL standards et Création de rapports basiques en SQL sur LearnSQL.fr , où les requêtes sont formulées autour de métriques réelles plutôt que d'une syntaxe isolée.

Les modèles métriques avancés, tels que les totaux cumulés, les moyennes mobiles ou les calculs de croissance, sont beaucoup moins fréquents. Ils constituent des ajouts utiles, en particulier pour les rôles impliquant beaucoup de reporting, mais ils ne remplacent pas de solides bases fondamentales. Les cours couvrant des sujets tels que Fonctions de fenêtrage , Requêtes récursives et SQL GROUP BY Extensions sur LearnSQL.fr sont particulièrement utiles une fois que les modèles de ventilation et de ratio sont déjà bien maîtrisés.

Dans l'ensemble, les résultats suggèrent que les entretiens SQL récompensent davantage la clarté du raisonnement métrique que l'étendue des fonctionnalités SQL. Une préparation qui met l'accent sur la construction de métriques de base et l'utilisation correcte des jointures correspond le mieux à ce qui apparaît dans les questions réelles des entretiens.

Conclusion

Cet article a analysé les questions d'entretien SQL issues de 11 entretiens réels avec des analystes de données afin d'identifier les modèles métriques les plus fréquents dans la pratique. Plutôt que de se concentrer sur des techniques SQL isolées, l'analyse a regroupé les questions par type de métrique calculée, révélant une nette concentration autour des modèles de ventilation et de ratio dans toutes les entreprises et tous les formats d'entretien.

Les résultats suggèrent que les entretiens SQL mettent systématiquement l'accent sur la construction des métriques et la logique de reporting plutôt que sur les fonctionnalités SQL avancées. Les recruteurs semblent utiliser ces questions pour évaluer si les candidats sont capables de définir correctement les métriques, de les segmenter de manière significative et de raisonner sur les comparaisons d'une manière qui reflète le travail analytique réel.

Le cadre SQL Metric Pattern et la fiche de référence pour les analystes de données offrent une approche structurée de ces problèmes en combinant la technique SQL, la définition des métriques et le contexte commercial. Pour les candidats qui souhaitent mettre en pratique ces compétences à plusieurs reprises sur différents ensembles de données et niveaux de difficulté, il est plus important d'avoir accès à un ensemble de cours structuré et complet que de passer d'une ressource à l'autre sans lien entre elles. C'est là qu'une option telle que le plan SQL de l'Tout à vie trouve tout naturellement sa place, car elle permet de s'exercer à long terme sur des modèles métriques fondamentaux et avancés sans avoir à optimiser le choix des cours individuels.

Cet article se concentre délibérément sur les modèles de base plutôt que sur la stratégie d'entretien. Une analyse plus approfondie pourrait décomposer davantage les questions en fonction du format des tests ou explorer les sous-modèles courants au sein de chaque type de métrique, mais les conclusions présentées ici indiquent déjà clairement que la maîtrise de la logique métrique fondamentale offre le meilleur retour sur investissement pour la préparation aux entretiens SQL.