Come posso progettare un sistema arbitrario in un'intervista? [chiuso]

Una domanda comune in Tech Interview è progettare un sistema particolare, di solito un prodotto esistente dell'azienda. Ad esempio, "Progetta Google Documenti".

Qual è la risposta prevista per una domanda del genere? Voglio dire, tali sistemi hanno sicuramente un design complesso che va oltre lo scopo di qualsiasi intervista. Cosa si aspettano gli intervistatori in così poco tempo?

Comprensione di come il tuo cervello guarda a questo problema. Ecco alcuni punti di partenza che ho potuto vedere su come si potrebbe provare ad avere questa conversazione:

• Dall'alto verso il basso - Guardando in basso da un livello molto alto, costruisci un disegno e perfeziona il progetto man mano che vengono eseguiti vari componenti e qui ci sono una manciata di componenti che ho potuto vedere ....

• Bottom-up - Guardando da zero, ecco alcuni pezzi che si potrebbero costruire per cercare di mettere insieme ...

• Chiarimento dei requisiti: fare domande sulla scala, le dimensioni, il budget e il team previsti per questo progetto. Potresti provare ad avere un codice persona un elaboratore di testi molto semplificato oppure potresti spendere centinaia di milioni di dollari per realizzare il sistema di gestione dei documenti definitivo che ritieni sia il modo in cui Google Doc ha portato all'estremo. Anche qui c'è la possibilità di chiedere qualcosa del tipo, "Cosa intendi con Google Doc? Quanta di quella funzionalità vuoi duplicare?" anche domande.

La chiave è quanto riesci a comunicare i tuoi pensieri e il tuo approccio nell'affrontare questo tipo di problema, poiché potresti far avvicinare un utente a te e chiederti "Psst, potresti fare qualcosa del genere in 2 settimane?" ciò potrebbe effettivamente accadere. Pertanto, il modo in cui dai la risposta è più importante di quello che è la risposta.

La mia opinione personale sarebbe che i progetti passati non sono una buona idea qui. Ciò che si sta cercando di trovare è che tipo di creatività e abilità comunicative in una nuova area piuttosto che ricordare semplicemente come è stato fatto qualcosa in passato. È probabile che mentre qualcosa che accade nella nuova posizione può essere simile a qualcosa del passato, ci potrebbero essere abbastanza differenze che la vecchia soluzione non è fattibile. Questo è il motivo per cui, sebbene ciò che può essere creato sia simile a un'applicazione esistente, potrebbero esserci varie personalizzazioni che rendono la soluzione abbastanza diversa dall'esempio iniziale.

Le interviste sono una strada a doppio senso. I manager e gli altri sviluppatori raramente sono maestri nel colloquio, quindi non sono sicuro di vedere il valore nel cercare di affermare che dovrebbero essere esperti in materia nelle interviste di lavoro. I recruiter che vedevo mi aspettavo di sapere come fare un colloquio, ma ci sono molti recruiter poveri che potrebbero essere usati come esempi del perché questa non è sempre una buona idea.

Soprattutto per gli sviluppatori senior, penso che queste domande possano essere molto valide. Mostrano che uno sviluppatore è in grado di passare da una descrizione ampia e complicata a un'implementazione realistica. Anche con un sistema totalmente sconosciuto, dovresti essere in grado di fare una serie di attività interessanti per l'intervistatore:

• Raccogliere i requisiti per rispondere alla domanda (ad es. Ambito di applicazione)
• Suddividere il problema in pezzi più gestibili; eventualmente identificare interfacce o oggetti che potrebbero essere necessari o suddividere la logica in front-end, back-end, DB, ecc.
• Dimostrare familiarità con la struttura e i concetti alla base di quel tipo di sistema, ad esempio le app Web nel caso di Google Documenti
• Mostra su cosa tendi a concentrarti quando viene presentato un problema di progettazione (Progettazione di oggetti? Tabelle SQL? Modelli di progettazione?)
• Mostra al capo un'anteprima di come sarà sviluppare un nuovo sistema con te, in cui il capo entra con una specifica e dice: "Cosa ci vorrebbe per costruire questo?"

Questa domanda è solo una versione di livello superiore di "Descrivi la gerarchia degli oggetti che useresti per questo ..." "Descrivi l'interfaccia che vorresti progettare per questo ..." "Progetta una serie di tabelle DB relazionali per questi dati ...", ecc. Che verrebbero fornite a sviluppatori di livello medio-basso. Negli sviluppatori di livello inferiore, l'intervistatore potrebbe valutare il potenziale a lungo termine della persona per la crescita dell'azienda, o semplicemente vedere cosa fanno di fronte a un grosso problema che potrebbe essere travolgente.

Si tratta di vedere i tuoi processi di pensiero in azione; non sono interessati a una soluzione, ma come approcceresti risolvendo il problema, quali domande faresti, quali problemi identificheresti, ecc.

