Crack l’entrevista de disseny del sistema: consells d’un desenvolupador de programari de Twitter

Recentment he escrit sobre com he rebut ofertes de diverses empreses de primera tecnologia. Durant la preparació de l'entrevista vaig llegir un munt de material i vaig preparar diversos consells sobre com abordar els problemes de disseny del sistema. En aquest article vull compartir aquests consells amb tots vosaltres.

Si sou un graduat sense experiència amb sistemes distribuïts a gran escala o un enginyer experimentat amb anys d’experiència, aquest article us serà útil.

Actualització (24/03/2013): si voleu unir-vos a un grup d'estudiants per obtenir més informació sobre el disseny del sistema, organitzaré una petita classe junts. Podeu anar a aquest enllaç per obtenir més informació o visitar el meu lloc web: zhiachong.com per obtenir més informació.

Disseny de sistemes: consells d’un desenvolupador de programari de Twitter

Aquest article es divideix en les quatre seccions següents:

  • Feu preguntes per aclarir-les
  • Utilitzeu el vostre fons
  • Abordatge sistemàtic d’un problema
  • Guardeu les vostres pròpies notes

Feu preguntes per aclarir-les

L’objectiu central d’una entrevista de disseny de sistemes és donar al candidat l’oportunitat de demostrar el seu coneixement.

No hi ha respostes absolutament correctes o incorrectes. Una bona pregunta sobre el disseny del sistema sol semblar molt ambigua. El motiu d'això és donar-vos l'oportunitat de demostrar:

  • Què us semblaria sobre l’espai problemàtic
  • Què li sembla als colls d'ampolla?
  • Què podeu fer per eliminar aquests colls d'ampolla?
Així és com dissenyeu aquesta caixa negra

Imagineu que us demanen que dissenyi una caixa negra. Com abordaries el problema? No hi ha instruccions clares sobre què construir aquí, a part del fet que la caixa pot contenir alguns elements.

Una de les estratègies més útils que faig servir personalment és fer preguntes d’aclariment. Quines són les "bones" preguntes d'aclariment?

Una bona pregunta d’aclariment us ajudarà a assolir un o més dels objectius següents:

  1. Us ajuda a limitar l’abast de les vostres activitats previstes
  2. Ajuda a aclarir què espera l'usuari del sistema
  3. Us proporciona instruccions sobre com procedir
  4. T’informa sobre possibles colls d’ampolla / àrees problemàtiques

A l'exemple de la caixa negra, us podeu preguntar: "Bé, què hi ha al quadre? Quants elements conté? I qui és l’usuari previst? "

A més, voldria dir que estem construint una caixa groga amb un somriure, que només hauria de contenir 1 pilota de tennis com a màxim. Tot i això, no es tracta d’una pilota de tennis normal. El radi és com a mínim de 0,5 mi el pes és d’aproximadament 1 kg. Està destinat a ser abraçat, no subjectat, de manera que no vull agafar-lo.

Anem, aquesta és la caixa.

La meva caixa ideal amb cara de somriure

Feu sempre preguntes per aclarir-les. No se us jutjarà si heu fet o no una pregunta específica durant l’entrevista, sinó sobre com us sentiu sobre l’àrea problemàtica.

Per exemple, si ara et demanés que dissenyis Twitter, com ho faries? Preneu-vos uns minuts per pensar-hi i potser fins i tot dibuixeu-lo en un tros de paper. Aneu tan profund com pugueu i torneu a aquest article. Millor encara, podeu deixar les vostres notes als comentaris que hi ha a continuació i en podem parlar més.

Si encara no us n'heu adonat, el resultat final de l'exercici anterior produiria resultats significativament diferents. A causa de la meva experiència específica, puc aprofundir en el disseny de les API i la infraestructura de backend molt intensament. Segons la meva experiència, probablement també investigaria problemes específics de l’iPhone. Parlaré de com interactua el client amb els punts finals de nivell mitjà, de com funcionaria el registre, de com dissenyo el back-end per garantir la disponibilitat, etc.

Són converses molt interessants per mantenir amb un company de feina i és un senyal molt fort que busca un entrevistador.

Utilitzeu el vostre fons per al vostre avantatge

Sovint veig enginyers que intenten esbrinar què intenta preguntar l’entrevistador i adaptar les seves respostes a les expectatives.

