Guide recrutement data
Test technique BigQuery : ce qu'on évalue vraiment en entretien
BigQuery paraît simple : du SQL sur des Po de données. Mais l'écart est immense entre lancer un SELECT * qui coûte une fortune et concevoir un entrepôt partitionné, clustéré et optimisé au coût. Voici ce qu'on évalue.
Data Builder·Juillet 2025·10 min de lecture·Data Engineer / Analytics Engineer
La particularité de BigQuery, c'est le modèle de coût : on paie les octets scannés, pas le temps. Un profil solide raisonne en volume lu avant d'écrire une requête. Cinq dimensions.
1Modèle de coût
Question discriminante
Qu'est-ce qui détermine le coût d'une requête BigQuery, et comment le réduire ?
- On paie les octets scannés, pas la durée : réduire la donnée lue est la clé.
- Sélectionner les colonnes utiles (jamais
SELECT * sur une large table). - Filtrer sur la colonne de partition pour ne lire que les partitions nécessaires.
- On-demand (par To scanné) vs slots réservés (capacité fixe).
Signal d'alerte : un SELECT * sur une table de plusieurs To sans filtre de partition est une erreur qui se voit directement sur la facture.
2Partitionnement et clustering
Question discriminante
Comment optimisez-vous une table de faits volumineuse et souvent filtrée ?
- Partitionner par date (ingestion ou colonne) pour le partition pruning.
- Clustering sur les colonnes de filtre/jointure fréquentes.
- Expiration de partition pour maîtriser le stockage.
- Vérifier l'estimation d'octets scannés avant de lancer une requête lourde.
3ARRAY, STRUCT et UNNEST
Question discriminante
Comment interrogez-vous des données imbriquées ou répétées (tableaux, structs) ?
SELECT tag, COUNT(*) AS n
FROM articles, UNNEST(SPLIT(tags, '|')) AS tag
GROUP BY tag
ARRAY et STRUCT — le modèle imbriqué natif de BigQuery.UNNEST pour aplatir un tableau en lignes.SPLIT + UNNEST pour éclater une chaîne délimitée.- Comprendre le coût d'un déplilement mal maîtrisé (explosion des lignes).
4Fonctions fenêtre et QUALIFY
Question discriminante
Comment gardez-vous la dernière ligne par entité, sans sous-requête ?
SELECT * FROM events
QUALIFY ROW_NUMBER() OVER (
PARTITION BY user_id ORDER BY ts DESC) = 1
QUALIFY natif — filtrer sur une fonction fenêtre directement.- Classements, cumuls,
LAG/LEAD comme en SQL standard. - Fonctions
APPROX_* (quantiles, count distinct) à grande échelle. DATE_TRUNC/TIMESTAMP_TRUNC pour les séries temporelles, avec fuseau.
5Optimisation et bonnes pratiques
Question discriminante
Une requête est lente ou chère. Par quoi commencez-vous ?
- Lire le plan d'exécution et l'estimation d'octets.
- Vues matérialisées pour des agrégats récurrents.
- BI Engine / cache de résultats pour les requêtes répétées.
- Éviter les jointures explosives et les
CROSS JOIN non maîtrisés.
6Grille par niveau
| Niveau | Maîtrise attendue | Signal GO | NO-GO |
|---|
| Junior | SQL sur BigQuery, colonnes utiles, filtres | Évite SELECT *, comprend le coût par octets scannés | Lance un SELECT * sur une grosse table sans filtre |
| Confirmé | Partitionnement, clustering, UNNEST, QUALIFY | Partitionne/clustérise, interroge des données imbriquées | Ne sait pas ce qu'est le partition pruning |
| Senior | Optimisation coût, vues matérialisées, slots | Diagnostique une requête chère, arbitre on-demand/slots | Ne peut pas expliquer d'où vient une facture élevée |
| Lead | Architecture d'entrepôt, gouvernance des coûts | Définit les standards de partitionnement et de coûts | Ne met aucune garde-fou de coût à l'échelle |
Data hiring guide
BigQuery technical interview: what we really assess
BigQuery looks simple: SQL over petabytes. But the gap is huge between running a SELECT * that costs a fortune and designing a partitioned, clustered, cost-optimized warehouse. Here's what we assess.
Data Builder·July 2025·10 min read·Data Engineer / Analytics Engineer
BigQuery's specificity is its cost model: you pay for bytes scanned, not time. A strong profile reasons in data read before writing a query. Five dimensions.
1Cost model
Key question
What determines the cost of a BigQuery query, and how do you reduce it?
- You pay for bytes scanned, not duration: reducing data read is the key.
- Select only useful columns (never
SELECT * on a wide table). - Filter on the partition column to read only the needed partitions.
- On-demand (per TB scanned) vs reserved slots (fixed capacity).
Warning signal : a SELECT * on a multi-TB table with no partition filter is a mistake that shows up directly on the bill.
2Partitioning and clustering
Key question
How do you optimize a large, frequently filtered fact table?
- Partition by date (ingestion or column) for partition pruning.
- Clustering on frequently filtered/joined columns.
- Partition expiration to control storage.
- Check the scanned-bytes estimate before running a heavy query.
3ARRAY, STRUCT and UNNEST
Key question
How do you query nested or repeated data (arrays, structs)?
SELECT tag, COUNT(*) AS n
FROM articles, UNNEST(SPLIT(tags, '|')) AS tag
GROUP BY tag
ARRAY and STRUCT — BigQuery's native nested model.UNNEST to flatten an array into rows.SPLIT + UNNEST to explode a delimited string.- Understanding the cost of an uncontrolled unnest (row explosion).
4Window functions and QUALIFY
Key question
How do you keep the latest row per entity, without a subquery?
SELECT * FROM events
QUALIFY ROW_NUMBER() OVER (
PARTITION BY user_id ORDER BY ts DESC) = 1
- Native
QUALIFY — filter on a window function directly. - Rankings, running totals,
LAG/LEAD as in standard SQL. APPROX_* functions (quantiles, distinct count) at scale.DATE_TRUNC/TIMESTAMP_TRUNC for time series, with time zone.
5Optimization and best practices
Key question
A query is slow or expensive. Where do you start?
- Read the execution plan and byte estimate.
- Materialized views for recurring aggregates.
- BI Engine / result cache for repeated queries.
- Avoid explosive joins and uncontrolled
CROSS JOINs.
6Level grid
| Level | Expected proficiency | Signal GO | NO-GO |
|---|
| Junior | SQL on BigQuery, useful columns, filters | Avoids SELECT *, understands cost per bytes scanned | Runs SELECT * on a big table with no filter |
| Mid-level | Partitioning, clustering, UNNEST, QUALIFY | Partitions/clusters, queries nested data | Doesn't know what partition pruning is |
| Senior | Cost optimization, materialized views, slots | Diagnoses a costly query, balances on-demand/slots | Can't explain where a high bill comes from |
| Lead | Warehouse architecture, cost governance | Sets partitioning and cost standards | Puts no cost guardrails at scale |