Dato l'esempio di Google Documenti, gli ovvi problemi che vengono in mente sono cose come archiviazione, sicurezza, scalabilità, disponibilità, progettazione dell'interfaccia client, compatibilità del browser, ecc. Come divideresti la responsabilità tra server e client? Come gestiresti i backup? Cosa succede quando un server si arresta? Cosa faresti con i documenti "abbandonati" (cose a cui non si è avuto accesso o modificato da un lungo periodo di tempo)?

Ancora una volta, il punto non è risolvere nessuno di questi problemi, ma identificarli , parlarne, confrontarsi un po 'su come affrontarli, ecc.

Sono una di quelle parti colpevoli che spesso intervistano questo tipo di domande. (Per la cronaca, faccio anche domande simili sul loro "progetto preferito".) Il motivo per cui lo chiedo è che è qualcosa che facciamo spesso qui intorno. Riceviamo ingegneri di progettazione da tutti i lati di un'interfaccia, qualcuno dell'ingegneria dei sistemi, qualcuno del test e qualcuno con una certa conoscenza dei casi d'uso dei clienti per la funzione. Siamo attorno a una lavagna e diciamo "Okay, come costruiremo questa cosa?" Spesso a quel punto sai molto poco della nuova funzionalità e sei lì solo per la tua esperienza nella tua parte del sistema, ma ci si aspetta che tu contribuisca in modo produttivo. Non è solo un ipotetico esercizio accademico.

Per quanto riguarda il tipo di risposte che mi aspetto, prendiamo ad esempio la progettazione di un sistema per scaricare il nuovo firmware da un server, attraverso 20 schede di linea incorporate in un ufficio centrale per aggiornare 5000 set top box sul campo contemporaneamente. Supponiamo che sul collegamento tra il server e le schede di linea sia presente una capacità di riserva molto ridotta.

Risposta errata:

Uhm, probabilmente userei Ethernet o qualcosa del genere.

Buona risposta:

Di quale immagine stiamo parlando? [Circa 7 MB.] Bene, ti consigliamo di assicurarti che il servizio non sia stato interessato durante il download. Avresti bisogno di flash o RAM extra per memorizzare due immagini contemporaneamente. Probabilmente vorrai memorizzare nella cache l'immagine sulle tue line card per evitare di scaricare ripetutamente la stessa immagine dal server. Essendo incorporate, le schede di linea probabilmente hanno CPU limitate, quindi potrebbe essere necessario serializzare i download per lasciare una capacità sufficiente per il servizio. Vorresti un modo per verificare che l'immagine fosse buona e tornare alla versione precedente se non funzionava. Avresti bisogno di un modo per riprovare alcune volte e segnalare errori a un essere umano se l'aggiornamento non riesce. Se hai diverse marche di set top box, avresti bisogno di un modo per identificare l'immagine che ti serve per inviarla.

Queste sono quasi trascrizioni parola per parola di due diversi candidati. La maggior parte dei candidati si trova da qualche parte nel mezzo, ma di solito ci arriva alla fine con un piccolo suggerimento, il che è perfettamente ok. Non stiamo cercando il prossimo Einstein qui, solo un'indicazione che puoi effettivamente ragionare in modo intelligente sui tipi di problemi su cui lavoriamo ogni giorno.

Faccio anche questo tipo di domanda e sono d'accordo con la maggior parte delle altre risposte. Forse aiuterebbe gli intervistati a capire PERCHÉ questo tipo di domanda è importante? Supponiamo di avere un'importante decisione aziendale da prendere e, per farlo, dobbiamo costruire un nuovo sistema. Se qualcuno ti corre incontro e ti chiede cosa ci vorrebbe per costruire un sistema che fa X, puoi dare loro una risposta perspicace che prevede le principali sfide e risorse richieste?

Un programmatore junior non ha idea da dove iniziare. Non sono pronti per iniziare a parlare senza una specifica dettagliata. Un programmatore senior vedrà immediatamente che ci sono molte sfaccettature del problema e tenterà di affinare una sfida. Non devi progettare ogni aspetto, basta identificare una sfida architettonica e poi capire come affrontarla.

Considera il problema di Google Documenti:

Una cosa interessante è la scala di taglio delle richieste che arriveranno. Non puoi semplicemente ottenere un singolo server e distribuire il tuo codice su di esso - questa è un'impresa più grande. Un intervistato di successo potrebbe concentrarsi su questo e descriverà i tipi di risorse che saranno necessarie e alcune delle sfide tecniche nell'implementazione su quella scala, con un'applicazione che non solo ha uno stato, ma condivide lo stato tra più utenti.

