Interview de Crack the System Design: conseils d'un ingénieur logiciel de Twitter

J'ai récemment écrit sur la façon dont j'ai reçu les offres de plusieurs entreprises de premier plan dans le secteur des technologies. Pendant le processus de préparation de mon entretien, j'ai lu beaucoup de documents et préparé un ensemble de notes sur la manière de traiter les problèmes de conception de système. Dans cet article, j'aimerais partager ces conseils avec vous tous.

Si vous êtes un nouveau diplômé sans expérience dans les systèmes distribués à grande échelle, ou même un ingénieur expérimenté avec des années d’expérience à votre actif, cet article vous sera utile.

Mise à jour (24/03/2019): Si vous souhaitez rejoindre un groupe d’étudiants pour en savoir plus sur la conception du système, j’organise un petit cours ensemble! Vous pouvez aller sur ce lien pour en savoir plus ou visiter mon site web: zhiachong.com pour plus d'informations.

Comment concevoir un système: Conseils d'un ingénieur logiciel Twitter

Cet article est divisé en quatre sections:

  • Poser des questions de clarification
  • Utilisez votre fond
  • Aborder systématiquement un problème
  • Gardez vos propres notes

Poser des questions de clarification

Un entretien de conception de systèmes a pour objectif principal de donner au candidat l’occasion de démontrer ses connaissances.

Il n'y a pas de réponses strictement bonnes ou mauvaises. Une bonne question sur la conception d’un système semble généralement très ambiguë, et la raison en est qu’elle est supposée vous donner une chance de démontrer ce qui suit:

  • Que pensez-vous de l'espace problématique?
  • Comment pensez-vous des goulots d'étranglement
  • Que pouvez-vous faire pour supprimer ces goulots d'étranglement?
Comment concevoir cette boîte noire

Imaginez que l’on vous demande de concevoir une boîte noire. Comment aborderiez-vous le problème? Il n’ya pas de directives claires sur ce que vous devez construire ici, mis à part le fait que la boîte peut contenir certains éléments.

L’une des stratégies les plus utiles que j’utilise personnellement est de poser des questions de clarification. Quelles sont les «bonnes» questions de clarification, vous demandez-vous?

Une bonne question de clarification vous aide à atteindre un ou plusieurs objectifs:

  1. Vous aide à réduire la portée de ce que vous êtes censé faire
  2. Permet de clarifier les attentes des utilisateurs vis-à-vis du système
  3. Vous indique où procéder
  4. Vous informe des éventuels goulots d'étranglement / problèmes

Dans l'exemple de la boîte noire, vous pourriez demander: «eh bien, que contient la boîte? Combien d'articles contient-il? Et qui est l'utilisateur prévu? "

Pour cela, je dirais, construisons une boîte jaune avec un smiley qui devrait contenir au plus une balle de tennis. Ce n'est pas une balle de tennis ordinaire, cependant. Il aura au moins 0,5 m de rayon et pèse environ 1 kg. Il est censé être pris dans les bras et non tenu en place, donc je ne veux pas qu’il soit manipulé.

Voilà, c'est la boîte.

Ma boite idéale avec un visage souriant

Toujours poser des questions de clarification. Vous n'êtes pas jugé sur le point de savoir si vous avez posé ou non une question spécifique lors de l'entretien, mais sur la manière dont vous envisagez le problème.

Par exemple, si je vous demandais de concevoir Twitter maintenant, comment le feriez-vous? Prenez quelques minutes pour y réfléchir et peut-être même le dessiner sur un bout de papier. Allez aussi profondément et largement que vous le pouvez, puis revenez à cet article. Mieux encore, vous pouvez laisser vos notes dans les commentaires ci-dessous et nous pourrons en discuter davantage.

Si vous ne le réalisez pas encore, le résultat final de l’exercice ci-dessus produirait des résultats très différents. Pour ce qui est de mon expérience spécifique, je pourrais approfondir la conception d’API et l’infrastructure d’arrière-plan. J’explorerais probablement aussi des problèmes spécifiques à l’iPhone, en raison de mon expérience. Je vais parler de la manière dont le client interagit avec les noeuds finaux de niveau intermédiaire, de la manière dont la journalisation fonctionnerait, de la manière dont je concevais le backend pour assurer la disponibilité, etc.

Ce sont des discussions assez intéressantes que vous pouvez avoir avec un collègue, et c'est un signe très fort qu'un intervieweur recherche.

Utilisez votre expérience à votre avantage

Souvent, je vois des ingénieurs qui essaient de comprendre ce que l’intervieweur essaie de demander, puis ils adaptent leurs réponses aux attentes.

