Available inFrenchEnglishGermanHindiPortugueseRussianSpanish
Entretien system design : notions clés
Défendez à l'oral, chronomètre en main, une architecture en nommant l'arbitrage que l'examinateur note au lieu d'énumérer des composants. Pour des développeurs qui font déjà tourner des systèmes en production et ont besoin du vocabulaire sous la main, pas d'un cours depuis zéro. Quatre-vingt-seize cartes en onze chapitres, du cadrage du besoin au cache, à la réplication, au partitionnement, aux files et au service de modèles ; l'entraînement porte sur l'échange, pas sur les algorithmes ni les produits d'un fournisseur.
« Concevez Twitter. » L'examinateur se tait. Quel est votre premier geste, avant qu'une seule boîte soit tracée ?
Faire valider le périmètre à voix haute : qui sont les utilisateurs, les deux ou trois choses que le système doit faire, l'échelle à laquelle il tourne. Vous serez noté sur ces exigences-là.
— Le premier livrable est une liste, pas un schéma.
Source
Le travail sur les exigences est le reproche écrit le plus fréquent à mi-niveau, et reste dans le trio de tête au niveau senior (Hello Interview, « system design requirements »). Le rituel est court : d'abord les exigences fonctionnelles (ce qu'un utilisateur peut faire), puis les non fonctionnelles qui façonnent l'architecture, puis l'échelle. Deux ou trois exigences fonctionnelles, c'est le bon nombre pour quarante-cinq minutes, et dire « ce sont celles que je vais concevoir » invite l'examinateur à vous corriger tant que c'est encore gratuit. Dessiner d'abord est le coup perdant : chaque boîte qu'aucune exigence ne justifie est une boîte que vous défendrez pour rien.