Entraînement entretien system design — en solo, avec feedback IA

Le system design est le tour où les bons ingénieurs sous-performent et où les ingénieurs moyens marquent parfois un coup de circuit, parce que la barre n'est pas « connaissez-vous la réponse » — c'est « savez-vous raisonner à voix haute sur un problème flou, sous pression temporelle ». Cela se travaille. Les entretiens blancs IA vous offrent la combinaison rare de répétitions illimitées et d'un feedback cohérent et structuré.

Ce qui est vraiment noté dans un tour de system design

Les candidats supposent que la note porte sur « avez-vous conçu le bon système ». Ce n'est pas le cas. Les vrais recruteurs notent cinq choses, et elles sont faiblement corrélées entre elles. Premièrement : avez-vous clarifié le problème avant de concevoir — concrètement, avez-vous posé des questions sur l'échelle, le ratio lecture/écriture, les exigences de latence et les contraintes. Deuxièmement : avez-vous fait des calculs de coin de table, ou avez-vous agité « beaucoup de trafic » sans chiffres. Troisièmement : avez-vous proposé une API et un modèle de données avant de dessiner des boîtes. Quatrièmement : avez-vous conçu une architecture qui colle aux exigences que vous venez de définir — pas une architecture générique. Cinquièmement : êtes-vous allé en profondeur sur au moins un composant et avez-vous articulé les tradeoffs, ou êtes-vous resté en surface pendant une heure.

La plupart des candidats échouent sur le n°1 et le n°5. Ils commencent à dessiner tout de suite parce que ça donne l'impression d'être productif, et ils restent au niveau « boîtes et flèches » pendant toute l'heure sans jamais défendre un seul choix. La solution est structurelle : suivez un framework, sur chaque problème, jusqu'à ce que le framework devienne automatique.

Le framework : six phases, sur chaque problème

Utilisez-le sur chaque design, y compris ceux qui semblent faciles. Il est plus lent les trois premières fois et plus rapide pour toujours ensuite.

1. Clarifier (5 min). Exigences fonctionnelles — que fait le système, que ne fait-il pas. Non fonctionnelles — échelle, latence, disponibilité, cohérence. Contraintes — budget, équipe, réglementation. Confirmez le périmètre avant de concevoir. Le recruteur ne vous donnera parfois aucun périmètre, exprès, pour voir si vous demandez.
2. Estimer (5 min). Utilisateurs, QPS, stockage, bande passante. Notez les chiffres (à voix haute, puisque vous parlez). 100M DAU, 10 lectures par utilisateur et par jour, un split lecture/écriture 80/20 — cela fait environ 12K QPS en lecture, 3K QPS en écriture. Vous n'avez pas besoin d'avoir raison ; vous avez besoin d'être plausible.
3. API (5 min). Définissez les 3 à 5 endpoints les plus importants. Méthode, chemin, paramètres, forme de la réponse. Cette étape compte plus que les candidats ne l'imaginent, parce qu'elle vous force à nommer vos noms. « POST /shorten » avec un corps {url, custom_alias?} est plus concret qu'agiter « le service d'URL ».
4. Modèle de données (5 min). Tables ou schémas de documents, clés, index. Énoncez votre choix de data store (Postgres, DynamoDB, Cassandra) et défendez-le en une phrase. Le choix fait partie du modèle de données — pas une décision séparée pour plus tard.
5. Architecture (15 min). Maintenant vous dessinez des boîtes. Client, load balancer, API gateway, services, caches, message queues, bases de données. Parcourez le chemin de lecture et le chemin d'écriture séparément. N'essayez pas de dessiner le diagramme parfait au premier passage — esquissez-le, puis ajoutez des boîtes à mesure que vous découvrez que vous en avez besoin.
6. Deep dive + tradeoffs (15 min). Le recruteur dira « allons en profondeur sur X ». Ou il ne le dira pas, et vous devriez le proposer. Choisissez le composant le plus intéressant et expliquez en détail comment il fonctionne — stratégie de réplication, politique d'éviction, approche de scaling. Terminez par des tradeoffs explicites : « nous avons choisi la cohérence à terme parce que le cas d'usage tolère 30 secondes de staleness et que l'alternative était un coût multiplié par 3 ».

Designs courants à répéter par cœur

URL shortener

