Razbiti sistemski intervju: nasveti inženirja programske opreme Twitter

Pred kratkim sem pisal o tem, kako sem oddajal ponudbe iz več vrhunskih tehnoloških podjetij. Med postopkom priprave na razgovor sem prebral veliko gradiva in pripravil nabor opomb, kako se spoprijeti s težavami v zasnovi sistema. V tem članku želim te nasvete deliti z vsemi.

Če ste nov diplomant, ki nima izkušenj z obsežnimi distribucijskimi sistemi, ali celo začarani inženir z dolgoletnimi izkušnjami pod pasom, vam bo ta članek koristen.

Posodobitev (24.3.2019): Če se želite pridružiti skupini študentov, če želite izvedeti več o oblikovanju sistema, skupaj organiziram majhen pouk! Če želite izvedeti več, pojdite na to povezavo ali pa obiščite mojo spletno stran: zhiachong.com za več informacij.

Kako načrtovati sistem: Nasveti inženirja programske opreme Twitter

Ta članek je razdeljen na naslednje štiri sklope:

  • Zastavite pojasnila
  • Uporabite svoje ozadje
  • Problema se lotite sistematično
  • Vodite svoje zapiske

Zastavite pojasnila

Glavni cilj razgovora o oblikovanju sistemov je dati kandidatu priložnost, da pokaže svoje znanje.

Ni natančno pravilnih ali napačnih odgovorov. Vprašanje dobre zasnove sistema ponavadi zveni zelo dvoumno, razlog za to pa naj bi bil priložnost, da pokažete naslednje:

  • Kako bi pomislili na problemski prostor
  • Kako razmišljate o ozkih grlih
  • Kaj lahko storite, da odstranite ta ozka grla.
Kako oblikovati to črno škatlo

Predstavljajte si, da vas vprašajo, da oblikujete črno polje. Kako bi se lotili problema? Tu ni jasnih navodil o tem, kaj morate zgraditi, razen tega, da je v polju mogoče držati nekatere predmete.

Ena izmed najbolj uporabnih strategij, ki jih osebno uporabljam, je postavljanje pojasnilnih vprašanj. Kakšna so "dobra" pojasnila?

Dobro vprašanje razjasnitve vam pomaga doseči eno ali več več stvari:

  1. Pomaga zožiti področje, kar naj bi počeli
  2. Pomaga razjasniti, kakšna je pričakovanja uporabnikov sistema
  3. Vam daje navodila, kako nadaljevati
  4. Obvešča vas o možnih ozkih grlih / problematičnih področjih

V primeru črnega polja boste morda vprašali: "No, kaj vsebuje škatlo? Koliko predmetov vsebuje? In kdo je predviden uporabnik? "

Na to bi lahko rekel, zgradimo rumeno polje z nasmehom, ki naj vsebuje največ 1 teniško žogo. Vendar to ni navadna teniška žoga. V polmeru bo vsaj 0,5 m in tehtal približno 1kg. Zamišljeno je, da se objema, ne drži, zato ne želim nobenega ročaja.

To je škatla.

Moja idealna škatlica z nasmejanim obrazom

Vedno postavljajte pojasnila. Ne presojate, ali ste med intervjujem postavili določeno vprašanje ali ne, ampak presojate, kako razmišljate o problematičnem prostoru.

Na primer, če bi vas prosil, da takoj oblikujete Twitter, kako bi to storili? Vzemite si nekaj minut, da razmislite o tem in ga morda celo skicirate na kos papirja. Pojdite čim globlje in širše, nato pa se vrnite na ta članek. Še bolje, lahko zapišete svoje opombe v spodnjih komentarjih in lahko razpravljamo naprej.

Če tega še niste spoznali, bi končni rezultat zgornje vaje prinesel bistveno drugačne rezultate. Zaradi mojega posebnega ozadja bi se lahko zelo poglobil v oblikovanje API-ja in varnostno infrastrukturo. Verjetno bi tudi zaradi izkušenj raziskal težave, povezane z iPhone. Govoril bom o tem, kako odjemalec komunicira s končnimi točkami srednjega nivoja, kako bi deloval beleženje, kako bi oblikoval nadomestni računalnik, da bi zagotovil čas dela in podobno.

To so precej zanimive razprave, ki jih lahko imate s sodelavcem, in to je zelo močan signal, ki ga anketar išče.

Uporabite svoje ozadje v svojo korist

Pogosto vidim inženirje, ki poskušajo ugotoviti, kaj sprašuje anketiranec, in nato pripravijo svoje odgovore, da ustrezajo pričakovanjem.

Pravzaprav močno odvračam koga od tega iz več razlogov:

  1. Vsakdo ima edinstveno ozadje. V intervjuju o oblikovanju sistemov vam lahko pokažete, kakšne so vaše prednosti. Ne zapravljajte priložnosti in skušate ugotoviti, kaj lahko kdo drug pričakuje od vas.
  2. Mogoče bi anketiranec odgovoril na vaše odgovore, toda morda bi vedeli, da samo blefirate in dejansko ne razmišljate o težavi.