Un'altra cosa interessante di Google Documenti è che più persone possono modificare contemporaneamente. Un intervistato di successo sarà in grado di discutere i meccanismi per assicurarsi che il documento risultante non sia spazzatura, e un candidato davvero eccezionale si renderà conto che i diversi metodi di sincronizzazione o fusione delle modifiche avranno un grande impatto sulle prestazioni e sull'UX. Forse anche discutere delle variazioni: un editor di documenti condivisi per la scrittura di codice dovrebbe probabilmente utilizzare un metodo diverso per risolvere i conflitti rispetto al tipico Google Doc, perché ci sono conseguenze diverse sulle cose che accadono in un ordine diverso o che hanno una struttura leggermente diversa.

Non esiste un solo modo giusto per creare un'app come Google Documenti, non è necessario identificare cosa faresti per ogni compromesso, ma è davvero bello trovare un'area che presenta un problema interessante e spiegare chiaramente quale sia il trade -offs potrebbe essere.

-t.

Sospetto che ciò che gli intervistatori vogliono sentire sia:

Google Doc è un'interfaccia web per un elaboratore di testi. I documenti dell'utente vengono digitati e archiviati e sono recuperabili dall'utente sullo stesso computer o su un altro computer.

Cosa vorresti discutere ulteriormente?

Quindi, la palla è nel campo dell'intervistatore. Se vuole maggiori dettagli, può chiedere. Ciò che l'intervistatore sta cercando è: puoi guardare un problema o un prodotto ed estrarre il design?

Per me, se la persona non inizia con l'identificazione dei casi d'uso / storie chiave, sarebbe sufficiente sapere che non sono preparati per una posizione che richiede questa particolare abilità.

Successivamente, dovrebbero essere in grado di trovare una soluzione architettonica basata sui casi d'uso / storie chiave. Speriamo che abbiano usato un processo sistematico per identificare i moduli oltre a estrarli dal loro ... Non mi aspetterei molto di più da una situazione di intervista per la soluzione.

Tuttavia, potrei scegliere uno dei moduli architettonici e chiedere un progetto più dettagliato, solo per vedere se hanno alcune capacità progettuali. Sarebbe anche bello vedere che considerano i casi di fallimento / problemi di prestazioni. Ma sospetto a questo punto, ci imbatteremo in un muro temporale. Quindi, non potrei davvero penalizzarli per non aver considerato questi problemi perché c'è solo così tanto tempo e penso che sia ragionevole per loro supporre che considerare ogni possibile scenario non è previsto in una situazione di intervista limitata nel tempo.

Recentemente ho avuto un'intervista in cui mi è stato chiesto di progettare un sistema di controllo dell'ascensore. Fondamentalmente vogliono vedere il tuo approccio all'attività. Se ti viene posta questa domanda, probabilmente hanno in mente un lavoro di alto livello. Congratulazioni.

La cosa fondamentale è come risolvere i problemi rispetto ai meriti della soluzione che dai e se sei in grado di affrontare i problemi del quadro generale.

Penso che una cosa importante da fare sia porre domande sui requisiti. Non limitarti a fare ipotesi che consentano al tuo animale domestico di funzionare. Ad esempio, potresti capitare di conoscere qualche metodo davvero ingegnoso per stampare documenti che potresti essere tentato di passare subito alla descrizione. Ma Google Documenti non viene stampato direttamente; produce un PDF che il client stampa quindi. Quindi, se inizi con quello, avrai dedicato metà del tuo tempo a risolvere un problema che non fa parte del problema e hai dimostrato che sei più interessato a usare la tua tecnologia calda che a risolvere il problema del cliente.

Per gestire questo tipo di domande di intervista, dovrai avere un interesse generale a capire "come funzionano le cose", non solo nei progetti che ti interessano ma anche in quelli che ritieni siano troppo lontani dalle tue esperienze.

Ciò significa leggere blog, articoli, http://www.infoq.com , Hacker News, ecc. Anche i bluff hardware di Coding Horror.

Nonostante il fatto che dimenticherai la maggior parte di ciò che hai letto (perché quelle informazioni non sono comunque collegate al tuo lavoro personalmente), ci potrebbero essere alcuni bocconcini che sono i "semi dell'immaginazione" e una piccola frazione di quei semi germoglierà quando incontrerai un problema simile in un lontano, lontano futuro.

Quindi, l'intervistatore è forse interessato alla tua abitudine di lettura (come parte del tuo hobby) e vedi se hai l'abitudine regolare di raccogliere semi di idee da luoghi casuali.

Il punto dietro a questo tipo di domanda è quello di ottenere una visione della tua mente. Una domanda comune che uso è di chiedere ai programmatori di progettare un sistema in grado di simulare PacMan.

E sì, cerco prima i casi d'uso, mi mostra che la persona sta pensando. Quindi, per il multithreading, considerare prima le strutture di dati (quelle che potrebbero essere utilizzate per il problema, quindi quelle più appropriate o specifiche con i motivi della decisione).

Questo è un must per le posizioni di sviluppo senior. È sciocco e inutile per le persone sedersi e rispondere alle domande sulle implementazioni di ordinamento a questo livello di esperienza degli sviluppatori. La progettazione del sistema è ciò che mi aspetterei a questo livello.