Le system design interview est un entretien sans code, de 45 à 90 minutes, où le candidat conçoit l'architecture d'un système à partir d'un énoncé volontairement flou. C'est l'étape la plus discriminante pour les profils seniors, staff et principal, car elle évalue la prise de décision architecturale sous contraintes. Ce guide détaille le protocole, la grille de calibration par niveau et les red flags à repérer.
Qu'est-ce qu'un system design interview ?
Un system design interview est un exercice où le candidat conçoit, sur un tableau blanc physique ou numérique, l'architecture d'un système répondant à un besoin volontairement sous-spécifié : « Concevez un raccourcisseur d'URL », « Concevez un fil d'actualité type réseau social », « Concevez un cache distribué ». Aucun code n'est écrit : on évalue la pensée systémique, pas la syntaxe.
Là où le live coding mesure la capacité à écrire du code propre, le system design mesure la capacité à arbitrer entre des contraintes contradictoires : cohérence contre disponibilité, coût contre performance, simplicité contre extensibilité. C'est précisément cet arbitrage qui sépare un ingénieur confirmé d'un véritable senior.
Pourquoi cette étape révèle la séniorité
Le system design révèle la séniorité parce qu'il n'a pas de réponse unique : la qualité d'un candidat se lit dans la justification de ses choix, pas dans une solution « correcte ». Un junior cherche la bonne réponse ; un senior expose plusieurs options, leurs compromis, et choisit en fonction du contexte business.
L'exercice met en lumière trois choses que les autres étapes captent mal : la capacité à raisonner sous incertitude, la maturité à dimensionner sans sur-architecturer, et l'aptitude à communiquer une vision technique à des interlocuteurs variés. Pour recruter un CTO ou un profil principal ou staff, c'est souvent l'étape la plus déterminante du process.
Le format standard
Le format standard dure 45 à 90 minutes selon le niveau visé, sans code, autour d'un tableau blanc partagé (Excalidraw, Miro ou un tableau physique). L'énoncé est volontairement flou pour observer comment le candidat structure l'ambiguïté : un bon candidat transforme une question vague en un périmètre clair avant de dessiner quoi que ce soit.
L'évaluateur joue un rôle actif : il challenge, introduit de nouvelles contraintes en cours de route (« et si le trafic est multiplié par cent ? »), et observe la capacité du candidat à faire évoluer son design sans tout reconstruire.
Les 5 phases d'un bon system design
Un system design bien mené suit cinq phases chronométrées. La standardisation de ces phases pour tous les candidats d'un même poste est ce qui rend les évaluations comparables et la décision défendable.
- Clarification (5 à 10 min) : exigences fonctionnelles et non fonctionnelles, contraintes, périmètre. Un senior pose une série de questions ciblées avant de dessiner ; se lancer immédiatement est un signal de manque de maturité.
- Estimation d'ordres de grandeur (5 min) : utilisateurs actifs, volume de requêtes, stockage, bande passante. Pas besoin de précision : on cherche la capacité à raisonner en ordres de grandeur.
- Design haut niveau (15 à 20 min) : composants principaux, APIs, modèle de données grossier, flux de données entre services.
- Deep dive (20 à 30 min) : zoom sur un ou deux composants critiques. C'est là qu'on discute les vrais trade-offs : cohérence contre disponibilité, stratégie de sharding, politique de cache, gestion de la file de messages.
- Goulots et montée en charge (10 à 15 min) : identifier les points de rupture, anticiper les modes de défaillance, proposer des évolutions réalistes.
Ce que vous cherchez vraiment
Ce que vous cherchez dans un system design n'est pas une architecture parfaite, mais un mode de raisonnement. Quatre comportements distinguent les bons candidats des autres.
- Des questions intelligentes en phase de clarification : un candidat qui conçoit avant de comprendre le besoin se disqualifie de lui-même.
- L'expression explicite des trade-offs : « l'option A apporte ceci au prix de cela, l'option B l'inverse ; selon le contexte, je choisirais… ».
- Le pragmatisme : ne pas dégainer une architecture de géant pour un service modeste. Un senior commence simple et fait évoluer quand la contrainte apparaît.
- La gestion des modes de défaillance : que se passe-t-il si le cache tombe ? si le réseau se partitionne ? si un service est saturé ?
Les red flags à repérer
Certains comportements signalent un niveau de séniorité inférieur à celui affiché sur le CV. Ils ne sont pas éliminatoires isolément, mais leur accumulation doit alerter.
- Sauter la phase de clarification et concevoir dans le vide.
- Empiler les buzzwords (microservices, Kubernetes, event sourcing) sans pouvoir en justifier l'usage dans le contexte.
- Être incapable d'estimer des ordres de grandeur, même approximatifs.
- Figer ses choix et refuser de les reconsidérer quand l'évaluateur les challenge.
- Sur-architecturer un système qui n'en a pas besoin, au détriment de la maintenabilité.
La grille de notation et la calibration par niveau
La grille de notation repose sur quatre axes notés sur 5, et le seuil attendu varie selon le niveau visé. Cette calibration explicite est indispensable pour comparer équitablement un senior et un principal sur le même exercice.
| Axe évalué | Senior (seuil) | Staff / Principal (seuil) |
|---|---|---|
| Clarification du besoin | ≥ 3/5 | ≥ 4/5 |
| Design haut niveau | ≥ 3/5 | ≥ 4/5 |
| Deep dive technique | ≥ 3/5 | ≥ 4/5 |
| Communication et arbitrage | ≥ 3/5 | ≥ 4/5 |
Adaptez aussi le problème au niveau. Pour un senior : raccourcisseur d'URL, système de chat, partage de fichiers. Pour un staff : fil d'actualité à grande échelle, système de paiement, streaming vidéo. Pour un principal : coordinateur de transactions distribuées, CDN global, courtier de messages.
Former vos interviewers
Un interviewer mal calibré est aussi problématique qu'un mauvais candidat : il valorise les choix qu'il connaît et pénalise les approches valides qu'il ne maîtrise pas. La formation des évaluateurs est donc non négociable.
Faites lire à vos interviewers des références communes, par exemple Designing Data-Intensive Applications de Martin Kleppmann, et organisez des sessions d'étalonnage où plusieurs évaluateurs notent le même candidat fictif, puis comparent. L'objectif est de réduire l'écart inter-juges avant de mettre l'étape en production. Ce type de calibration s'applique aussi aux postes voisins comme le SRE.
FAQ, System design interview
Faut-il faire un system design pour un profil junior ?
Non, c'est généralement inadapté. Un junior n'a pas encore l'expérience opérationnelle pour arbitrer des trade-offs d'architecture, et l'exercice ne ferait que mesurer ses lectures théoriques. Réservez le system design aux profils confirmés, seniors et au-delà ; pour un junior, un exercice de code reste plus pertinent.
Combien de temps doit durer un system design ?
Comptez 45 minutes pour un senior et jusqu'à 90 minutes pour un staff ou principal. Un format trop court empêche le deep dive, là où se révèle la vraie profondeur technique. Un format trop long fatigue le candidat sans ajouter de signal : l'essentiel se joue dans les arbitrages, pas dans l'exhaustivité.
Le candidat doit-il aboutir à une architecture complète ?
Non. Un design « fini » mais non justifié vaut moins qu'un design partiel dont chaque choix est argumenté. On évalue le raisonnement, les trade-offs explicités et la capacité à faire évoluer la solution sous contrainte, pas la quantité de composants dessinés sur le tableau.
Professionnalisez vos entretiens d'architecture avec Rocket4RPO
Recruter un senior ou un principal sur une mauvaise lecture d'architecture coûte cher : remplacer un salarié représente de 50 % à 200 % de son salaire annuel (SHRM/Gallup), et l'impact d'une erreur sur un poste senior se propage à toute l'équipe. Rocket4RPO calibre vos system design interviews, forme vos évaluateurs et construit des grilles par niveau. Estimez l'enjeu financier de vos recrutements clés avec notre calculateur.