Knæk systemdesigninterviewet: tip fra en Twitter-softwareingeniør

Jeg skrev for nylig om, hvordan jeg landede tilbud fra flere top-tech-virksomheder. Under min forberedelsesproces til interview læste jeg op på meget materiale og forberedte et sæt noter om, hvordan man tacklede systemdesignproblemer. I denne artikel vil jeg gerne dele disse tip med jer alle.

Hvis du er en nyuddannet uden erfaring i store distribuerede systemer eller endda en erfaren ingeniør med mange års erfaring under dit bælte, vil denne artikel være nyttig for dig.

Opdatering (24.3.2019) : Hvis du gerne vil deltage i en gruppe studerende for at lære mere om systemdesign, organiserer jeg en lille klasse sammen! Du kan gå til dette link for at lære mere eller besøge min hjemmeside: zhiachong.com for mere info.

Denne artikel er opdelt i følgende fire sektioner:

  • Stil afklaringsspørgsmål
  • Brug din baggrund
  • Håndter et problem systematisk
  • Hold dine egne noter

Stil afklaringsspørgsmål

Et centralt mål for et systemdesigninterview er at give kandidaten mulighed for at demonstrere deres viden.

Der er ingen strengt rigtige eller forkerte svar. Et godt systemdesignspørgsmål lyder normalt meget tvetydigt, og grunden til det er, at det skal give dig en chance for at demonstrere følgende:

  • Hvordan du ville tænke på problemområdet
  • Hvordan du tænker på flaskehalse
  • Hvad du kan gøre for at fjerne disse flaskehalse.

Forestil dig, at du bliver bedt om at designe en sort kasse. Hvordan vil du tackle problemet? Der er ingen klare anvisninger om, hvad du har brug for at bygge her, bortset fra at boksen er i stand til at holde nogle genstande i den.

En af de mest nyttige strategier, jeg personligt bruger, er at stille afklaringsspørgsmål. Hvad er “gode” afklaringsspørgsmål, spørger du?

Et godt afklaringsspørgsmål hjælper dig med at opnå en eller flere af flere ting:

  1. Hjælper dig med at indsnævre omfanget af, hvad du skal gøre
  2. Hjælper med at afklare, hvad brugerens forventning til systemet er
  3. Giver dig vejledning om, hvor du skal gå videre
  4. Informerer dig om mulige flaskehalse / problemområder

I eksemplet med den sorte boks kan du spørge: ”Nå, hvad holder kassen? Hvor mange ting indeholder den? Og hvem er den tiltænkte bruger? ”

Til det kan jeg sige, lad os bygge en gul kasse med en smiley på, som højst skal rumme 1 tennisbold. Dette er dog ikke en almindelig tennisbold. Det vil være mindst 0,5 m i radius og vejer ca. 1 kg. Det er meningen, at det skal krammes, ikke holdes, så jeg vil ikke have noget greb om det.

Derefter, dette er kassen.

Stil altid afklaringsspørgsmål. Du bliver ikke bedømt på, om du har stillet et specifikt spørgsmål under interviewet eller ej, men du bliver bedømt på, hvordan du tænker på problemområdet.

For eksempel, hvis jeg skulle bede dig om at designe Twitter lige nu, hvordan ville du gøre det? Brug et par minutter på at tænke over det, og måske endda tegne det på et stykke papir. Gå så dybt og bredt som muligt, og kom derefter tilbage til denne artikel. Endnu bedre, du kan efterlade dine noter i kommentarerne nedenfor, og vi kan diskutere yderligere.

Hvis du ikke har indset det endnu, ville slutresultatet af øvelsen ovenfor give væsentligt forskellige resultater. For min egen specifikke baggrund kan jeg gå dybt ned i API-design og backend-infrastruktur. Jeg vil sandsynligvis også udforske iPhone-specifikke problemer på grund af min erfaring. Jeg vil tale om, hvordan klienten interagerer med de mellemliggende slutpunkter, hvordan logning ville fungere, hvordan jeg ville designe backend for at sikre oppetid osv.

Dette er ganske interessante diskussioner, som du kan have med en kollega, og det er et meget stærkt signal, som en interviewer leder efter.

Brug din baggrund til din fordel

Ofte ser jeg ingeniører forsøge at finde ud af, hvad intervieweren prøver at spørge, og derefter sørge for, at deres svar svarer til forventningerne.

Jeg fraråder faktisk nogen at gøre dette af flere grunde:

  1. Alle har en unik baggrund. I et systemdesigninterview er det en mulighed for dig at demonstrere, hvad dine styrker er. Spild ikke muligheden for at prøve at finde ud af, hvad en anden kan forvente af dig.
  2. Intervieweren nikkede måske sammen til dine svar, men de vidste måske, at du bare bluffede dig igennem og ikke faktisk tænkte på problemet.