Vaše izkušnje in ozadje se lahko pri naslednjem kandidatu močno razlikujejo. Na mizo prinesete nabor vrednot in strokovnega znanja, ki ga ne more nihče drug. Zaradi tega ste dragoceni in nenadomestljivi. Ne glede na to, na katerem področju ste, je ljudem vseeno, kaj lahko prinesete k mizi.

Težave se lotite sistematično

Zdaj, ko imam v mislih svoje znanje, je nekaj, o čemer razmišljam, ko se lotevam novega sistema. Toplo priporočam, da oblikujete nabor meril ali korakov tudi zase.

Med delom na novem sistemu imam nekaj v mislih:

  • Kaj je cilj sistema?
  • Kdo so uporabniki sistema?
  • Kakšna je lestvica, s katero sodelujemo?
  • Je to nov / stari sistem? Kako ravnamo z različicami?

Med ostalimi…

Glej, moj nabor meril bo drugačen od nabora inženirjev. Ta merila uporabljam za oblikovanje slike v moji glavi, ki bodo usmerjala moj postopek odločanja.

Oborožen z odgovori na ta vprašanja se lahko lotim problema in ga sistematično razčlenim na posamezne komponente.

Dobra vaja mi je všeč, kako oblikovati sistem za naročanje kave. Na to sem pomislil, ko sem nekega dne sedel pri Starbucksu in spoznal, da bi bilo lepo, če bi lahko na telefon naročil smoothie in ga prevzel v lokalnem Starbucksu.

Misli so mi začele v različnih smereh:

  • Kaj počne ta aparat za naročanje kave?
  • Če ga sestavim, ga lahko prodam Starbucksu ali ga označim z belo oznako in ga prodam kot storitev?
  • Koliko uporabnikov potrebujem podporo, če jo prodam Starbucksu?
  • Ali lahko, če to označim z belo oznako, vmesnik prodam svoji storitvi naročanja kave in nato strankam pomagam sestaviti zaledje, da lahko shranijo naročila na svojih lokalnih strojih?
Kako pristopiti k tej težavi

Ko dobim odgovore na ta vprašanja, lahko končno oblikujem celotno sliko o tem, kaj počne moja storitev naročanja kave. Takole bi izgledala moja različica storitve naročanja kave:

Moja storitev naročanja kave je programska oprema kot storitev (SAAS). Ponuja vmesnik za vključitev različnih partnerjev.

  • Ima API, imenovan addCoffeeForMerchant, ki vstavi ime kave, ceno kave in sestavine kave.
  • Ima GET API, imenovan getCoffeesForMerchant, ki vrne seznam kavic za določen ID trgovca.
  • ID trgovca je edinstven identifikator (UUID), ki se generira z uporabo nekaterih mehanizmov mešanja, ki jih je mogoče dodatno razjasniti s stranko.
  • Programska oprema je optimizirana za samo branje, saj večina mojih strank enkrat ustvari svoj jedilnik in ga prebere večkrat čez dan.
  • Ima mehanizem za predpomnjenje, ki uporablja strategijo izseljevanja z najnovejšim uporabnikom (LRU), ker če menija v določenem času ni bila naročena, moje stranke ni vseeno, ali se prikaže v meniju nekoliko počasneje.
  • V primeru, da se katera od podatkovnih shramb samoodruši, bo moja storitev naročanja kave kopirala podatke v različnih grozdih po zahodni in ameriški vzhodni obali ZDA, ker zaenkrat ciljam na ameriški trg.

Zelo verjetna bi bila tudi katera koli druga storitev naročanja kave. Je samo vprašanje, za kaj optimizirate. Mislim, da so to zelo zanimive težave in odlična miselna vaja je, da ohranite svoj um.

Vodite svoje zapiske

Kot programski inženir gre za nenehni proces učenja. Toplo priporočam, da za zapiske uporabite bodisi Evernote ali Moleskin. Osebno nosim majhen zvezek za hitre ideje, ki jih moram zapisati, na Evernoteju pa hranim razne druge stvari, kadar koli lahko.

V svoji Evernote imam prenosnik z imenom »Programiranje«. Kadar koli naletim na kaj novega ali kaj zanimivega, zapiram v svoj prenosni računalnik za nadaljnjo uporabo.

Vsako leto mesečno ali četrtletje pregledujem in dodelim oznake tem novim zapiskom, da se prepričam, da so zapiski organizirani. Na primer, imam oznako »Oblikovanje« za vse, kar ima povezavo z zasnovo sistema. To bi lahko bila nekaj kot povezava do videoposnetka v YouTubu, ki se mi je zdel zanimiv ali zanimiv argument mojega sodelavca, o katerem nisem razmišljal.

