Crack the System Design-interview: tip fra en Twitter-softwareingeniør

Jeg skrev for nylig om, hvordan jeg landede tilbud fra flere top-tier tech-virksomheder. Under min forberedelsesproces læsede jeg meget materiale og udarbejdede et sæt noter om, hvordan man løser systemdesignproblemer. I denne artikel vil jeg gerne dele disse tip med jer alle.

Hvis du er en nyuddannet uden erfaring med 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-03-2019): Hvis du gerne vil være med i en gruppe studerende for at lære mere om systemdesign, arrangerer 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 information.

Sådan systemdesign: Tips fra en Twitter-softwareingeniør

Denne artikel er opdelt i følgende fire sektioner:

  • Stil afklaringsspørgsmål
  • Brug din baggrund
  • Løs systematisk et problem
  • Opbevar dine egne notater

Stil afklaringsspørgsmål

Et hovedmål med et systemdesignsamtale er at give kandidaten en 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 hertil er, at det skal give dig en chance for at demonstrere følgende:

  • Hvordan du tænker på problemrummet
  • Hvordan du tænker på flaskehalse
  • Hvad du kan gøre for at fjerne disse flaskehalse.
Sådan designes denne sorte kasse

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

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

Et godt præciseringsspø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 brugerforventningen til systemet er
  3. Giver dig retning om, hvor du skal gå videre
  4. Informerer dig om mulige flaskehalse / problemområder

I eksemplet med den sorte boks kan du måske spørge: ”Nå, hvad har kassen? Hvor mange varer indeholder det? Og hvem er den tilsigtede bruger? ”

Til det kan jeg sige, lad os opbygge en gul kasse med en smiley på, der højst skal indeholde 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 klemmes, ikke holdes, så jeg vil ikke have noget greb om det.

Der går du, dette er kassen.

Min ideelle kasse med et smiley-ansigt

Stil altid afklaringsspørgsmål. Du bedømmes ikke om, hvorvidt du stillede et specifikt spørgsmål under interviewet, men du bedømmes efter, hvordan du tænker på problemrummet.

Hvis jeg for eksempel 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 ud på et stykke papir. Gå så dybt og bredt som du kan, og kom derefter tilbage til denne artikel. Bedre endnu, kan du efterlade dine noter i kommentarerne nedenfor, og vi kan diskutere videre.

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

Dette er ret 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 catering deres svar til at passe forventningerne.

Jeg afskrækker faktisk nogen fra at gøre dette af flere grunde:

  1. Alle har en unik baggrund. I et systemdesignsamtale er det en mulighed for dig at demonstrere, hvad dine styrker er. Spild ikke muligheden for at finde ud af, hvad en anden kunne forvente af dig.
  2. Intervieweren har måske nikket sammen til dine svar, men de har måske vidst, at du bare bluffer din vej igennem og ikke tænker over problemet.

Din oplevelse 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, interesserer folk sig for hvad du kan bringe til bordet.

Løs problemet systematisk

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

Nogle af tingene i mit sind, når jeg arbejder med et nyt system, er:

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

Blandt andre…

Se, mit sæt kriterier afviger fra en front-end ingeniørs sæt af kriterier. Jeg bruger disse kriterier til at formulere et billede i mit hoved, og disse vil være vejledende for 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 gerne gør, er, hvordan man designer et kaffe-ordre-system. Jeg tænkte på dette, mens jeg sad på Starbucks en dag og indså, at det ville være dejligt, hvis jeg kunne bestille en smoothie på min telefon og hente den hos mine lokale Starbucks.

Mit sind begyndte at gå i forskellige retninger:

  • Hvad gør denne kaffe-bestillingsmaskine?
  • Hvis jeg bygger en, kan jeg sælge den til Starbucks, eller hvidmærker jeg den og sælger den som en service?
  • Hvor mange brugere har jeg brug for at støtte, hvis jeg sælger det til Starbucks?
  • Alternativt, hvis jeg hvidmærker det, kan jeg sælge grænsefladen til min kaffe-bestillingstjeneste og derefter hjælpe kunderne med at opbygge en backend, så de kan gemme ordrer på deres lokale maskiner?
Hvordan man nærmer sig dette problem

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