Din erfaring og baggrund kan variere meget fra den næste kandidat. Du bringer et sæt værdier og ekspertise til bordet, som ingen andre kan. Det er det, der gør dig værdifuld og uerstattelig. Uanset hvilket felt du befinder dig i, bekymrer folk sig om, hvad du kan bringe til bordet.

Håndter problemet systematisk

Nu med min ekspertise i tankerne er der flere ting, jeg tænker på, når jeg tackler et nyt system. Jeg anbefaler stærkt, at du også formulerer et sæt kriterier eller trin.

Nogle af de ting, jeg tænker på, når jeg arbejder på et nyt system er:

  • Hvad er systemets mål?
  • Hvem er brugerne af systemet?
  • Hvad er skalaen, vi arbejder med?
  • Er dette et nyt / gammelt system? Hvordan håndterer vi versionering?

Blandt andre…

Se, mit sæt kriterier vil være anderledes end en front-end ingeniørs sæt af kriterier. Jeg bruger disse kriterier til at formulere et billede i mit hoved, og disse vil styre min beslutningsproces.

Bevæbnet med svar på disse spørgsmål kan jeg begynde at tackle det aktuelle problem og derefter systematisk opdele det i individuelle komponenter.

En god øvelse, jeg kan lide at gøre, er, hvordan jeg designer et kaffebestillingssystem . Jeg tænkte på dette, mens jeg sad på Starbucks en dag og indså, at det ville være rart, hvis jeg kunne bestille en smoothie på min telefon og afhente den hos min lokale Starbucks.

Mit sind begyndte at gå i forskellige retninger:

  • Hvad gør denne kaffebestillingsmaskine?
  • Hvis jeg bygger en, kan jeg sælge den til Starbucks, eller mærker jeg den og sælger den som en tjeneste?
  • Hvor mange brugere skal jeg støtte, hvis jeg sælger det til Starbucks?
  • Alternativt, hvis jeg hvidmærker det, kan jeg så sælge grænsefladen til min kaffebestillingstjeneste og derefter hjælpe kunderne med at opbygge en backend, så de kan gemme ordrer på deres lokale maskiner?

Når jeg først får svar på disse spørgsmål, kan jeg endelig danne mig et fuldstændigt billede af, hvad min kaffe-bestillingstjeneste gør. Sådan ser min version af kaffebestillingstjenesten ud:

Min kaffebestillingstjeneste er en software as a service (SAAS). Det tilbyder en grænseflade, som forskellige partnere kan tilslutte.

  • Det har en API, kaldet addCoffeeForMerchant , der indsætter kaffe navn, kaffe pris og kaffe ingredienser.
  • Den har en GET API, kaldet getCoffeesForMerchant , der returnerer en liste over kaffe for et givet handels-ID.
  • Forhandler-id'et er en unik identifikator (UUID), der genereres ved hjælp af en hashing-mekanisme, som kan afklares yderligere med kunden.
  • Softwaren er optimeret til skrivebeskyttede operationer, fordi de fleste af mine kunder opretter deres menu en gang og læser den flere gange i løbet af dagen.
  • Den har en cachemekanisme, der bruger LRU-bortkastningsstrategi, for hvis menupunktet ikke er bestilt på et stykke tid, er min kunde ligeglad med, om det vises lidt langsommere i menuen.
  • Hvis en af ​​datalagrene brister selv, vil min kaffebestillingstjeneste replikere data på tværs af forskellige klynger over den amerikanske vestkyst og den amerikanske østkyst, fordi jeg kun målretter mod det amerikanske marked for nu.

Alternativt vil enhver anden kaffebestillingstjeneste, som du kan tænke på, også være meget sandsynlig. Det er bare et spørgsmål om, hvad du optimerer til. Jeg synes, det er meget interessante problemer, og det er en god mental øvelse at holde dit sind engageret.

Hold dine egne noter

Som softwareingeniør er det en uendelig læringsproces. Jeg anbefaler stærkt, at du bruger enten Evernote eller en Moleskin til at føre noter. Jeg bærer personligt en lille notesbog til hurtige ideer, jeg har brug for at notere, og jeg opbevarer forskellige andre ting på Evernote, når jeg kan.

Jeg har en notesbog med navnet “Programmering” i min Evernote. Hver gang jeg løber ind i noget nyt eller noget interessant, noterer jeg det i min notesbog til yderligere reference.

Jeg går igennem og tildeler etiketter til disse nye noter månedligt eller kvartalsvis for at sikre, at noterne er organiserede. For eksempel har jeg et "Design" -mærke til alt, hvad der har med systemdesign at gøre. Det kunne være noget som et link til en YouTube-video, som jeg fandt interessant, eller et interessant argument, som min kollega fremførte, som jeg ikke havde tænkt på.

