Trecerea la interviul de proiectare a sistemului

A trecut ceva timp de când am scris ultima dată, dar în ultimul an, am făcut o mulțime de interviuri de design de sistem. Îmi plac foarte mult aceste interviuri, chiar dacă ar avea nevoie de unele îmbunătățiri, pentru că pot semăna foarte mult cu munca mea și sunt suficient de deschise pentru a permite candidaților să-și joace punctele forte.

Pe baza intervievării multor candidați, am compilat câteva sfaturi importante pentru a vă asigura că le oferiți intervievatorilor exact semnalele de care au nevoie pentru a vă evalua punctele forte. Proiectarea sistemului este o abilitate care necesită experiență, dar pentru cei cu experiență, această abilitate ar trebui să fie ceva ce oricum folosesc în munca lor de zi cu zi. Ceea ce urmează este o listă de verificare pentru a combate nervii interviului și pentru a-ți prezenta experiența în acea oră.

Colectați cerințele funcționale și nefuncționale

Am mai vorbit despre colectarea cerințelor , dar acest lucru este deosebit de important pentru interviurile de proiectare a sistemului. Spre deosebire de un algoritm constrâns, un sistem mare are mult mai multe zone în care puteți lua decizii diferite în funcție de cerințele dvs. Există două tipuri de cerințe pe care ar trebui să le clarificați:

• Cerințe funcționale: ce ar trebui de fapt sistemul face? De exemplu, atunci când proiectăm un scurtator de adrese URL, o întrebare importantă de pus este dacă dorim să acceptăm căutările inverse (de la o adresă URL lungă la o adresă URL scurtă existentă)sau dacă puteți tolera ca aceeași adresă URL lungă să fie scurtată în două moduri diferite. Aici înțelegeți cum vor interacționa utilizatorii cu sistemul.
• Cerințe nefuncționale: cum se comportă sistemul din punct de vedere tehnic. Veți dori să înțelegeți amploarea sistemului (numărul de utilizatori, solicitările simultane, cantitatea de date prelucrate sau stocate). Un alt factor comun de clarificat este latența așteptată, în special latența end-to-end pentru întregul sistem, care poate include cerințe de consecvență citire după scriere.

Este în regulă să te scufunzi în unele dintre aceste cerințe în timpul proiectării sistemului tău, pe măsură ce îți dai seama ce compromisuri ești forțat să faci. Cu toate acestea, cu cât ești mai experimentat, cu atât poți recunoaște mai multe dintre aceste cerințe de la început și, prin urmare, nivelul tău de experiență apare în această parte a interviului.

Dar orice ai face, nu te arunca direct într-un design. Aflați mai întâi ce proiectați.

Prezentați o soluție end-to-end

Cea mai mare problemă pe care o văd este atunci când candidații intră în prea multe detalii în unele părți ale arhitecturii lor, iar la sfârșitul interviului, nu au o soluție integrală. Poate că s-au concentrat prea mult pe stocarea datelor și au făcut cu mâna cu mâna asupra modului în care sunt procesate datele. Sau nu au vorbit niciodată despre modul în care datele, sau chiar ce date, ajung de fapt în sistemul lor.

Dacă nu altceva, asigurați-vă că aveți o diagramă bloc de nivel înalt care prezintă în mod clar toate componentele diferite ale sistemului propus. Majoritatea soluțiilor vor consta din aceste piese comune:

• Surse de date: servere de aplicații, dispozitive client etc.
• Depozite de date: baze de date relaționale, serii de timp și cheie-valoare, cache-uri în memorie etc.
• Transport de date: cozi de mesaje, API-uri REST etc.
• Prelucrarea datelor: unde are loc prelucrarea, ce date sunt necesare și ce face prelucrarea.
• Servicii auxiliare dacă au sens: firewall-uri, echilibratoare de încărcare etc. În problemele pe care le dau, acestea sunt de obicei un dat și nu este necesar să fie menționate, dar pot fi centrale pentru alte aplicații.

Observați accentul puternic pe date. Acest lucru se datorează faptului că în majoritatea sistemelor la scară largă, cel puțin din experiența mea, datele sunt în centrul sistemului. Totul despre sistem, diferitele piese și modul în care acestea se leagă, există pentru a vă asigura că datele pot curge prin sistem și pot fi procesate într-un mod valoros pentru utilizatorii dvs.

Utilizați terminologia standard din industrie

Tehnologiile și terminologia specifice pe care compania dumneavoastră le folosește sunt uneori unice, adesea determinate de nevoile specifice ale istoriei sale. Dar la baza acestei unicități se află un set comun de modele pe care le aplică compania ta, iar acele modele sunt limbajul pe care îl împărtășești cu intervievatorul. Faceți referire la aceste modele.

De exemplu, nu ezitați să numiți Kafka sau Amazon SQS dacă vă simțiți confortabil, dar menționați că doriți o coadă de mesaje configurată ca un sistem pub/sub. Această abordare are multe avantaje:

• Dacă intervievatorul nu cunoaște aceleași tehnologii ca și tine (deși ar trebui să-i cunoască pe cei mari), aveți un limbaj comun.
• Arătați că înțelegeți exact funcționalitatea de care are nevoie sistemul propus, deoarece aceeași tehnologie poate fi adesea utilizată din mai multe motive.
• Și, în cele din urmă, arată că, indiferent de trecutul tău, ai suficiente cunoștințe generale pentru a-ți transpune experiența în noul tău rol, unde este posibil să folosești diferite tehnologii.

Denumirea unei anumite tehnologii este grozavă pentru a arăta că aveți experiență în lumea reală, dar asigurați-vă totuși că faceți referire la modelele de bază.

