Rompi l'intervista di System Design: consigli di un ingegnere del software Twitter

Di recente ho scritto di come ho ottenuto offerte da più aziende tecnologiche di alto livello. Durante il processo di preparazione al colloquio, ho letto molto materiale e preparato una serie di note su come affrontare i problemi di progettazione del sistema. In questo articolo, vorrei condividere questi suggerimenti con tutti voi.

Se sei un neolaureato senza esperienza in sistemi distribuiti su larga scala, o anche un ingegnere esperto con anni di esperienza alle spalle, questo articolo ti sarà utile.

Aggiornamento (24/03/2019): se desideri unirti a un gruppo di studenti per saperne di più sulla progettazione del sistema, sto organizzando una piccola classe insieme! Puoi andare a questo link per saperne di più o visitare il mio sito Web: zhiachong.com per maggiori informazioni.

Come progettare il sistema: suggerimenti di un ingegnere del software Twitter

Questo articolo è suddiviso nelle seguenti quattro sezioni:

  • Poni domande di chiarimento
  • Usa il tuo sfondo
  • Affrontare sistematicamente un problema
  • Mantieni i tuoi appunti

Poni domande di chiarimento

Uno degli obiettivi principali di un'intervista di progettazione di sistemi è quello di offrire al candidato l'opportunità di dimostrare le proprie conoscenze.

Non ci sono risposte strettamente giuste o sbagliate. Una buona domanda di progettazione del sistema suona in genere molto ambigua e la ragione è che dovrebbe darti la possibilità di dimostrare quanto segue:

  • Come penseresti dello spazio problematico
  • Come pensi ai colli di bottiglia
  • Cosa puoi fare per rimuovere questi colli di bottiglia.
Come progettare questa scatola nera

Immagina che ti venga chiesto di progettare una scatola nera. Come affronteresti il ​​problema? Non ci sono indicazioni chiare su cosa devi costruire qui, a parte la scatola che può contenere alcuni oggetti al suo interno.

Una delle strategie più utili che personalmente utilizzo è quella di porre domande di chiarimento. Quali sono le "buone" domande di chiarimento che ponete?

Una buona domanda di chiarimento ti aiuta a raggiungere una o più di una serie di cose:

  1. Ti aiuta a restringere l'ambito di ciò che dovresti fare
  2. Aiuta a chiarire quali sono le aspettative dell'utente per il sistema
  3. Ti dà indicazioni su dove procedere
  4. Ti informa di possibili colli di bottiglia / aree problematiche

Nell'esempio della scatola nera, potresti chiedere: “bene, cosa contiene la scatola? Quanti oggetti contiene? E chi è l'utente previsto? "

Per quello che potrei dire, costruiamo una scatola gialla con una faccina che dovrebbe contenere al massimo 1 palla da tennis. Questa non è una normale palla da tennis, tuttavia. Sarà di almeno 0,5 m di raggio e pesa circa 1 kg. È pensato per essere abbracciato, non trattenuto, quindi non voglio alcun controllo.

Ecco qua, questa è la scatola.

La mia scatola ideale con una faccina sorridente

Poni sempre domande di chiarimento. Non vieni valutato se hai fatto o meno una domanda specifica durante il colloquio, ma sei giudicato su come pensi allo spazio del problema.

Ad esempio, se dovessi chiederti di progettare Twitter in questo momento, come lo faresti? Dedica qualche minuto a pensarci, e magari anche a disegnarlo su un pezzo di carta. Vai nel modo più profondo e ampio possibile, quindi torna a questo articolo. Meglio ancora, puoi lasciare le tue note nei commenti qui sotto e possiamo discutere ulteriormente.

Se non te ne sei ancora reso conto, il risultato finale dell'esercizio precedente produrrebbe risultati significativamente diversi. Per il mio background specifico, potrei approfondire a fondo la progettazione dell'API e l'infrastruttura di back-end. Probabilmente avrei esplorato anche problemi specifici di iPhone, a causa della mia esperienza. Parlerò di come il client interagisce con gli endpoint di livello intermedio, come funzionerebbe la registrazione, come progetterei il backend per garantire il tempo di attività e così via.

Queste sono discussioni piuttosto interessanti che puoi avere con un collega, e questo è un segnale molto forte che un intervistatore sta cercando.

Usa il tuo background a tuo vantaggio

Spesso vedo gli ingegneri che cercano di capire cosa sta cercando di fare l'intervistatore, e poi soddisfano le loro risposte per soddisfare le aspettative.

In realtà scoraggio fortemente chiunque dal farlo per diversi motivi:

  1. Ognuno ha uno sfondo unico. In un'intervista di progettazione di sistemi, è un'opportunità per te per dimostrare quali sono i tuoi punti di forza. Non sprecare l'opportunità di cercare di capire cosa potrebbe aspettarsi qualcun altro da te.
  2. L'intervistatore potrebbe aver fatto un cenno con la testa alle tue risposte, ma potrebbe aver saputo che stai solo facendo il bluff e non stai pensando al problema.

