Accueil›Blog›Test SQL senior

Tests prêts à l'emploi

Test SQL senior : un cas de modélisation + optimisation à donner en entretien

Pour un profil senior, écrire une requête ne suffit pas : il faut savoir modéliser et optimiser. Ce cas en deux parties, à donner en entretien (30-40 min), révèle la capacité d'arbitrage d'un candidat expérimenté. Corrigé et grille inclus.

Data Builder·Juillet 2025·11 min de lecture·Test SQL · niveau senior · entretien

Sommaire

Le point de départ : une table dénormalisée
Partie 1 — Modéliser proprement
Partie 2 — Optimiser une requête lente
Grille par niveau

On n'attend pas une réponse unique mais un raisonnement : quels compromis, pourquoi, à quel coût. Un senior justifie ses choix ; un junior déguisé applique des recettes sans les relier au contexte.

1Le point de départ : une table dénormalisée

La consigne

Donnez cette table au candidat.

On part d'une seule grande table où tout est répété (le nom du client, son pays, le nom du produit reviennent à chaque ligne de commande). C'est le point de départ classique d'un cas de modélisation.

-- Table de depart (tout dans une seule table)
ventes_brutes(
  commande_id, date_commande, statut,
  client_nom, client_pays, client_email,
  produit_nom, produit_categorie, produit_prix,
  quantite, montant
)

2Partie 1 — Modéliser proprement

La consigne

Proposez un schéma normalisé (ou en étoile) et justifiez vos choix.

On demande au candidat de découper cette table en un modèle propre et d'expliquer les compromis. Un bon senior propose un schéma en étoile (une table de faits, des dimensions) et sait dire pourquoi.

-- Corrige : schema en etoile (orientation analytique)
dim_clients(id, nom, email, pays)
dim_produits(id, nom, categorie, prix)
fait_commandes(
  id, date_commande, statut,
  client_id  -> dim_clients(id),
  produit_id -> dim_produits(id),
  quantite, montant
)
-- La table de faits ne garde que des cles + mesures ;
-- les libelles vivent dans les dimensions (une seule source de verite).

Attendu : séparer les dimensions (clients, produits) de la table de faits (commandes).
Attendu : justifier normalisation vs schéma en étoile selon l'usage (analytique).
Bon signe : le candidat parle de cohérence, de doublons évités et de performance de lecture.

Signal d'alerte : ce qu'on évalue : pas le schéma « parfait », mais la capacité à arbitrer (normaliser pour la cohérence vs dénormaliser pour la vitesse de lecture) et à relier ce choix à l'usage réel.

3Partie 2 — Optimiser une requête lente

La consigne

Cette requête d'agrégation est lente sur des millions de lignes. Comment l'améliorer ?

On soumet une requête réaliste mais mal écrite. Un senior identifie les anti-patterns et propose des pistes concrètes (index, éviter les fonctions sur colonnes filtrées, pré-agrégation).

-- Requete lente (anti-pattern)
SELECT client_id, SUM(montant)
FROM fait_commandes
WHERE YEAR(date_commande) = 2024   -- fonction sur colonne = pas d'index
GROUP BY client_id;