En fait, je décourage fortement quiconque de le faire pour plusieurs raisons:

  1. Tout le monde a un fond unique. Lors d’un entretien de conception de systèmes, c’est l’occasion pour vous de démontrer vos forces. Ne perdez pas l’occasion en essayant de comprendre ce que quelqu'un d’autre pourrait attendre de vous.
  2. L’intervieweur a peut-être incliné vos réponses, mais il se peut qu’il sache que vous bluffez et que vous ne réfléchissez pas réellement au problème.

Votre expérience et vos antécédents peuvent varier considérablement du candidat suivant. Vous apportez à la table un ensemble de valeurs et d'expertise que personne d'autre ne peut. C'est ce qui vous rend précieux et irremplaçable. Peu importe le domaine dans lequel vous évoluez, les gens se soucient de ce que vous pouvez apporter à la table.

Aborder le problème systématiquement

Maintenant, avec mon expertise en tête, je pense à plusieurs choses lorsque je m’attaque à un nouveau système. Je vous recommande fortement de formuler vous-même un ensemble de critères ou d’étapes.

Certaines des choses qui me viennent à l’esprit lorsque je travaille sur un nouveau système sont les suivantes:

  • Quel est le but du système?
  • Qui sont les utilisateurs du système?
  • Quelle est l’échelle avec laquelle nous travaillons?
  • Est-ce un nouveau / ancien système? Comment traitons-nous le versioning?

Entre autres…

Vous voyez, mon ensemble de critères sera différent de celui d’un ingénieur front-end. J'utilise ces critères pour formuler une image dans ma tête et ceux-ci guideront mon processus de prise de décision.

Armé de réponses à ces questions, je peux commencer à aborder le problème actuel, puis à le décomposer systématiquement en composants individuels.

Un bon exercice que j'aime faire consiste à concevoir un système de commande de café. J'ai pensé à cela alors que j'étais assis chez Starbucks un jour et je me suis rendu compte que ce serait bien si je pouvais commander un smoothie sur mon téléphone et le récupérer chez mon Starbucks local.

Mon esprit a commencé à aller dans différentes directions:

  • Que fait cette machine à commander du café?
  • Si j'en construis un, puis-je le vendre à Starbucks, ou dois-je le mettre en marque blanche et le vendre en tant que service?
  • Combien d'utilisateurs dois-je prendre en charge si je le vends à Starbucks?
  • Sinon, si je le marque en blanc, puis-je vendre l'interface à mon service de commande de café et ensuite aider les clients à créer un back-end afin qu'ils puissent stocker les commandes sur leurs machines locales?
Comment aborder ce problème

Une fois que j'ai obtenu des réponses à ces questions, je peux enfin avoir une image complète de ce que fait mon service de commande de café. Voici à quoi ressemblerait ma version du service de commande de café:

Mon service de commande de café est un logiciel en tant que service (SAAS). Il offre une interface à divers partenaires à brancher.

  • Il possède une API, appelée addCoffeeForMerchant, qui insère le nom du café, le prix du café et les ingrédients du café.
  • Il possède une API GET, appelée getCoffeesForMerchant, qui renvoie une liste de cafés pour un identifiant de commerçant donné.
  • L'identifiant du commerçant est un identifiant unique (UUID) généré à l'aide d'un mécanisme de hachage pouvant être clarifié avec le client.
  • Le logiciel est optimisé pour les opérations en lecture seule, car la plupart de mes clients créent leur menu une fois et le lisent plusieurs fois au cours de la journée.
  • Il a un mécanisme de mise en cache qui utilise la stratégie d’expulsion moins utilisée récemment (LRU), car si l’élément de menu n’a pas été commandé depuis un moment, mon client ne se soucie pas de s’afficher un peu plus lentement dans le menu.
  • Au cas où l'un des magasins de données s'ouvrirait automatiquement, mon service de commande de café répliquerait les données sur différents clusters de l'ouest et de la côte est des États-Unis, car je ne visais le marché américain que pour l'instant.

Alternativement, tout autre service de commande de café auquel vous pouvez penser serait également très probable. C’est juste une question de ce que vous optimisez. Je pense que ce sont des problèmes très intéressants et que c’est un excellent exercice mental que de garder votre esprit occupé.

Gardez vos propres notes

En tant qu’ingénieur logiciel, c’est un processus d’apprentissage sans fin. Je vous recommande vivement d’utiliser Evernote ou un Moleskine pour prendre des notes. Personnellement, je porte un petit cahier contenant les idées rapides que je dois noter, et je garde diverses autres choses sur Evernote chaque fois que je peux.

J'ai un cahier nommé «Programmation» dans mon Evernote. Chaque fois que je rencontre quelque chose de nouveau ou d'intéressant, je le note dans mon cahier pour plus de référence.

Je passe et attribue des étiquettes à ces nouvelles notes sur une base mensuelle ou trimestrielle pour m'assurer que les notes sont bien organisées. Par exemple, j'ai une étiquette «Design» pour tout ce qui a trait à la conception du système. Cela peut être quelque chose comme un lien vers une vidéo YouTube que je trouve intéressante, ou un argument intéressant que mon collègue a avancé et auquel je n’avais pas pensé.