La tua esperienza e il tuo background possono variare notevolmente dal prossimo candidato. Porta sul tavolo un insieme di valori e competenze che nessun altro può fare. Questo è ciò che ti rende prezioso e insostituibile. Indipendentemente dal campo in cui ti trovi, le persone si preoccupano di ciò che puoi portare al tavolo.

Affronta il problema in modo sistematico

Ora, con la mia esperienza in mente, ci sono diverse cose a cui penso quando sto affrontando un nuovo sistema. Consiglio vivamente di formulare una serie di criteri o passaggi anche per te stesso.

Alcune delle cose che ho in mente quando lavoro su un nuovo sistema sono:

  • Qual è l'obiettivo del sistema?
  • Chi sono gli utenti del sistema?
  • Qual è la scala con cui stiamo lavorando?
  • È un nuovo / vecchio sistema? Come gestiamo il versioning?

Tra gli altri…

Vedi, la mia serie di criteri sarà diversa dalla serie di criteri di un ingegnere front-end. Uso questi criteri per formulare un'immagine nella mia testa e questi guideranno il mio processo decisionale.

Armato delle risposte a queste domande, posso iniziare ad affrontare il problema a portata di mano e poi scomporlo sistematicamente in singoli componenti.

Un buon esercizio che mi piace fare è come progettare un sistema di ordinazione del caffè. Ci ho pensato mentre ero seduto a Starbucks un giorno e mi sono reso conto che sarebbe stato bello poter ordinare un frullato sul telefono e prenderlo dal mio Starbucks locale.

La mia mente ha iniziato ad andare in varie direzioni:

  • Cosa fa questa macchina per ordinare il caffè?
  • Se ne costruisco uno, posso venderlo a Starbucks o posso farlo con etichetta bianca e venderlo come servizio?
  • Quanti utenti devo supportare se lo vendo a Starbucks?
  • In alternativa, se lo contrassegno in bianco, posso vendere l'interfaccia al mio servizio di ordinazione del caffè e quindi aiutare i clienti a costruire un backend in modo che possano archiviare gli ordini sui loro computer locali?
Come affrontare questo problema

Una volta ottenute le risposte a queste domande, posso finalmente creare un quadro completo di ciò che fa il mio servizio di ordinazione del caffè. Ecco come sarebbe la mia versione del servizio di ordinazione del caffè:

Il mio servizio di ordinazione caffè è un software come servizio (SAAS). Offre un'interfaccia a cui possono collegarsi vari partner.

  • Ha un'API, chiamata addCoffeeForMerchant, che inserisce il nome del caffè, il prezzo del caffè e gli ingredienti del caffè.
  • Ha un'API GET, chiamata getCoffeesForMerchant, che restituisce un elenco di caffè per un determinato ID commerciante.
  • L'ID commerciante è un identificatore univoco (UUID) che viene generato utilizzando un meccanismo di hashing, che può essere ulteriormente chiarito con il cliente.
  • Il software è ottimizzato per le operazioni di sola lettura, perché la maggior parte dei miei clienti crea il proprio menu una volta e lo legge più volte durante il giorno.
  • Ha un meccanismo di memorizzazione nella cache che utilizza la strategia di sfratto utilizzata di recente (LRU), perché se la voce di menu non è stata ordinata da un po 'di tempo, al mio cliente non importa se è leggermente più lento nella visualizzazione del menu.
  • Nel caso in cui uno dei negozi di dati esploda automaticamente, il mio servizio di ordinazione del caffè replicherà i dati attraverso diversi cluster lungo la costa occidentale e orientale degli Stati Uniti perché sto prendendo di mira il mercato statunitense solo per ora.

In alternativa, qualsiasi altro servizio di ordinazione del caffè a cui puoi pensare sarebbe altamente probabile. È solo una questione di ciò per cui stai ottimizzando. Penso che questi siano problemi molto interessanti, ed è un ottimo esercizio mentale per mantenere la mente impegnata.

Mantieni i tuoi appunti

Come ingegnere del software, è un processo di apprendimento senza fine. Consiglio vivamente di usare Evernote o Moleskin per tenere appunti. Personalmente porto con me un piccolo quaderno per le idee veloci che devo annotare e continuo a tenere diverse altre cose su Evernote ogni volta che posso.

Ho un Notebook chiamato "Programmazione" nel mio Evernote. Ogni volta che mi imbatto in qualcosa di nuovo, o in qualcosa di interessante, lo annoto nel mio taccuino per ulteriori riferimenti.

