Come vengono applicate le competenze utilizzate nelle domande di intervista tipiche nel lavoro reale? [chiuso]

Per i lavori di sviluppo di app SQL e C #, gli intervistatori di solito pongono domande su alberi, grafici e attraversamenti di elenchi collegati usando C e puntatori puri. Nei 3 anni trascorsi nel mio lavoro, in realtà non ho mai dovuto farlo

trova il percorso del 1 ° nodo alla destra di un dato nodo che è un multiplo del nodo dato

per esempio

Vedo che queste competenze potrebbero essere utilizzate in lavori in cui è necessario scrivere compilatori, driver e lavorare sul kernel del sistema operativo. Oltre a quelli, dove altro vengono utilizzate queste abilità?

Leggi alcune delle risposte di Joel qui sotto.

Soprattutto notare qualcosa come Schmiel, il pittore. Sul lavoro, potresti non dover mai riscrivere un elenco collegato, ma sicuramente dovresti sapere come funziona, in modo da poter evitare Schmiel.

Fondamentalmente, se vai dal dottore, vorresti che quel dottore avesse studiato anatomia. Anche se lei ti sta solo prescrivendo un po 'di antistaminico, un dottore avrà imparato a scuola che alcuni farmaci sono dannosi per le persone con un "cratosos diamadabada cronico al femore inferiore" o qualsiasi altra cosa. Questo tipo di conoscenza approfondita di TUTTO in quella specialità a volte può fare la differenza tra vita e morte, e nella tecnologia dell'informazione tra vita e morte del prodotto, o un lavoro.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... passa almeno un semestre ad avvicinarti alla macchina o non sarai mai in grado di creare codice efficiente in lingue di livello superiore ..."

"... stai programmando in base alla superstizione, per quanto mi riguarda: un medico che non conosce l'anatomia di base, distribuendo le prescrizioni in base a ciò che la bambina delle vendite farmaceutiche avrebbe funzionato."

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Loro non sono. Molte interviste sono fatte da persone che non sanno come cercare abili sviluppatori e non sanno quali domande dovrebbero o non dovrebbero fare.

La maggior parte degli intervistatori non pone affatto domande tecniche e sono più concentrate su cose insignificanti ma misurabili , come il numero di progetti a cui hai partecipato (più è meglio per quegli intervistatori) o il diploma universitario (più alto è meglio per loro ). Sono felici di assumere una persona che ha perso cinque anni al college senza imparare nulla e poi ha trascorso dieci anni facendo dozzine di siti Web di e-commerce, ma non assumerà una persona che ha abbandonato il college dopo alcuni anni e stava lavorando su alcuni grandi progetti tecnicamente impegnativi.

Fare almeno domande teoriche è meglio che non farle. Ciò ha il vantaggio di verificare che la persona abbia sufficienti conoscenze teoriche e non è un programmatore che può avere qualche anno di esperienza con la programmazione, ma non capisce davvero cosa sta succedendo sotto il cofano. Gli sviluppatori che di solito non hanno questa conoscenza teorica ¹ non conoscono la differenza tra un elenco, un elenco collegato una ricerca o un insieme di hash e li usano in modo intercambiabile.

Domande buone (tecniche), domande cattive

Durante le interviste, potresti incontrare domande che vanno da molto buone a estremamente cattive:

1. (Nocivo) "Qual è la lunghezza delle righe del programma di lavoro più lungo che hai scritto in quella lingua?"

   Questa domanda è chiaramente sbagliata. Ho già spiegato perché in un'altra risposta . La società in cui gli intervistatori pongono tali domande ha forti possibilità di valutare la produttività degli sviluppatori in LOC / mese. Se devo dare un consiglio: non hai bisogno di un simile lavoro.

   Questo esempio è diverso dalle cose insignificanti ma misurabili che ho citato all'inizio della mia risposta. Qui, l'intervistatore mostra anche che non ha nemmeno la comprensione più elementare delle metriche scegliendone una che è ben nota per essere dannosa.

