Parlons des entretiens (partie 2) 😎

Dans le post précédent, nous avons abordé les soft skills, la méthode STAR et Excel. C'est l'ensemble de base. Maintenant, allons plus loin, SQL.

Si vous maîtrisez bien Excel, vous comprenez déjà les bases : comment les données sont liées, quels problèmes surviennent lors des jointures, comment fonctionnent les regroupements. La transition vers SQL au début se résume essentiellement à 5 commandes : SELECT, FROM, WHERE, JOIN, GROUP BY. Les fonctions de fenêtrage et les tables temporaires sont utiles, mais pas critiques au début.

Et maintenant, passons à l'essentiel. Le problème principal n'est pas la syntaxe. Le problème réside dans les blocs qui ne font pas échouer la requête. Le code s'exécute, l'interpréteur reste silencieux, mais le résultat n'est pas celui attendu par l'intervieweur. C'est là que beaucoup échouent.

1️⃣NOT IN + NULL : silence au lieu de données

En SQL : NULL ≠ vide ≠ 0. Ceux qui ont étudié Python savent : zéro est zéro, NULL est le vide, rien. Gardez cela en tête.

Problème : trouver les utilisateurs qui ne sont pas dans la liste noire.

❌
SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM blocked)

Apparemment, tout est correct. Mais si dans blocked il y a au moins une ligne avec user_id = NULL, le résultat est 0 lignes. SQL ne peut pas comparer avec NULL et retourne silencieusement le vide.

✅
SELECT * FROM users u
WHERE NOT EXISTS (
SELECT 1 FROM blocked b
WHERE b.user_id = u.id
)

D'ailleurs, NOT EXISTS est aussi plus rapide : il prend l'id, va dans la deuxième table, trouve la première occurrence, s'arrête. NOT IN parcourt la table entièrement de haut en bas. Sur les grandes tables, la différence est notable.

2️⃣ LEFT JOIN qui devient silencieusement INNER JOIN

Nous détaillerons les types de JOIN dans les prochains posts de la série. Pour l'instant, seulement l'essence du piège.
❌
SELECT c.name, o.amount
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'completed'

Ce qui se passe : WHERE tue les lignes NULL de la table de droite. Les clients sans commandes disparaissent simplement. LEFT JOIN se transforme en INNER JOIN. Et le résultat est à côté.
✅
SELECT c.name, o.amount
FROM customers c
LEFT JOIN orders o
ON c.id = o.customer_id
AND o.status = 'completed'

Une seule ligne avec AND. La différence est fondamentale.

3️⃣AVG ment joliment

Voici un petit problème. 10 lignes de ventes. Trois ont NULL. Que retourne AVG ? La moyenne sur 7, pas sur 10. Si les valeurs semblent plausibles, le piège est difficile à remarquer. Le chiffre est réaliste, mais faussé.
❌
SELECT AVG(salary) FROM employees


✅
SELECT AVG(COALESCE(salary, 0)) FROM employees

COALESCE : rencontre NULL, le remplace par 0. On peut aussi s'en passer, mais alors expliquez à l'intervieweur que vous comprenez le comportement de AVG et que vous l'acceptez consciemment. Les deux options seront acceptées 👌

4️⃣Ordre d'exécution : le piège principal

On écrit : SELECT → FROM → WHERE → GROUP BY.
Exécuté : FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.

Pas logique ? Et comment 🤷‍♀️

❌
SELECT category, AVG(sales) AS avg_sales
FROM orders
WHERE avg_sales > 1000
GROUP BY category

L'alias avg_sales n'existe pas encore à l'étape WHERE. Le système ne connaît tout simplement pas ce champ.

✅
SELECT category, AVG(sales) AS avg_sales
FROM orders
GROUP BY category
HAVING AVG(sales) > 1000

HAVING est un filtrage après le regroupement. Nous détaillerons cela dans un post séparé de la série.

5️⃣Vous avez oublié la syntaxe ? Ne paniquez pas

Ça arrive : le stress, vous n'avez pas touché au sujet depuis longtemps. Eh bien, ça arrive à tout le monde. Dites-le franchement : « Je comprends la logique, je peux décrire les étapes. La syntaxe exacte, je la googlerais ». Tout professionnel sensé appréciera cela. Comprendre la logique est une chose. Googler une fonction = 30 secondes.

Bonus pour finir : la première question lors d'un test = « Quel SGBD utilisez-vous ? ».
DATE_TRUNC — PostgreSQL. DATE_FORMAT — MySQL. Une requête correcte pour une mauvaise base = une erreur pour rien.

Dans le prochain post SQL : Rétention et cohortes. Et demain, un post et un article sur le cas de mon équipe avec la société Grand-Alpha. Ils travaillent dans l'alimentation animale.

Question pour vous. Avez-vous déjà eu cela, oublier la réponse et ne pas vous en souvenir, même en vous tuant ? Comment avez-vous agi dans cette situation ? 👇

#sql
@data_dzen