Una domanda comune in Tech Interview è progettare un particolare sistema, di solito un prodotto esistente dell'azienda. Ad esempio, "Progetta Google Documenti".
Qual è la risposta prevista per una domanda del genere? Voglio dire, questi sistemi hanno sicuramente un design complesso che va oltre lo scopo di ogni intervista. Quali sono gli intervistatori che si aspettano in così poco tempo?
Scopri come il tuo cervello guarda questo problema. Qui ci sono alcuni punti di partenza che ho potuto vedere per come si potrebbe provare ad avere questa conversazione:
dall'alto verso il basso - Guardare dall'alto un livello molto alto costruisci un design e arricchisci il design con il completamento di vari componenti e qui ci sono una manciata di componenti che potrei vedere ....
Bottom-up - Guardando da zero, ecco alcuni pezzi che potresti costruire per provare a mettere insieme ....
Chiarimento dei requisiti: porre domande sulla scala, le dimensioni, il budget e il team proiettati utilizzati per questo progetto. Potresti provare ad avere un codice di persona un elaboratore di testi molto semplificato oppure puoi pianificare di 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 è la possibilità di chiedere qualcosa del tipo "Cosa intendi con Google Doc? Quanta funzionalità vuoi duplicare?" domande pure.
La chiave è quanto riesci a comunicare i tuoi pensieri e il tuo approccio nell'affrontare questo tipo di problemi in quanto potresti farti avvicinare da un utente e chiedere: "Psst, potresti fare qualcosa di simile in 2 settimane?" quello potrebbe realmente accadere. Pertanto, in che modo hai dato la risposta è più importante di quale è la risposta.
La mia opinione personale sarebbe che i progetti passati non sono una buona idea qui. Quello che si sta cercando di trovare è quale tipo di creatività e capacità di comunicazione in un'area nuova piuttosto che ricordare semplicemente come qualcosa è stato fatto in passato. È probabile che mentre qualcosa che accade nella nuova posizione possa essere simile a qualcosa del passato, potrebbero esserci differenze sufficienti che la vecchia soluzione non è fattibile. Questo è il motivo per cui mentre ciò che può essere costruito è simile a un'applicazione esistente, potrebbero esserci varie personalizzazioni che rendono la soluzione molto diversa dall'esempio iniziale.
Le interviste sono una strada a doppio senso. I manager e altri sviluppatori sono raramente padroni delle interviste quindi non sono sicuro di vedere il valore nel provare a dichiarare che dovrebbero essere esperti in materia nelle interviste di lavoro. I reclutatori vedevo in attesa di sapere come fare un'intervista, ma ci sono un sacco di reclutatori 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 buone. 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 svolgere una serie di attività interessanti per l'intervistatore:
Questa domanda è solo una versione di livello superiore di "Descrivi la gerarchia dell'oggetto che useresti per questo." "Descrivi l'interfaccia che avresti progettato per questo." "Progetta una serie di tabelle DB relazionali per questi dati ...", ecc. Che verrebbero fornite agli 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 quello che fanno di fronte a un grosso problema che potrebbe essere schiacciante.
Si tratta di vedere i tuoi processi mentali in azione; non sono interessati a una soluzione, ma come affrontate la soluzione del problema, quali domande porre, quali problemi identificherebbero, ecc.
Dato l'esempio di Google Docs, i problemi ovvi che vengono in mente sono cose come archiviazione, sicurezza, scalabilità, disponibilità, design dell'interfaccia client, compatibilità con i browser, ecc. Come divideresti le responsabilità tra server e client? Come gestiresti i backup? Cosa succede quando un server va giù? Cosa faresti con i documenti "abbandonati" (cose che non sono state consultate o modificate in un lungo periodo di tempo)?
Ancora una volta, il punto non è quello di risolvere nessuno di questi problemi, ma di identificarli , parlarne, fare un brainstorming su come affrontarli, ecc.
Sono una di quelle parti colpevoli che spesso fanno questo tipo di domande nelle interviste. (Per la cronaca, faccio anche domande simili sul loro "progetto preferito".) Il motivo per cui lo chiedo è che è qualcosa che facciamo spesso qui intorno. Otteniamo ingegneri progettisti da tutti i lati di un'interfaccia, qualcuno dall'ingegneria dei sistemi, qualcuno dai test e qualcuno con una certa conoscenza dei casi d'uso del cliente per la funzionalità. Ci fermiamo intorno a una lavagna e diciamo "Ok, come costruiremo questa cosa?" Spesso a questo punto si conosce molto poco della nuova funzione e ci si trova solo per la propria esperienza nella propria parte del sistema, ma si è comunque tenuti a contribuire in modo produttivo. Non è solo un ipotetico esercizio accademico.
Per quanto riguarda il tipo di risposte che mi aspetto, prendi 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 ci sia pochissima capacità inutilizzata sul collegamento tra il server e le schede di linea.
Risposta errata:
Um, I would probably use ethernet or something like that.
Buona risposta:
How large an image are we talking about? [Around 7 MB.] Well, you'd want to make sure service wasn't affected during the download. You'd need extra flash or RAM to store two images at once. You'd probably want to cache the image on your line cards in order to avoid downloading the same image over and over from the server. Being embedded, your line cards probably have limited CPU themselves, so you might need to serialize the downloads in order to leave enough capacity for service. You'd want some way to verify the image was good and fall back to the old version if it didn't work. You'd need some way to retry a few times and report errors to a human if the upgrade fails. If you have different brands of set top boxes, you'd need some kind of way to identify which image you need to send it.
Quelle sono quasi trascrizioni parola per parola di due candidati diversi. La maggior parte dei candidati è una via di mezzo, ma di solito arriva alla fine con un piccolo suggerimento, che è perfettamente a posto. Non stiamo cercando il prossimo Einstein qui, solo un'indicazione che puoi ragionare in modo intelligente sui tipi di problemi su cui lavoriamo ogni giorno.
Chiedo anche questo tipo di domande 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 dover prendere una decisione aziendale importante e, per farlo, dobbiamo costruire un nuovo sistema. Se qualcuno si avvicina a te e ti chiede cosa ci vorrebbe per costruire un sistema che fa X, puoi dare loro una risposta perspicace che preannunci 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 esperto vedrà immediatamente che ci sono molti aspetti del problema e tenterà di affinare una sfida. Non devi architettare ogni aspetto, basta identificare una sfida architettonica e poi capire come affrontarlo.
Considera il problema di Google Documenti:
Una cosa interessante è la scala di taglio delle richieste che arriveranno. Non si può semplicemente ottenere un singolo server e distribuire il codice su di esso, si tratta di un'impresa più grande. Un intervistato di successo potrebbe azzerare ciò e descrivere i tipi di risorse che saranno necessari, e alcune delle sfide tecniche nell'implementazione a tale livello, con un'applicazione che non solo ha lo stato, ma condivide lo stato tra più utenti.
Un'altra cosa interessante di Google Docs è che più persone possono modificarle 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 comprenderà che i diversi metodi di sincronizzazione o fusione delle modifiche avranno un grande impatto sulle prestazioni e sulla UX. Forse anche discutere delle varianti: un editor di documenti condiviso per scrivere codice dovrebbe probabilmente utilizzare un metodo diverso per risolvere i conflitti rispetto al tipico documento Google, perché ci sono diverse conseguenze su cose che accadono in un ordine diverso o con una struttura leggermente diversa.
Non esiste un unico modo giusto per creare un'app come Google Docs, non devi identificare cosa faresti per ogni trade-off, ma è davvero fantastico trovare un'area che ha un problema interessante e spiegare chiaramente quali potrebbero essere i trade-off.
-t.
Sospetto che ciò che gli intervistatori vogliono sentire sia:
Google Doc is a web interface for a word processor. User documents are typed and stored, and are retrievable by the user on the same or a different computer.
What would you like to discuss further?
Quindi, la palla è nel campo dell'intervistatore. Se vuole più 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à.
In seguito, dovrebbero essere in grado di trovare una soluzione architettonica basata sui casi / storie di utilizzo chiave. Si spera che abbiano usato un processo sistematico per identificare i moduli diversi da quelli che li hanno estratti ... Non mi aspetterei molto di più da una situazione di intervista per la soluzione.
Tuttavia, potrei scegliere uno dei moduli architettonici e chiedere un disegno più dettagliato, solo per vedere se hanno alcune capacità di progettazione. Sarebbe anche bello vedere che considerano i casi di insuccesso / problemi di prestazioni. Ma sospetto che a questo punto ci troveremmo in un muro temporale. Quindi, non potrei davvero penalizzarli per non aver preso in considerazione questi problemi perché c'è solo così tanto tempo e penso sia ragionevole per loro presumere che considerando ogni possibile scenario non ci si aspetti da una situazione di intervista limitata nel tempo.
Recentemente ho avuto un colloquio in cui mi è stato chiesto di progettare un sistema di controllo per ascensori. Fondamentalmente vogliono vedere il tuo approccio al compito. Se ti viene posta questa domanda, probabilmente hanno in mente un lavoro di altissimo livello per te. Complimenti.
La cosa fondamentale è come risolvi i problemi rispetto ai meriti della soluzione che offri, e se sei in grado di affrontare problemi di grandi dimensioni.
Penso che una cosa importante da fare sia porre domande sui requisiti. Non limitarti a fare supposizioni che consentiranno al tuo animale domestico di funzionare. Ad esempio, potrebbe capitare di conoscere un metodo davvero ingegnoso per la stampa di documenti che potresti essere tentato di saltare a descrivere. Ma Google Docs non stampa direttamente; produce un PDF che il cliente quindi stampa. Quindi, se inizi con questo, avrai perso metà del tuo tempo per risolvere un problema che non è parte del problema e hai dimostrato che sei più interessato a utilizzare la tua tecnologia più calda che a risolvere il problema del cliente.
Per gestire questo tipo di domande per il colloquio, è necessario avere un interesse generale a capire "come funzionano le cose", non solo nei progetti a cui sei interessato, ma anche a progetti che ritieni siano troppo lontani dalle tue esperienze .
Questo significa leggere blog, articoli, link , 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 personale), potrebbero esserci alcune curiosità che sono i "semi dell'immaginazione", e una piccola frazione di quei semi germogli quando incontri un problema simile nel lontano, lontano futuro.
Quindi, l'intervistatore è forse interessato alla tua abitudine di lettura (come parte del tuo hobby) e verifica se hai l'abitudine di raccogliere semi di idee da luoghi casuali.
Il punto dietro a questo tipo di domande è quello di ottenere una visione della tua mente. Una domanda comune che uso è chiedere ai programmatori di progettare un sistema in grado di simulare PacMan.
E sì, prima cerco casi d'uso, mi mostra che la persona sta pensando. Quindi, per il multithreading, considerare prima le strutture dati (quelle che potrebbero essere utilizzate per il problema, quindi quelle più appropriate o specifiche con i perché della decisione).
Questo è un must per le posizioni di sviluppo senior. È sciocco e inutile che le persone si siedano e rispondano alle domande su implementazioni di ordinamento a questo livello di esperienza degli sviluppatori. Il design del sistema è quello che mi aspetterei a questo livello.
Leggi altre domande sui tag interview