2. (Bad) "Chi è Dennis Ritchie?"

   Avere almeno un po 'di cultura è davvero molto utile, ma porre quella domanda non ha senso. Se la società cerca sviluppatori di talento in grado di gestire progetti di sviluppo software e scrivere codice, il fatto che non conoscano il nome della persona che ha creato C e Unix non dovrebbe importare troppo.

3. (Buono) "Quali sono le nuove funzionalità di .NET 4.5?"

   Questa domanda è molto più interessante di quella su Dennis Ritchie. Se il candidato non può parlare di nuove funzionalità in .NET 4.5, perché si definisce sviluppatore C #? La mancanza di tale conoscenza:

   • Mostra che la persona potrebbe non essere realmente interessata né al linguaggio di programmazione né alla comunità .NET,

   • Indica che alla persona potrebbero mancare alcune conoscenze cruciali sulle funzionalità di C # /. NET che altri sviluppatori usano se non quotidianamente, almeno frequentemente.

   Vedi anche la risposta di Jerry Coffin che contiene un'analisi più dettagliata di questo tipo di domande.

4. (Media) "Quale è più veloce, SSD o RAM?"

   Questo potrebbe essere utile e mostra se la persona ha abbastanza conoscenze hardware, ma comunque, un candidato che non può rispondere a questa domanda non dovrebbe essere respinto.

5. (Media) "Come vengono implementati stack e coda?"

   Questo è il tipo di domande di cui parli. Sono teorici, forse anche troppo teorici, ma sapere cosa succede sotto il cofano può aiutare a scrivere codice migliore.

   Non rifiuterei un candidato che non è in grado di rispondere a questa domanda, ma controllerò più attentamente se conosce davvero le cose, ad esempio ponendo una domanda correlata ma meno teorica:

6. (Bene) "Come puoi camminare attraverso un albero senza ricorrere alla ricorsione?"

   Se il candidato risponde a questa domanda, parlando di FILO / FIFO e dei vantaggi e degli svantaggi dell'utilizzo di una pila rispetto a una ricorsione per l'attraversamento di alberi, non importa che non sia stato in grado di rispondere alla domanda precedente.

   Fare questa domanda è anche un buon modo per individuare candidati che hanno trascorso anni a conseguire la laurea in CS, ma non hanno esperienza sul campo.

Come porre buone domande tecniche?

Il commento di Kojiro è interessante e merita una risposta più lunga:

A volte è necessario assumere qualcuno proprio perché dovrebbero sapere di più su un argomento di te, quindi per definizione sei sottoqualificato per fare il colloquio. Non puoi ottenere assistenza in modo affidabile nemmeno facendo l'intervista per lo stesso motivo. Il meglio che puoi fare è provare a porre domande in base a dove la tua comprensione si interseca con il dominio problematico e spero che tu sia fortunato.

Trovare buone domande può essere difficile, specialmente quando assumi il tuo primo sviluppatore o quando assumi uno sviluppatore che dovrebbe essere più abile di tutti gli sviluppatori che lavorano effettivamente nell'azienda.

Ecco tre suggerimenti che possono aiutare:

1. Trova un amico / collega si crede di essere abili e chiedere a lui di fare le recensioni. Ciò richiede molta fiducia, ma può essere di grande beneficio per la tua azienda.

2. Trova un consulente che ritieni competente e chiedigli di aiutarti o di fare la parte tecnica del colloquio.

3. Digita "domande di intervista" su Google. Funziona abbastanza bene e di solito spiega possibili risposte. Esempio:

   • Python : quelle dieci domande sembrano abbastanza buone. Sono forse un po 'di base, ma aiuteranno a filtrare il 95% dei candidati che non vuoi assumere comunque.

   • SQL di Dave Pinal, eccellente come al solito.

   • C # : un po 'troppo semplice, ma ancora una volta, filtreranno il 95% dei candidati,

   • JavaScript : le domande sono più aperte, il che potrebbe non essere una buona cosa per le domande tecniche se vuoi che l'intervista sia breve e ti riservi più tempo per le domande non tecniche aperte. L'elenco aiuta ancora a filtrare facilmente i candidati che non comprendono i concetti di base in JavaScript.

   Lo svantaggio di questo approccio è che il candidato può utilizzare la stessa tecnica per allenarsi per il colloquio. Se ha esaminato ogni domanda del primo sito Web che ha trovato su Google, potrebbe ottenere un buon punteggio, senza avere effettivamente le competenze richieste.