-- Corrige : filtre par plage (l'index sur date_commande est utilisable)
SELECT client_id, SUM(montant)
FROM fait_commandes
WHERE date_commande >= '2024-01-01'
  AND date_commande <  '2025-01-01'
GROUP BY client_id;
-- + index sur (date_commande, client_id) ; envisager une table pre-agregee
--   si cette requete tourne souvent.

Attendu : repérer le filtre par fonction sur la date qui empêche l'usage d'un index.
Attendu : proposer un filtre par plage de dates, un index adapté, voire une pré-agrégation.
Bon signe : le candidat veut d'abord lire le plan d'exécution avant d'optimiser à l'aveugle.

Signal d'alerte : le vrai marqueur senior : commencer par « je regarde le plan d'exécution », pas appliquer des optimisations au hasard. La démarche compte autant que la solution.

4Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Sait écrire des requêtes	Découpe la table en dimensions/faits	Ne voit pas le problème de la table unique
Confirmé	Modélise correctement	Justifie normalisation vs étoile	Modélise sans expliquer les compromis
Senior	Optimise avec méthode	Lit le plan, repère les anti-patterns	Optimise au hasard sans diagnostic
Lead	Arbitre selon le contexte	Relie chaque choix au coût et à l'usage	Applique des recettes hors contexte

Home›Blog›Senior SQL test

Ready-to-use tests

Senior SQL test: a modelling + optimization case to give in an interview

For a senior profile, writing a query isn't enough: you must model and optimize. This two-part case, to give in an interview (30-40 min), reveals an experienced candidate's ability to make trade-offs. Answer and grid included.

Data Builder·July 2025·11 min read·SQL test · senior level · interview

Contents

The starting point: a denormalized table
Part 1 — Model it cleanly
Part 2 — Optimize a slow query
Level grid

A single answer isn't expected but a reasoning: which trade-offs, why, at what cost. A senior justifies their choices; a disguised junior applies recipes without tying them to the context.

1The starting point: a denormalized table

The task

Give this table to the candidate.

We start from one big table where everything is repeated (the customer's name, country, product name recur on every order line). It's the classic starting point of a modelling case.

-- Table de depart (tout dans une seule table)
ventes_brutes(
  commande_id, date_commande, statut,
  client_nom, client_pays, client_email,
  produit_nom, produit_categorie, produit_prix,
  quantite, montant
)

2Part 1 — Model it cleanly

The task

Propose a normalized (or star) schema and justify your choices.

The candidate is asked to split this table into a clean model and explain the trade-offs. A good senior proposes a star schema (one fact table, dimensions) and can say why.

-- Corrige : schema en etoile (orientation analytique)
dim_clients(id, nom, email, pays)
dim_produits(id, nom, categorie, prix)
fait_commandes(
  id, date_commande, statut,
  client_id  -> dim_clients(id),
  produit_id -> dim_produits(id),
  quantite, montant
)
-- La table de faits ne garde que des cles + mesures ;
-- les libelles vivent dans les dimensions (une seule source de verite).

Expected: separate the dimensions (customers, products) from the fact table (orders).
Expected: justify normalization vs star schema depending on use (analytical).
Good sign: the candidate mentions consistency, avoided duplicates and read performance.

Warning signal : what we assess: not the ‘perfect’ schema, but the ability to trade off (normalize for consistency vs denormalize for read speed) and tie the choice to the real use.

3Part 2 — Optimize a slow query

The task

This aggregation query is slow on millions of rows. How would you improve it?

We submit a realistic but poorly written query. A senior identifies the anti-patterns and proposes concrete leads (indexes, avoiding functions on filtered columns, pre-aggregation).

-- Requete lente (anti-pattern)
SELECT client_id, SUM(montant)
FROM fait_commandes
WHERE YEAR(date_commande) = 2024   -- fonction sur colonne = pas d'index
GROUP BY client_id;

-- Corrige : filtre par plage (l'index sur date_commande est utilisable)
SELECT client_id, SUM(montant)
FROM fait_commandes
WHERE date_commande >= '2024-01-01'
  AND date_commande <  '2025-01-01'
GROUP BY client_id;
-- + index sur (date_commande, client_id) ; envisager une table pre-agregee
--   si cette requete tourne souvent.

Expected: spot the function-on-date filter that prevents index usage.
Expected: propose a date-range filter, a suitable index, even a pre-aggregation.
Good sign: the candidate wants to read the execution plan first before optimizing blindly.

Warning signal : the real senior marker: starting with ‘I look at the execution plan’, not applying random optimizations. The approach matters as much as the solution.

4Level grid

Level	Expected proficiency	Signal GO	NO-GO
Junior	Can write queries	Splits the table into dimensions/facts	Doesn't see the single-table problem
Mid-level	Models correctly	Justifies normalization vs star	Models without explaining trade-offs
Senior	Optimizes methodically	Reads the plan, spots anti-patterns	Optimizes randomly with no diagnosis
Lead	Trades off by context	Ties each choice to cost and use	Applies recipes out of context

Test SQL senior : un cas de modélisation + optimisation à donner en entretien

1Le point de départ : une table dénormalisée

2Partie 1 — Modéliser proprement

3Partie 2 — Optimiser une requête lente

4Grille par niveau

Senior SQL test: a modelling + optimization case to give in an interview

1The starting point: a denormalized table

2Part 1 — Model it cleanly

3Part 2 — Optimize a slow query

4Level grid

Vous recrutez un profil data ?