Le design trompeusement facile. Le système est simple — générer un ID court, stocker le mapping, rediriger à la consultation. L'entretien est difficile parce que le recruteur vous pousse sur chaque détail. Comment générez-vous les IDs ? (Aléatoire vs incrémental vs hash base62 — chacun a ses tradeoffs.) Quelle base de données ? (Un KV store comme Redis pour les lectures chaudes, du relationnel pour l'analytics.) Comment gérez-vous les collisions ? (Réessai avec un ID plus long, ou pré-allocation d'un pool par nœud.) Quel est le ratio lecture/écriture ? (100:1 au minimum — concevez pour la lecture intensive.) Stratégie de caching ? Read-through avec un TTL élevé puisque les URLs changent rarement. Ce design couvre peut-être 40 % des sujets qui apparaissent aussi dans les autres designs.

Fil social (style Twitter)

Le fan-out est la question canonique. Push (écrire le tweet → l'écrire dans toutes les timelines des followers) vs pull (écrire le tweet → lire depuis la liste des following au moment de la requête). Le push optimise la latence de lecture au prix d'une amplification en écriture — mauvais pour les comptes de célébrités avec 10M de followers. Le pull optimise le coût d'écriture — mauvais pour les utilisateurs avec des milliers de following. La réponse du monde réel est hybride : push pour les utilisateurs normaux, pull pour les célébrités. Soyez prêt à expliquer quel seuil vous choisiriez (par exemple, un nombre de followers > 10K déclenche le comportement pull) et pourquoi.

Système de chat

Trois sous-systèmes intéressants : le stockage des messages, la livraison et la présence. Stockage : partitionner par ID de conversation, stocker les messages dans des logs en append-only, archiver les conversations froides. Livraison : une connexion websocket par utilisateur actif, une message queue pour la livraison hors ligne, des push notifications pour le mobile. Présence : éphémère, basée sur des heartbeats, cohérente à terme. Le recruteur poussera sur l'ordre des messages (causal ? total ? un ordre total par conversation suffit généralement) et sur les garanties de livraison (at-least-once est le défaut — gérez la déduplication côté client).

Utiliser les entretiens blancs IA spécifiquement pour le system design

Choisissez le mode « Full Interview » et dites à l'IA que vous voulez un tour de system design, pas un screening. Précisez le design (« URL shortener », « fil Instagram ») ou laissez-la choisir. Déroulez le framework à voix haute — décrivez ce que vous dessineriez, parcourez le chemin de lecture, expliquez les tradeoffs au fur et à mesure que vous les faites. L'IA enchaînera avec le même genre de questions qu'un vrai recruteur pose : « que se passe-t-il si le cache tombe ? », « comment gérez-vous une hot key ? », « quelle est votre stratégie de réplication et quel est le mode de défaillance ? ». Répondez en phrases complètes avec des tradeoffs explicites, parce que c'est ainsi que le vrai tour est noté.

Une astuce précise : dites à l'IA de jouer le rôle d'un recruteur senior dans un FAANG. Elle poussera plus fort sur les hypothèses et refusera d'accepter des réponses génériques. C'est le réglage au plus fort levier pour les candidats Senior et au-delà, parce que vous avez besoin de vous entraîner à défendre vos choix face aux objections, pas seulement à les énoncer.

Ce que le feedback IA ne détectera pas (et quoi y faire)

Le feedback IA est excellent sur la structure, l'articulation des tradeoffs et les composants manquants. Il est plus faible sur la qualité du diagramme (vous décrivez, vous ne dessinez pas) et sur le réalisme de vos estimations chiffrées pour l'échelle propre à l'entreprise visée. Atténuez cela en faisant une ou deux sessions avec un vrai tableau blanc — ouvrez excalidraw sur un second écran et dessinez pendant que vous parlez. Associez les entretiens blancs IA à un ou deux tours avec un pair ou un coach dans la dernière semaine avant le vrai entretien, surtout si vous visez Staff ou Principal.

Pour les parties où l'IA excelle : la structure et l'articulation des tradeoffs. Relisez le feedback noté après chaque session et notez deux changements concrets pour la suivante. Deux changements par session se cumulent vite — trois sessions et vous serez mesurablement plus structuré que 80 % des candidats qui entrent dans la salle.

Questions fréquentes