^{¹ Ci sono alcuni sviluppatori che non saranno in grado di spiegare cos'è un albero B (a parte il fatto che si tratta di "una struttura di dati"), ma sono ancora in grado di svilupparsi correttamente.}

Dalla mia esperienza nella mia azienda in cui ho fatto molte interviste, ci sono buone probabilità che l'intervistato non abbia idea di come farlo correttamente. Quindi hanno preparato una serie di domande tecniche, ne hanno calcolato un punteggio e hanno reso il tuo curriculum. Ciò ha tuttavia molti inconvenienti e non dovrebbe essere fatto per i seguenti motivi:

• Chiedete conoscenza puntuale. Se il programmatore non ha mai fatto qualcosa in quella zona, potrebbe comunque essere un eccellente collaboratore, ma proprio non conosce quella particolare risposta. Al contrario: se qualcuno si fosse preparato per l'intervista e avesse trovato la risposta a quella particolare domanda in rete, si ottiene la risposta giusta, ma quella persona potrebbe non avere la minima idea dell'argomento reale.

• Le persone sono nervose durante le interviste di lavoro. Il cervello ha questa grande funzionalità per chiudere molte aree di livello superiore (come la logica) se in preda al panico, il che significa: se sei nervoso, potresti non fornire la qualità delle risposte che avresti in una situazione quotidiana. Alcune persone possono affrontare una situazione stressante come un'intervista, molti no.

• Con un'unica risposta corretta, metti alla prova l'abilità delle persone a trovare quella risposta particolare. Questa è una delle molte competenze di cui ha bisogno un collega, ma non quella e solo richiesta. Pertanto una o due di queste domande dovrebbero essere sufficienti per testare quell'area di conoscenza e quindi dovrebbero essere interrogate altre abilità. Un'intervista che contiene solo domande per la risoluzione dei problemi mette alla prova la stessa abilità ancora e ancora.

Quali sono le buone domande sulle attività di programmazione?

Quelle famose domande "Can you write a short program" hanno l'enorme problema che la maggior parte dei programmatori non può scrivere una singola riga di codice senza che il loro IDE li aiuti. Ma questo non è affatto un problema nelle situazioni lavorative quotidiane, perché il programmatore ha sempre il suo IDE che lo aiuta. Quindi, chiedendo cose come "Trova l'errore", "Scrivi 50 righe di codice che fanno ..." o anche semplici domande devono tenere conto del fatto che il richiedente non ha i suoi strumenti (IDE, Google) disponibili.

Ad esempio, posso rispondere praticamente a qualsiasi domanda entro 1 minuto se Google mi aiuta, ma senza connessione Internet mi sembra impotente. Io chiamo quella memoria esternalizzata e, invece di ostacolarmi, mi aiuta molto a concentrarmi su ciò che è veramente importante - comprendere la meccanica di base - perché tutto il resto può essere cercato. Ma non chiedermi i dettagli di qualsiasi API casuale, perché non li conosco, ho Google per questo.

Detto questo, una buona domanda relativa alle attività di programmazione non dovrebbe concentrarsi sulla conoscenza delle API o su speciali capacità di codifica, a meno che questo non sia un requisito assoluto per il lavoro. È possibile acquisire conoscenze, quindi è meglio scoprire quanto è brava quella persona ad acquisire conoscenza piuttosto che chiedersi ciò che già sa.

Una buona domanda per un'attività di programmazione dovrebbe essere breve, semplice, in grado di essere codificata in ogni lingua con solo poche righe di codice e, soprattutto, dovrebbe dirti il ​​più possibile su come la persona lavora e trova le risposte. Esempio:

"Scrivi una funzione nella lingua che preferisci che prende una matrice di numeri interi e li riordina in modo che il primo numero intero sia dopo l'ultimo, e tutti gli altri si spostino di conseguenza."

Il primo che un candidato dovrebbe chiedere a questo punto è: "Mi dispiace ... puoi per favore spiegare il compito?". Perché a nessun programmatore è stata data una descrizione chiara di cosa fare mai. Questo è seguito dalla spiegazione, che il codice nelle domande dovrebbe fare uno spostamento a sinistra del contenuto dell'array con l'overflow aggiunto a destra.

Questo compito è così semplice che chiunque abbia conseguito una laurea in qualsiasi livello di programmazione dovrebbe essere in grado di rispondere correttamente. Ciò tiene conto del fatto che il programmatore deve lavorare senza i suoi strumenti e che essere nervoso riduce la capacità di pensare logicamente. Tuttavia, ti dice ancora come le persone risolvono i problemi solo dal modo in cui la domanda è formulata e dal modo in cui le persone si avvicinano, semplicemente perché uno spostamento a sinistra è contrario al comune istinto "da sinistra a destra" e costringe le persone a pensare un secondo.

Ci sono molte possibili risposte a questa domanda, quindi dare un'occhiata da vicino al modo in cui il codice è sviluppato è la parte importante, non se la soluzione funzionasse davvero. Il richiedente verifica null? Come viene archiviato l'overflow? Viene utilizzato un loop o un mem-set? In che modo il richiedente verifica la correttezza del codice? Questa semplice domanda ti dice un'intera biografia su come funziona quella persona.

Quali sono le domande di buona conoscenza generale?

Le domande valide sono facili da rispondere, consentono una grande quantità di risposte (le cosiddette "domande aperte") e consentono di apprendere il più possibile sul candidato nel minor tempo possibile.

Esempi:

(Chiedere a un programmatore C ++): "Quali altre lingue oltre a C ++ conosci?"

Questa è una domanda di livello base, che offre al richiedente la giusta possibilità di salvare in questo momento se non fosse a conoscenza dell'argomento richiesto. Un 'no' a questo punto è meglio che tormentarlo con molte altre domande a cui tutti devono rispondere: "Mi dispiace, non ne so nulla."

Inoltre, ti dice innanzitutto quali altre lingue conosciute da quella persona, inoltre impari quanto è interessata quella persona ad avere una visione più ampia del mondo della programmazione, o se hai qualcuno con un solo linguaggio singolare (e quindi funzionalità / tecniche ) Visualizza.

(Successivamente, diciamo che conosce Java): Quali sono le tre principali differenze tra C ++ e Java secondo te? "

Questa è una domanda aperta che consente molte risposte, quindi il richiedente ha buone possibilità di trovarne almeno tre. Chiedere i primi tre (opinione personale) non solo limita le possibili risposte, ma costringe anche il richiedente a ordinare in base alla priorità. Tuttavia è (o dovrebbe essere) facile rispondere.

Questa è una semplice domanda che mette alla prova molte conoscenze approfondite sui diversi linguaggi di programmazione. Quanto è profonda la conoscenza di questi argomenti? Da queste risposte puoi dire molto sulla conoscenza e sull'effettiva comprensione della meccanica di base dei linguaggi di programmazione. Quanto ha speso quella persona con i dettagli sporchi, o se è solo qualcuno che collega tra loro varie funzioni API senza avere la minima idea di cosa accada al di sotto di esse.

Questo concetto di domande entry-level seguito da semplici domande di approfondimento può essere utilizzato anche per la maggior parte degli altri argomenti. Sempre in questo schema: domanda di salvataggio, domanda di verifica, domanda approfondita. Un altro esempio (da un'intervista a Java):

1. "Come valuteresti la tua esperienza con lo sviluppo multi-thread?"
2. "Per favore, nomina quelle che ritieni siano le tre cose più importanti da considerare nello sviluppo di un'applicazione multi-thread."
3. "Indica tre classi dell'API Java che possono aiutarti nello sviluppo di tali applicazioni e fornire una breve descrizione del loro utilizzo."

Queste tre domande ti diranno più di qualsiasi domanda tecnica cosa il richiedente sappia veramente di quegli argomenti, pur essendo equo a rispondere considerando la conoscenza del punto e il livello di stress.

Quindi la prossima volta che qualcuno ti pone 20 domande di programmazione di seguito, sai che non ha praticamente idea di come intervistare qualcuno in modo corretto. ;)

Attenzione: questo è scritto come (una specie di) commento sulla risposta di @ MainMa, ma 1) è troppo lungo per inserirsi in un commento, e 2) Penso che aggiunga una prospettiva leggermente diversa su domande costruttive, quindi è una vera risposta in sé .