Voici un exemple de l'une de mes notes:

Désolé pour la mauvaise grammaire et les fautes de frappe: p

L’une des choses que j’ai récemment appris d’un collègue est que NoSQL est idéal pour le prototypage, car il n’est pas nécessaire de discuter de schémas avec d’autres équipes. Si je voulais changer le schéma, je peux le faire très rapidement avec une base de données NoSQL. C’est un apprentissage essentiel tiré du travail que j’ai inséré dans mon cahier de “Programmation”.

Je décompose mes notes en:

  1. Conception de systèmes
  2. Interviewing (expérience + revue des différentes interviews que j’ai eues dans le passé, regroupées par nom de société)
  3. Tid-bits aléatoires, bons à savoir, comme des scripts bash utiles ou des astuces en ligne de commande
  4. Lectures / vidéos YouTube

Toutes les notes ci-dessus vont sous «Programmation». Au fil du temps, j’aperçois que j’ai une collection pseudo-organisée de choses que j’ai lues ou explorées dans le passé.

En tant que personne qui me connaît sur le plan personnel, je ne suis pas une personne très organisée. Ainsi, je n’ai collecté que 10 à 15% des objets, il reste donc beaucoup à faire.

La connaissance et la pratique vont de pair pour améliorer la conception des systèmes. Si vous estimez que votre travail actuel ne vous permet pas de concevoir des systèmes, vous devez en trouver un ou essayer de concevoir une petite partie d'une architecture existante de manière à ce qu'elle soit plus rapide, moins chère et plus robuste. ou plus facile à modifier à l'avenir.

Ressources que je recommande

Intro à: Architecture et conception de systèmes - Excellent tutoriel sur Youtube, créé par un ancien ingénieur de Facebook, sur la manière de résoudre les problèmes de conception de systèmes.

Conception d'applications gourmandes en données - Une autre bonne ressource pour apprendre à concevoir pour évoluer. Il décrit différentes choses qu'un ingénieur logiciel typique considère comme allant de soi - comment fonctionnent les bases de données (mySQL et noSQL), quand les utiliser, le pour et le contre de diverses techniques de gestion de la balance, etc. Je le recommande vivement

Simulation d'entrevues - Un environnement simulé imitant l'interview réelle est extrêmement utile pour préparer les interviews. Si vous pouvez trouver un ami pour le faire à votre place, je le recommande vivement. Je fais aussi des simulations d’entretiens, alors si vous êtes intéressé, n'hésitez pas à me contacter sur zhiachong.com!

Ce que chaque ingénieur logiciel devrait savoir sur l’abstraction unificatrice des données en temps réel - Une discussion très longue et technique sur les journaux, les compromis. Je n’ai pas encore fini, mais c’est vivement recommandé par un collègue.

Evernote - La meilleure application de conservation de notes que j'ai utilisée. Il existe de nombreux tutoriels sur la meilleure utilisation d'Evernote. Je ne les ai pas encore parcourues, simplement parce que je ne l’utilise que comme un cahier. J'enregistre tout ce que j'apprends là-bas, puis parfois, je les réorganise.

Cahier Moleskine - J'aime beaucoup celui-ci. La qualité de celui-ci est extrêmement élevée. Le prix est un peu plus élevé, mais comme je l'utilise quotidiennement, je le considère comme un bon investissement. Tenir un beau cahier dans mes mains tous les jours me rend plus enthousiaste à écrire plus de notes.

Pilot G2 (noir) - Sans aucun doute les meilleurs stylos que j’ai jamais utilisés et les seuls stylos que j’utiliserai. Je les achète en masse chez Amazon et je les garde partout où je vais. J'en ai un dans mon sac à dos, un au bureau et un dans mon bureau à la maison pour avoir toujours un stylo. Il écrit très bien, l'encre coule doucement et j'adore la sensation d'écrire avec. Couplé au Moleskine, parfois je veux juste prendre le G2 pour noter des choses au hasard là-dessus parce que ces deux sont si parfaits ensemble.

Entretien Grokking the System Design - Celui-ci est une recommandation d'amis. C’est un cours en ligne qui explique comment concevoir un système distribué en détail. C'est un cours de 79 $, cependant. Il y a une tarification par équipe. Si cela vous intéresse, je vais vérifier avec eux pour voir s’il est possible de former un groupe à rabais.

Suivez-moi sur Twitter, Facebook et LinkedIn. Inscrivez-vous à ma liste de diffusion et envoyez régulièrement des conseils, des astuces et des enseignements de l'industrie.

Si vous avez apprécié cet article, commentez ci-dessous: quel est votre conseil pour créer un système évolutif et fiable?