No puc aturar ningú per diversos motius:

  1. Tothom té un bagatge únic. Podeu mostrar on es troben els vostres punts forts en una entrevista de disseny de sistemes. No deixeu passar l’oportunitat de conèixer què poden voler els altres.
  2. És possible que l’entrevistador hagi assentit amb les seves respostes, però sabia que només feia blufes i no pensaves en el problema.

La vostra experiència i antecedents poden variar molt del següent candidat. Aporteu una gamma de valors i experiència que ningú més no pot. Això us fa valuós i insubstituïble. Independentment de quin camp estigueu, a la gent li importa què podeu aportar a la taula.

Abordeu el problema sistemàticament

Tenint en compte la meva experiència, hi ha algunes coses que penso en iniciar un sistema nou. Us recomano que també formuleu una sèrie de criteris o passos.

Quan treballo en un sistema nou, penso en alguns dels següents aspectes:

  • Quin és l'objectiu del sistema?
  • Qui són els usuaris del sistema?
  • Amb quina escala treballem?
  • És aquest un sistema nou / antic? Com tractem les versions?

Entre altres…

Ja veieu, els meus criteris són diferents del que seria un enginyer frontal. Utilitzo aquests criteris per formular una imatge al meu cap i aquests guiaran el meu procés de presa de decisions.

Amb respostes a aquestes preguntes, puc començar a abordar el problema que ens ocupa i, després, dividir-lo sistemàticament en components individuals.

Un bon exercici que m’agrada fer és dissenyar un sistema de comanda de cafè. Això és el que vaig pensar estant assegut a Starbucks un dia, i em vaig adonar que seria bo que pogués demanar un batut al telèfon i recollir-lo al meu Starbucks local.

Els meus pensaments van començar a anar en diferents direccions:

  • Què fa aquesta cafetera?
  • Puc vendre-ho a Starbucks si en construeixo un o el puc etiquetar en blanc i vendre’l com a servei?
  • Quants usuaris he de donar suport si el venc a Starbucks?
  • Com a alternativa, si els etiqueto en blanc, puc vendre la interfície al meu servei de comandes de cafè i ajudar els clients a crear un back-end perquè puguin emmagatzemar les comandes a les seves màquines locals?
Com es pot abordar aquest problema?

Un cop tingui respostes a aquestes preguntes, per fi puc obtenir una imatge completa del que fa el meu servei de comandes de cafè. Així seria la meva versió del servei de comanda de cafè:

El meu servei de comanda de cafè és Software as a Service (SAAS). Ofereix una interfície a la qual es poden connectar diversos socis.

  • Té una API anomenada addCoffeeForMerchant que insereix el nom del cafè, el preu del cafè i els ingredients del cafè.
  • Té una API GET anomenada getCoffeesForMerchant que retorna una llista de cafès per a una identificació de comerciant determinada.
  • L'identificador de comerciant és un identificador únic (UUID) que es genera mitjançant un mecanisme de resum que es pot aclarir més amb el client.
  • El programari està optimitzat per a operacions de només lectura, ja que la majoria dels meus clients creen el menú una vegada i el llegeixen diverses vegades al llarg del dia.
  • Té un mecanisme d'emmagatzematge en memòria cau que utilitza l'estratègia de desallotjament Least-Recent-Used (LRU). Si l'element del menú no es demana des de fa molt de temps, al meu client no li importa si es mostra una mica més lent al menú.
  • Si un dels magatzems de dades falla, el meu servei de comandes de cafè replica dades en diferents clústers de les costes oest i est dels EUA, ara com ara em concentro al mercat nord-americà.

Com a alternativa, qualsevol altre servei de comanda de cafè que puguis pensar seria molt probable. Es tracta d’allò que optimitzeu. Crec que són problemes molt interessants i és un exercici mental fantàstic per mantenir la ment ocupada.

Guardeu les vostres pròpies notes

Com a desenvolupador de programari, aquest és un procés d’aprenentatge interminable. Recomano encaridament utilitzar Evernote o una pell de pell per prendre notes. Personalment, porto una petita llibreta amb idees ràpides per apuntar-me i guardar diverses altres coses a Evernote sempre que puc.

Tinc un quadern anomenat Programació al meu Evernote. Sempre que em trobo amb alguna cosa nova o interessant, l’escric a la meva llibreta per a més referència.

Reviso aquestes notes noves cada mes o cada trimestre amb etiquetes per assegurar-me que les notes estiguin organitzades. Per exemple, tinc una etiqueta de "disseny" per a tot el que fa al disseny del sistema. Podria ser un enllaç a un vídeo de YouTube que em va semblar interessant o un argument interessant que el meu company no havia pensat.