Nella sua risposta, @MainMa classifica "Quali sono le nuove funzionalità di .NET 4.5?" come una "buona" domanda.

Mi permetto di dissentire. Mentre lo ha definito, direi che questa è una domanda abbastanza mediocre nella migliore delle ipotesi. Una buona domanda sarebbe più simile: "In che modo il codice che scrivi oggi differisce dal codice che hai scritto N anni fa?" (per un valore di N inferiore agli anni di esperienza elencati nel curriculum, preferibilmente tra 3 e 5).

Come è stato definito, la domanda riguarda la memorizzazione. Questo candidato ha memorizzato completamente l'elenco delle funzionalità? Per diritto, colui che cita l'elenco di Microsoft nel modo più preciso dovrebbe essere il vincitore.

Ciò di cui dovresti preoccuparti è la sua programmazione. In che modo ha influito sul suo codice? Quale di queste funzionalità usa davvero ? Ancora più importante, mostra un buon giudizio su quando utilizzare quali nuove funzionalità e quando quelle più vecchie bastano perfettamente?

Il solo fatto di poter dire "LINQ" non ti dice praticamente nulla di utile sul candidato. Essere in grado di dire: "LINQ mi ha aiutato a rendere il mio codice molto più compatto e leggibile perché posso esprimere i concetti X, Y e Z in modo chiaro e diretto, dove in precedenza dovevo saltare i seguenti cerchi infuocati per fare quelle cose". (o qualcosa di simile) ti dice molto sul candidato, che tipo di codice scrive, il suo giudizio, la flessibilità e così via. Ti dà anche molte più opportunità per domande di follow-up su come questa persona pensa ai problemi, scrive codice, pensa al codice e così via. Infine, ti dà un'idea molto migliore se questo è un candidato che ha davvero N anni di esperienza o qualcuno che ha un anno di esperienza, ripetuto N volte.

