Mi rendo conto che ci sono state molte discussioni su questo tipo di cose e spesso si trasformano in dogmi se si pongono domande sul tipo di "100 pirati logici" o se si inducono a scrivere "brusio".
Sono interessato a quali tecniche e domande sono state efficaci per te quando hai intervistato potenziali sviluppatori per lavori.
Una tecnica per risposta in modo che possiamo votare su di loro, per favore.
Risposte:
Oltre alle vere domande tecniche, e in genere alla fine dell'intervista cerco di capire il loro livello di interesse nel settore e nella sua cultura con domande come:
Hai visto qualcosa di recente relativo alla programmazione che hai trovato interessante e vorresti raccomandare ad altri colleghi programmatori? Una nuova lingua, strumento, piattaforma, tecnica, sito Web?
Puoi nominare una persona ben nota nel nostro settore il cui lavoro ti piace o trova stimolante e perché? (sviluppatore, fondatore del sito web, autore, relatore, ecc.)
Cosa stai leggendo ora o qual è l'ultimo libro correlato al software che hai letto?
Quali siti di programmazione frequenti?
Anche se non riuscire a rispondere a queste domande (purtroppo accade molto frequentemente) non significa "non assumere" per me, dicono molto sul modo in cui una persona si avvicina alla professione di sviluppo del software.
Falli scrivere codice, codice reale.
L'intervistatore può lasciarti scegliere il linguaggio di programmazione con cui ti senti più a tuo agio, sia esso C ++, Java, C # o qualsiasi altra cosa e chiederti di risolvere un semplice problema, ad esempio fare un po 'di lavoro con una stringa o un elenco doppiamente collegato o altro. Se hai problemi ad usare la migliore lingua per risolvere un semplice problema, allora c'è un problema. Si prega di consultare il post sul blog di Steve Yegge e in particolare la sezione "Preparazione mentale".
Chiedi a diverse persone del tuo team di intervistarli in modo indipendente. Condividi i tuoi pensieri dopo, non parlare tra prima di intervistarli. Parlare in mezzo influenzerà il tuo giudizio e non avrai valutazioni indipendenti.
Per i tecnici che li intervistano li fanno scrivere codice. Per i non tecnici, non provare a chiedere cose con cui non hai esperienza. Assicurati di avere almeno alcune persone tecniche che intervistano però.
Le interviste non dovrebbero essere condotte solo dai dirigenti, dovrebbero essere estremamente importanti per ogni lavoratore con cui lavoreranno in futuro.
Mi piace che un intervistato spieghi i loro progetti precedenti e cosa hanno fatto. Da questa risposta posso avere domande di follow-up: perché hanno fatto le cose in un certo modo, come hanno risolto un problema particolare se ne hanno menzionato uno, ma soprattutto quale era lo scopo del progetto e quale problema aziendale ha risolto.
Faccio questo per vedere se riescono ad articolarsi in un modo che mi faccia capire cosa stessero facendo, e vedere se capivano anche quello che stavano facendo.
È sorprendente che l'ultima domanda sullo scopo del progetto e sul problema aziendale risolto che inciampi molte persone. Non hanno idea del PERCHÉ il progetto a cui stavano lavorando era stato realizzato. Se non sai perché il tuo progetto esiste in primo luogo, mi chiedo se stai contribuendo soluzioni o semplicemente facendo come ti viene detto.
(Ho pensato di lanciarlo qui, poiché tutte le altre risposte tendono ad essere tecniche. Voglio che le persone sappiano perché stanno risolvendo i problemi che stanno risolvendo, altrimenti tendono a risolvere i problemi sbagliati che l'utente finale non fa ' ci tengo a :)
Chiedi alla loro opinione su un'importante decisione architettonica
Per esempio. Ecco il programma x che esegue contemporaneamente un numero di sottoattività. Quale sceglieresti, una struttura multi-processo o threading.
Quali sono i vantaggi / gli svantaggi di entrambi. Quanto funzionerebbero e come potrebbero essere utilizzati per sfruttare una piattaforma multi-core e multi-processore, qual è la tua preferenza personale? I pregiudizi personali possono aiutare a identificare se hanno mai dovuto effettivamente applicare le conoscenze e dare loro un punto di partenza per condividere le loro esperienze?
Ci sono tonnellate di domande che un intervistatore potrebbe formulare come queste:
La maggior parte di questi argomenti sono i tipi che implicano una conoscenza intima di come / perché un sistema informatico funziona nel modo in cui funziona. Sono tutti problemi / soluzioni a problemi che non hanno una risposta definita, quindi danno un'idea di quanto bene quella persona è in grado di adattare o superare le sfide a portata di mano. Non è il tipo di concetti che possono essere facilmente ripresi senza qualche esperienza concreta.
Nota: anche far scrivere al richiedente un codice pesudo è d'obbligo, ma la risposta è già stata presa.
Fornisci loro un codice di base da eseguire sulla lavagna, ad esempio l'implementazione dell'elenco collegato, l'ordinamento o qualcosa di simile.
Puoi giudicare quanto siano a loro agio con il loro linguaggio senza l'aiuto del compilatore e puoi giudicare il loro processo di pensiero (specialmente se non hanno mai implementato una cosa del genere - la maggior parte dei "nuovi" programmatori non l'ha mai fatto).
Fai una conversazione, lascialo andare alla deriva e serpeggiare lungo il percorso tecnico e professionale e cerca commenti perspicaci o stupidi lungo la strada. Questo ti dà 3/4 di ciò di cui hai bisogno da un'intervista, una valutazione di: abilità e personalità delle persone, intelligenza generale e una valutazione approssimativa delle abilità tecniche.
Usa le "domande" del tuo colloquio come argomento iniziale e per mantenere la conversazione correlata ad argomenti tecnici - potresti dover ripristinare la conversazione di tanto in tanto (come fare un esercizio di codifica) per sondare adeguatamente le aree di interesse / interesse.
Il vero trucco per questa tecnica è quello di assicurarsi che fanno tutto il parlare, altrimenti si corre il rischio di una valutazione favorevole perché hanno fatto si sente intelligente ascoltando / d'accordo con tutto quello che hai detto.