Aquest és un exemple de l'aspecte d'una de les meves notes:

Perdoneu la mala gramàtica i els errors tipogràfics: pàg

Una de les coses que he après recentment d’un company és que NoSQL és ideal per prototipar perquè no requereix discussions d’esquemes amb altres equips. Si volia canviar l’esquema, ho puc fer molt ràpidament amb una base de dades NoSQL. Aquesta va ser una troballa important del treball que vaig posar al meu quadern de "programació".

Desglosso les meves notes en:

  1. Dissenys de sistemes
  2. Enquesta (experiència + revisió de diverses entrevistes que he realitzat en el passat, agrupades per nom de l'empresa)
  3. Bits informatius aleatoris, bé de saber CS, com ara scripts bash útils o trucs de línia d'ordres
  4. Lectures / vídeos de YouTube

Trobareu tota la informació anterior a "Programació". Amb el pas del temps, trobo que tinc una col·lecció pseudoorganitzada de coses que he llegit o investigat en el passat.

Com algú que em coneix personalment, no sóc una persona molt ben organitzada. Per tant, només he recopilat un 10-15% de les coses, de manera que encara hi ha moltes coses a fer.

El coneixement i la pràctica van de la mà per millorar el disseny del sistema. Si creieu que el vostre treball actual no us proporciona la possibilitat de dissenyar sistemes, n'heu de trobar un o provar de dissenyar una petita porció d'una arquitectura existent perquè sigui més ràpida, més barata o més robusta. o més fàcil de canviar en el futur.

Recursos que recomano

Introducció a: Arquitectura i disseny de sistemes: gran tutorial de Youtube d'un antic enginyer de Facebook sobre com tractar problemes de disseny de sistemes.

Disseny d'aplicacions intensives en dades: un altre recurs fantàstic per aprendre a escalar. Es tracta de diverses coses que un desenvolupador de programari típic dóna per descomptat: com funcionen les bases de dades (mySQL i noSQL), quan s’han d’utilitzar, avantatges i desavantatges de diverses tècniques per fer front a les economies d’escala, etc.

Entrevistes simulades: un entorn simulat que imita l’entrevista real és extremadament útil per preparar les entrevistes. Si podeu trobar un amic que pugui fer-ho per vosaltres, us ho recomano. També faig entrevistes simulades. Així que si esteu interessats, no dubteu a contactar-me a zhiachong.com.

Què han de saber tots els desenvolupadors de programari sobre l'abstracció unificada de dades en temps real: una discussió tècnica i llarga sobre protocols i compromisos. Encara no ho he acabat, però un company ho recomana.

Evernote: la millor aplicació per prendre notes que he utilitzat mai. Hi ha molts tutorials sobre com utilitzar millor Evernote. No ho he mirat només perquè només l’utilitzo com a portàtil. Allà hi tinc un registre de tot allò que aprenc i, de tant en tant, em reorganitzo.

Quadern Moleskin: aquest m’agrada molt. La qualitat és extremadament alta. El preu és una mica més elevat, però com que el faig servir diàriament, crec que és una bona inversió. Tenir un bon quadern a les mans cada dia em fa més il·lusió prendre més notes.

Pilot G2 (negre): simplement els millors bolígrafs que he fet servir i els únics que utilitzaré. Els compro a granel a Amazon i els conservo a tot arreu. Tinc una a la motxilla, una a l'oficina i una a la meva oficina, de manera que sempre tinc un bolígraf amb mi. Escriu molt bé, la tinta flueix suaument i m’encanta la sensació d’escriure amb ella. En relació amb el Moleskin, de vegades només vull fer servir el G2 per escriure-hi coses aleatòries perquè aquestes dues combinen perfectament.

Grokking the System Design Entrevista: aquesta és una recomanació dels amics. És un curs en línia que explica detalladament com dissenyar sistemes distribuïts. Tanmateix, té una taxa de 79 dòlars. Hi ha preus per equips. Si esteu interessats, us preguntaré si és possible formar un grup amb un descompte de grup.

Segueix-me a Twitter, Facebook i LinkedIn. Inscriviu-vos a la meva llista de correu on publico regularment consells, trucs i experiències del sector.

Si us ha agradat aquest article, comenteu a continuació: Quin és el vostre consell per crear un sistema fiable i escalable?