To je vzorec, kako izgleda ena od mojih zapiskov:

Oprosti za slabo slovnico in tipkarske napake: str

Ena izmed stvari, ki sem se je pred kratkim naučila od sodelavcev, je, da je NoSQL odličen za izdelavo prototipov, saj ni treba, da bi se z drugimi skupinami pogovarjali o shemi. Če bi želel spremeniti shemo, lahko to storim res hitro z bazo podatkov NoSQL. To je bilo ključno učenje iz dela, ki sem ga vstavil v zvezek »Programiranje«.

Svoje zapiske razčlenim na:

  1. Oblikovanje sistemov
  2. Intervju (izkušnja + pregled različnih intervjujev, ki sem jih imel v preteklosti, razvrščeno po imenu podjetja)
  3. Naključne sitnice, dobro poznavanje CS, kot so uporabni skripti bash ali triki v ukazni vrstici
  4. Branja / YouTube video posnetki

Vse zgornje opombe spadajo pod "Programiranje". Sčasoma ugotovim, da imam psevdo organizirano zbirko stvari, ki sem jih v preteklosti bodisi prebral bodisi raziskoval.

Kot vsak, ki me pozna na osebni ravni, nisem zelo organizirana oseba. Tako sem zbral le 10 do 15% stvari, tako da je tam ostalo še veliko več.

Znanje in praksa sta z roko v roki pri izboljšanju zasnove sistemov. Če menite, da vam trenutno delo ne ponuja priložnosti za načrtovanje sistemov, potem bodite poiščite takšnega, ali pa poskusite zasnovati en majhen del obstoječe arhitekture, tako da je hitrejši, cenejši, robustnejši, ali lažje spreminjati v prihodnosti.

Viri, ki jih priporočam

Uvod v: Projekti arhitekture in sistemov - Odlična Youtube navodila za uporabo inženirja Facebooka o tem, kako pristopiti k težavam pri načrtovanju sistemov.

Oblikovanje podatkovno intenzivnih aplikacij - še en dober vir za učenje oblikovanja obsega. Govori o različnih stvareh, ki jih tipični inženirji programske opreme vzamejo za samoumevne - kako delujejo baze podatkov (mySQL in noSQL), kdaj jih uporabljamo, prednosti in slabosti različnih tehnik za upravljanje obsega itd. Toplo priporočam recommend

Mock Intervjuji - Simulirano okolje, ki posnema dejanski intervju, je izredno koristno pri pripravi na intervjuje. Če lahko najdete prijatelja, ki bi to storil namesto vas, ga toplo priporočam. Vodim tudi posmehljive intervjuje, zato vas, če vas zanima, lahko obrnete na zhiachong.com!

Kaj bi moral vedeti vsak programski inženir o poenotenju odvzema podatkov v realnem času - zelo dolgotrajna in tehnična razprava o dnevnikih, kompromisih. Nisem ga še dokončal, vendar ga močno priporoča sodelavec.

Evernote - najboljša aplikacija za beleženje, ki sem jo uporabil. Obstaja veliko vadnic, kako najbolje izkoristiti Evernote. Nisem še šel skozi njih, preprosto zato, ker ga uporabljam kot zvezek. Zabeležim vse, kar se tam naučim, nato pa občasno preidem skozi njih in jih reorganiziram.

Moleskin zvezek - v tem zelo uživam. Kakovost le-tega je izjemno visoka. Cena je nekoliko višja, a ker jo uporabljam vsakodnevno, se mi zdi dobra naložba. Vsakodnevno držanje lepega zvezka v rokah me bolj navduši, ko pišem več zapiskov.

Pilot G2 (črna) - lahka najboljša peresa, kar sem jih kdaj uporabila, in edina pisala, ki jih bom uporabila. Kupim jih na veliko pri Amazonu in jih hranim povsod, kjer grem. Enega imam v nahrbtniku, enega v pisarni in enega v domači pisarni, tako da imam vedno pisalo naokoli. Piše odlično, črnilo teče gladko in preprosto obožujem občutek, kako pisati z njim. V povezavi z Moleskinom včasih želim, da poberem G2, da bi tam narisal naključne stvari, ker sta ta dva skupaj tako popolna.

Gokking System Design Interview - Ta priporočilo prihaja od prijateljev. To je spletni tečaj, ki uči, kako podrobno oblikovati porazdeljeni sistem. Vendar gre za tečaj 79 dolarjev Obstajajo skupinske cene. Če vas zanima, bom preveril, ali je mogoče oblikovati skupino za skupinski popust.

Spremljajte me na Twitterju, Facebooku in LinkedInu. Prijavite se na moj seznam e-poštnih sporočil, kjer redno pošiljam nasvete, trike in spoznavanja v panogi.

Če ste uživali v tem članku, komentirajte spodaj: kakšen je vaš nasvet za gradnjo razširljivega in zanesljivega sistema?