Riepilogo: essere in grado di citare un elenco di funzionalità di alcuni anni fa è inutile e ti dice poco sul candidato che probabilmente sarà utile. I progressi del candidato come programmatore saranno probabilmente molto più interessanti, quindi è molto meglio chiederlo più direttamente.

La realtà è che la maggior parte delle attività quotidiane che la maggior parte degli sviluppatori svolgono nella loro vita professionale sono banali; Ciò significa che alcune delle domande che devi affrontare in un colloquio di lavoro potrebbero non affrontarti mai nella realtà, ma ciò non significa che non ci sia motivo di porle.

Supponiamo che ci sia una posizione aperta nella tua azienda e al momento stai intervistando persone. Hai già 20-30 sviluppatori in coda. Quindi come sceglieresti il ​​miglior candidato per quella posizione? Supponiamo che il compito più impegnativo che devono svolgere in quel lavoro sia aprire un file dal file system, leggere i dati riga per riga, modificarli leggermente e reinserirli nel file originale.

Chiederai loro come apriresti un file? Scommetto che non puoi vedere una grande differenza tra le risposte. Quindi devi trovare una soluzione per distinguere tra gli sviluppatori che sanno solo come aprire un file e quelli che possono sviluppare un'applicazione in tempo reale. Anche se non vuoi che costruiscano una simile applicazione, ma vuoi comunque assumere il miglior candidato.