Min kaffe-bestillingstjeneste er en software som en 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.
  • Det har en GET API, kaldet getCoffeesForMerchant, der returnerer en liste over kaffe for et givet handlende-ID.
  • Forhandler-ID er en unik identifikator (UUID), der genereres ved hjælp af en eller anden hashmekanisme, som kan afklares yderligere med kunden.
  • Softwaren er optimeret til skrivebeskyttet operation, fordi de fleste af mine kunder opretter deres menu én gang og læser den flere gange i løbet af dagen.
  • Den har en cachemekanisme, der bruger mindst-nyligt anvendte (LRU) -udkastningsstrategi, fordi hvis menupunktet ikke er blevet bestilt på et stykke tid, er min kunde ligeglad med, om det er lidt langsommere i at dukke op i menuen.
  • I tilfælde af, at en af ​​dataene lagrer selvudbrud, vil min kaffe-bestillingstjeneste kopiere data på tværs af forskellige klynger over USAs vestkyst og den amerikanske østkyst, fordi jeg kun er målrettet mod det amerikanske marked for nu.

Alternativt vil enhver anden kaffe-bestillingstjeneste, 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, dette er meget interessante problemer, og det er en fantastisk mental øvelse at holde dit sind engageret.

Opbevar dine egne notater

Som softwareingeniør er det en uendelig læringsproces. Jeg anbefaler stærkt, at du bruger enten Evernote eller en Moleskin til at holde notater. 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 bærbar computer, der hedder “Programmering” i min Evernote. Hver gang jeg støder på noget nyt eller noget interessant, noterer jeg det i min notesbog for yderligere henvisning.

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

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

Undskyld for den dårlige grammatik og skrivefejl: s

En af de ting, jeg for nylig lærte af en kollega, er, at NoSQL er fantastisk til prototyper, fordi der ikke er behov for at gennemgå schema-diskussioner med andre teams. 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" notebook.

Jeg opdeler mine noter i:

  1. Systemdesign
  2. Interview (erfaring + gennemgang af forskellige interviews, jeg har haft før, grupperet efter firmanavn)
  3. Tilfældige tid-bits, CS-velkendt, som nyttige bash-scripts eller kommandolinjetricks
  4. Aflæsninger / YouTube-videoer

Alle ovenstående noter er under ”Programmering”. Med tiden finder jeg ud af, at jeg har en pseudoorganiseret samling af ting, som jeg enten har læst eller udforsket i fortiden.

Som enhver, der kender mig på et personligt plan, er jeg ikke en meget organiseret person. Således har jeg kun samlet 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 mulighed for at udføre systemdesign, skal du enten finde en der gør det, eller prøve at designe en lille del af en eksisterende arkitektur, så det enten er hurtigere, billigere, mere robust, eller lettere at ændre i fremtiden.

Ressourcer, jeg anbefaler

Introduktion til: Arkitektur og systemdesign - Fantastisk Youtube-tutorial fra en ex-Facebook-ingeniør om, hvordan man kan benytte systemdesignproblemer.

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

Mock Interviews - Et simuleret miljø, der efterligner det faktiske interview er meget nyttigt i forberedelserne til interviews. Hvis du kan finde en ven til at gøre det for dig, så vil jeg varmt anbefale det. Jeg kører også spotintervju, så hvis du er interesseret, er du velkommen til at nå mig på zhiachong.com!

Hvad enhver softwareingeniør skal vide om data i realtid, som er en samlet abstraktion - En meget langvarig og teknisk diskussion om logs, trade-offs. Jeg er ikke færdig med det endnu, men det anbefales stærkt fra en kollega.

Evernote - Den bedste note-holder app, jeg har brugt. Der er mange tutorials om, hvordan man bedst kan bruge Evernote. Jeg har ikke gennemgået dem endnu, simpelthen fordi jeg bruger det som bare en bærbar computer. Jeg logger alt, hvad jeg lærer der, og går derefter lejlighedsvist igennem og omorganiserer dem.

Moleskin notebook - Jeg kan virkelig lide denne. Kvaliteten på den er ekstremt høj. Prisen er lidt højere, men da jeg bruger den dagligt, betragter jeg den som en god investering. At have en smuk notesbog i mine hænder hver dag gør mig mere ophidset over at skrive flere noter.

Pilot G2 (sort) - Nemt de bedste penne, jeg nogensinde har brugt, og de eneste penne, jeg vil bruge. 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 rundt. Det skriver godt, blækket flyder jævnt, og jeg elsker bare følelsen af ​​at skrive med det. Sammen med Moleskin vil jeg sommetider bare hente G2 for at notere tilfældige ting derpå, fordi disse to er så perfekte sammen.

At få fat i System Design Interview - Denne kommer som en anbefaling fra venner. Det er et online-kursus, der lærer, hvordan man designe distribueret system i detaljer. Det er en kursus på $ 79. Der er en teampriser. Hvis der er nogen interesse, tjekker jeg hos dem for at se, om det er muligt at danne en gruppe til grupperejse.

Følg mig på Twitter, Facebook og LinkedIn. Tilmeld mig min postliste, hvor jeg regelmæssigt sender tip, tricks og erhvervslæring.

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