Același lucru este valabil și pentru terminologia specifică companiei. Dacă tu și intervievatorul interpretați aceleași cuvinte ca concepte diferite, veți avea o mulțime de greșeli de comunicare. (Interesant este că toate acestea se pot aplica atunci când lucrați cu alte echipe dintr-o companie mare!)

Explicați ce probleme rezolvați cu alegerile dvs.

Am crezut că acest lucru prezintă compromisuri, dar am descoperit că candidații petrec adesea prea mult timp detaliind soluții alternative în loc să se angajeze la o anumită propunere. Cu toate acestea, compromisurile sunt o parte importantă a proiectării sistemelor mari, așa că este important să explicați ce probleme rezolvă fiecare dintre alegerile dvs.

De exemplu, dacă ați decis să încorporați o coadă de mesaje în designul dvs., puteți spune că sunteți dispus să suportați timpul de procesare (Procesarea nu mai este la cerere, ci atunci când consumatorul din coadă ajunge la acea bucată de date) pentru a se asigura că fiecare dată este procesată în mod fiabil, fără a vă face griji cu privire la condițiile de cursă între prelucrarea datelor aferente. Sau, dacă încorporați un magazin cheie-valoare, puteți spune că doriți citiri cu latență scăzută pentru elemente individuale și nu trebuie să faceți alte interogări pe baza cerințelor funcționale pe care le-ați adunat mai devreme.

Spunând atât de multe și mergând mai departe, arătați că ați făcut alegerile în mod deliberat și cu o înțelegere clară atât a problemei, cât și a celor de soluție, în timp ce rămâneți la o narațiune unificată despre sistemul propus.

Fiți pregătiți să vă scufundați în profunzime în domeniile dumneavoastră de expertiză

Ar trebui să fie acceptabil să nu existe o expertiză aprofundată în toate domeniile sistemului (deși știu că nu toți intervievatorii sunt atât de îngăduitori), dar dacă intervievatorul a ales problema pe baza trecutului tău, ar trebui să existe domenii în care ai experiență. În special, doriți să vă asigurați că puteți vorbi inteligent despre orice parte a sistemului care se aliniază cu munca anterioară, mai ales dacă acea piesă este menționată în mod vizibil în CV-ul dvs.

Ai spus că ai lucrat la o arhitectură de streaming pentru procesarea datelor? Ar trebui să puteți vorbi despre cozile de mesaje, să menționați tehnologii precum Apache Spark sau Samza (sau orice tehnologii pe care le-ați folosit înainte), compromisurile dintre procesarea fluxurilor și prelucrarea datelor online sau offline etc. Dacă ați lucrat mult cu stocarea datelor, ar trebui să puteți vorbi despre fragmentare, opțiuni de baze de date, cache persistentă pe disc vs. în memorie etc.

Acesta este un alt domeniu în care se așteaptă ca cunoștințele tale să fie mai largi cu cât ești mai experimentat. Dacă ești suficient de senior, ar trebui să poți vorbi despre diferitele domenii pe care le-am menționat mai sus cel puțin la un nivel înalt. Acestea sunt concepte destul de standard în ingineria software care apar în multe sisteme la scară largă.

Vorbim despre producția sistemului

În cele din urmă – și aceasta este partea în care se împiedică oamenii fără experiență – vorbesc despre aducerea sistemului în producție. Sperăm că intervievatorul tău a cerut în mod clar acest lucru atunci când a prezentat problema, dar dacă nu, asigură-te că clarifici dacă această parte este ceva despre care trebuie să vorbești.

Aici vorbiți despre monitorizare și înregistrare, gestionarea erorilor (deși unele dintre acestea ar fi putut apărea mai devreme), lansări treptate pentru a aborda probleme precum perioadele de încălzire a cache-ului, degradarea grațioasă în caz de vârfuri neașteptate de trafic etc. Mai exact, monitorizarea și gestionarea erorilor sunt două domenii fiecare sistemul se ocupă de acestea, așa că aș conduce cu acestea.

Această parte a interviului este în care arătați că nu numai că puteți proiecta un sistem teoretic, dar aveți experiența din lumea reală pentru a ști ce probleme va întâmpina un astfel de sistem în producție. Dacă ar fi să te fac un lider tehnic, aș avea încredere că te vei gândi la aceste preocupări înainte Lansăm? Este, de asemenea, un motiv pentru care trebuie să fiți simplificat în ceea ce privește designul general al sistemului, astfel încât să aveți timp să abordați această secțiune.

Ultimul sfat pe care îl am este minor, dar merită menționat rapid: fii gata să-ți arăți designul pe măsură ce îl construiești. Dacă faceți interviul în persoană, fiți pregătiți să desenați diagrame bloc pe tablă. Dacă interviul este virtual, alegeți un instrument de desen și exersați cu el. Asta ar putea însemna chiar să-ți iei propria tablă albă pentru tine! Doar asigurați-vă că este vizibil de pe cameră.

Când este făcut corect, proiectarea sistemului vă oferă dumneavoastră, inginerul experimentat, oportunitatea de a prezenta (cel puțin un subset de) abilitățile tale ca lider tehnic pentru un proiect. Cu toate acestea, deoarece încercați să vă încadrați experiența într-o singură oră, a avea un scenariu pentru interviu înseamnă că puteți arăta exact abilitățile care inspiră încredere în abilitățile dvs.

Acest articol a fost publicat inițial pe site-ul Hiring For Tech. Dacă doriți să citiți mai mult conținut de la mine, vă rugăm să vă abonați fie prin e-mail, fie pe LinkedIn. Dacă aveți păreri despre conținutul meu, comentați mai jos. Și nu uitați să urmează-mă pentru mai mult conținut!