Esamino e assegno le etichette a queste nuove note su base mensile o trimestrale per assicurarmi che le note siano organizzate. Ad esempio, ho un'etichetta "Design" per tutto ciò che ha a che fare con la progettazione del sistema. Potrebbe essere qualcosa di simile a un link a un video di YouTube che ho trovato interessante o una discussione interessante che il mio collega ha esposto a cui non avevo pensato.

Questo è un esempio di come appare uno dei miei appunti:

Ci scusiamo per la cattiva grammatica e errori di battitura: p

Una delle cose che ho imparato di recente da un collega è che NoSQL è ottimo per la prototipazione, perché non è necessario sottoporsi a discussioni di schema con altri team. Se volessi cambiare lo schema, posso farlo molto velocemente con un database NoSQL. Questa è stata una chiave di apprendimento dal lavoro che ho inserito nel mio taccuino "Programmazione".

Divido i miei appunti in:

  1. Disegni di sistemi
  2. Intervista (esperienza + revisione di diverse interviste che ho avuto in passato, raggruppate per nome dell'azienda)
  3. Tid-bit casuali, CS di buona conoscenza, come utili script bash o trucchi da riga di comando
  4. Letture / video di YouTube

Tutte le note sopra vanno sotto "Programmazione". Nel corso del tempo, ho scoperto di avere una raccolta pseudo-organizzata di cose che ho letto o esplorato in passato.

Come chiunque mi conosca a livello personale, non sono una persona molto organizzata. Pertanto, ho raccolto solo forse il 10-15% delle cose, quindi c'è ancora molto da fare.

Conoscenza e pratica vanno di pari passo per migliorare le progettazioni dei sistemi. Se ritieni che il tuo lavoro attuale non ti offra l'opportunità di progettare sistemi, allora dovresti trovarne uno che lo fa o provare a progettare una piccola parte di un'architettura esistente in modo che sia più veloce, più economica, più robusta, o più facile da modificare in futuro.

Risorse che raccomando

Introduzione a: Architecture and Systems Designs - Grande tutorial su Youtube di un ex ingegnere di Facebook su come affrontare i problemi di progettazione dei sistemi.

Progettazione di applicazioni ad alta intensità di dati - Un'altra buona risorsa per imparare a progettare per la scala. Parla di varie cose che un tipico ingegnere informatico dà per scontato: come funzionano i database (mySQL e noSQL), quando usarli, pro e contro di varie tecniche per gestire la bilancia ecc. Lo consiglio vivamente

Interviste simulate: un ambiente simulato che imita l'intervista effettiva è estremamente utile nella preparazione delle interviste. Se riesci a trovare un amico che lo faccia per te, lo consiglio vivamente. Conduco anche interviste simulate, quindi se sei interessato, non esitare a contattarmi su zhiachong.com!

Ciò che ogni ingegnere del software dovrebbe sapere sull'astrazione unificante dei dati in tempo reale - Una discussione molto lunga e tecnica su log, compromessi. Non l'ho ancora finito, ma è altamente raccomandato da un collega.

Evernote: la migliore app per tenere appunti che ho usato. Esistono molti tutorial su come utilizzare al meglio Evernote. Non li ho ancora esaminati, semplicemente perché lo uso solo come un quaderno. Registro tutto ciò che imparo e quindi ogni tanto li ripasso e li riorganizzo.

Notebook Moleskin - Mi piace davvero questo. La qualità è estremamente alta. Il prezzo è leggermente più alto, ma poiché lo uso quotidianamente, lo considero un buon investimento. Tenendo un bel taccuino in mano ogni giorno mi rende più eccitato di scrivere più note.

Pilot G2 (nero) - Facilmente le migliori penne che io abbia mai usato e le uniche penne che userò. Li compro alla rinfusa da Amazon e li tengo in giro ovunque io vada. Ne ho uno nello zaino, uno in ufficio e uno nel mio ufficio a casa, in modo da avere sempre una penna in giro. Scrive alla grande, l'inchiostro scorre uniformemente e adoro la sensazione di scrivere con esso. Insieme al Moleskin, a volte voglio solo prendere il G2 per scrivere cose casuali lì perché questi due sono così perfetti insieme.

Grokking the System Design Interview - Questo viene come una raccomandazione dagli amici. È un corso online che insegna in dettaglio come progettare un sistema distribuito. È un corso da $ 79, tuttavia. C'è un prezzo di squadra. Se c'è qualche interesse, controllerò con loro per vedere se è possibile formare un gruppo per lo sconto di gruppo.

Seguimi su Twitter, Facebook e LinkedIn. Iscriviti alla mia mailing list dove invio regolarmente suggerimenti, trucchi e conoscenze del settore.

Se ti è piaciuto questo articolo, commenta di seguito: qual è il tuo consiglio per costruire un sistema scalabile e affidabile?