Dette er et eksempel på, hvordan en af ​​mine noter ser ud:

En af de ting, jeg for nylig lærte fra en kollega, er, at NoSQL er fantastisk til prototyping, fordi der ikke er behov for at gennemgå skemadiskussioner med andre hold. Hvis jeg ville ændre skemaet, kan jeg gøre det virkelig hurtigt med en NoSQL-database. Det var en vigtig læring fra arbejde, som jeg indsatte i min "Programmering" notesbog.

Jeg nedbryder mine noter i:

  1. Systemdesign
  2. Interviewing (erfaring + gennemgang af forskellige interviews, jeg har haft tidligere, grupperet efter firmanavn)
  3. Tilfældige tid-bits, CS god-at-vide, som nyttige bash-scripts eller kommandolinjetricks
  4. Læsninger / YouTube-videoer

Alle ovenstående noter går under “Programmering”. Over tid finder jeg ud af, at jeg har en pseudo-organiseret samling af ting, jeg enten har læst eller udforsket tidligere.

Som enhver, der kender mig personligt, er jeg ikke en meget organiseret person. Således har jeg kun samlet måske 10-15% af tingene, så der er meget mere tilbage at gøre der.

Viden og praksis går hånd i hånd med at blive bedre til systemdesign. Hvis du føler, at dit nuværende arbejde ikke giver dig muligheden for at lave systemdesign, skal du enten finde en der gør det, eller prøve at designe en lille del af en eksisterende arkitektur, så den enten er hurtigere, billigere, mere robust, eller lettere at ændre i fremtiden.

Ressourcer, jeg anbefaler

Introduktion til: Arkitektur og systemdesign - Stor Youtube-tutorial fra en tidligere Facebook-ingeniør om, hvordan man nærmer sig systemdesignproblemer.

Design af dataintensive applikationer - En anden god ressource til at lære at designe til skala. Det taler om forskellige ting, som en typisk softwareingeniør tager for givet - hvordan databaser (mySQL og noSQL) fungerer, hvornår de skal bruge hver, fordele og ulemper ved forskellige teknikker til håndtering af skala osv. Jeg kan varmt anbefale det?

Mock Interviews - Et simuleret miljø, der efterligner det egentlige interview, er yderst nyttigt til forberedelse til interviews. Hvis du kan finde en ven til at gøre det for dig, så anbefaler jeg det stærkt. Jeg kører også mock-interviews, så hvis du er interesseret, er du velkommen til at kontakte mig på zhiachong.com!

Hvad enhver softwareingeniør bør vide om realtidsdatas samlende abstraktion - En meget langvarig og teknisk diskussion om logfiler, kompromiser. Jeg er ikke færdig med det endnu, men det anbefales stærkt fra en kollega.

Evernote - Det bedste? note-holder app jeg har brugt. Der er mange tutorials om, hvordan man bedst udnytter Evernote. Jeg har ikke gennemgået dem endnu, simpelthen fordi jeg bruger det som bare en notesbog. Jeg logger alt, hvad jeg lærer der, og går derefter lejlighedsvis igennem og omorganiserer dem.

Moleskin notesbog - Jeg nyder virkelig denne. Kvaliteten af ​​den er ekstremt høj. Prisen er lidt højere, men da jeg bruger den dagligt, anser jeg den for en god investering. At holde en smuk notesbog i mine hænder hver dag gør mig mere begejstret for at skrive flere noter.

Pilot G2 (sort) - Let de bedste penne, jeg nogensinde har brugt, og de eneste penne, jeg bruger. Jeg køber dem i bulk fra Amazon og holder dem rundt overalt, hvor jeg går. Jeg har en i min rygsæk, en på kontoret og en på mit hjemmekontor, så jeg altid har en pen omkring. Det skriver godt, blækket flyder glat, og jeg elsker bare følelsen af ​​at skrive med det. Sammen med Moleskin vil jeg nogle gange bare hente G2 for at skrive tilfældige ting der, fordi disse to er så perfekte sammen.

Grokking af systemdesigninterviewet - Denne kommer som en anbefaling fra venner. Det er et online kursus, der lærer, hvordan man designer det distribuerede system i detaljer. Det er dog $ 79 kursus. Der er en team-prisfastsættelse. Hvis der er nogen interesse, vil jeg kontakte dem for at se, om det er muligt at danne en gruppe til grupperabat.

Følg mig på Twitter, Facebook og LinkedIn. Tilmeld dig min mailingliste, hvor jeg regelmæssigt sender tips, tricks og branchelærdomme.

Hvis du kunne lide denne artikel, skal du kommentere nedenfor: hvad er dit tip til at opbygge et skalerbart, pålideligt system?