Come qualsiasi altra cosa nella nostra vita, ci sono alcuni punti che ti rendi conto che devi andare e imparare di più. Se non sai cosa sia un elenco collegato, per me come programmatore, ciò significa letteralmente che non hai davvero raggiunto quel punto nella tua vita professionale per sentire che devi andare e imparare quella cosa specifica. Perché? Semplicemente perché non sei mai stato coinvolto in un progetto abbastanza grande da richiedere di migliorare le tue capacità fino a quel livello. Se sei a un livello base, potresti dire che non ho davvero alcuna esperienza lavorativa per questo specifico lavoro, ma comunque se lo sai significa che sei abbastanza motivato da metterti al di sopra della media almeno.

Le competenze richieste per svolgere questi compiti sono raramente importanti. Le competenze dimostrate nell'approccio alla risposta alla domanda e nel dialogo successivo sono il punto centrale.

Quando intervisto gli sviluppatori cerco (a) smart (b) che le cose vengano fatte (c) si adatteranno. C'è un livello base di conoscenze tecniche richieste per ricoprire qualsiasi ruolo, che deve andare con la volontà di imparare e acquisire nuove competenze. L'intervista riguarda il controllo di quelle caselle.

La mia preferenza è leggere il codice scritto da un richiedente. Non mi piacciono le domande fisse per l'intervista, ma forniscono qualcosa di cui parlare in assenza di codice. Preferisco chiedere informazioni su RAII o IOC o sull'implementazione di IDisposable piuttosto che su elenchi e raccolte, ma tutto farà finché sarà possibile ottenerlo abbastanza tecnico .

La peggior paura dell'intervistatore è di assumere qualcuno che in realtà non sa molto di programmazione. Devi parlare di qualcosa di diverso dall'esperienza di lavoro per eliminare i falsi.

Queste domande riguardano lo screening delle persone che non possono programmare. A volte le persone che non sono in grado di programmare ma che conoscono molte curiosità fanno domanda per i lavori di sviluppo e che far loro scrivere qualcosa di utile e non banale richiede troppo tempo per un'intervista.

Vedo che queste competenze potrebbero essere utilizzate in lavori in cui è necessario scrivere compilatori, driver e lavorare sul kernel del sistema operativo. Oltre a quelli, dove altro vengono utilizzate queste abilità?

Che ne dici di scrivere motori di ricerca, server Web, browser Web, elaboratori di testi, fogli di calcolo, editor di immagini, programmi di disegno, server di database, bioinformatica, programmi di trading, giochi, simulatori di fisica e così via e così via.

Ti garantirò che la maggior parte dei lavori software comporta l'estrazione di dati da un database, la loro creazione su uno schermo, la loro modifica, la loro rimozione dallo schermo e la reinserimento in un database. Tuttavia, anche in questo caso, potresti eventualmente imbatterti in un'applicazione in cui i vincoli non possono essere soddisfatti dalle funzionalità integrate di una piattaforma. A quel punto puoi rinunciare o accedere alla tua cassetta degli attrezzi di algoritmi e strutture di dati e provare a risolvere il problema.

Gli oggetti teorici sono usati per comodità perché dovresti sapere di cosa tratta un'implementazione media di albero / grafico / elenco, quindi sai come risolvere un problema di attraversamento casuale, ma queste domande non riguardano affatto gli oggetti teorici.

Si tratta di essere in grado di lavorare con un modello astratto, comprendere un problema astratto e risolverlo con un algoritmo di qualunque tipo. Questa è pura abilità di sviluppo lì, quindi conta sicuramente. Questo è il motivo per cui queste domande hanno un senso, non perché si suppone che siano precise situazioni di vita reale.