Mi rendo conto che ci sono state molte discussioni su questo tipo di cose e spesso si trasformano in dogmi in giro, sia che si chieda il tipo di domande "100 pirati logici" sia che si scriva "fizz buzz".
Sono interessato a quali tecniche e domande sono state efficaci per tu quando intervisti potenziali sviluppatori per lavori.
Una tecnica per risposta in modo che possiamo votare su di loro, per favore.
Oltre alle vere domande tecniche e in genere alla fine dell'intervista, cerco di comprendere il loro livello di interesse nel settore e la sua cultura con domande del tipo:
Hai visto qualcosa di recente correlato alla programmazione che hai trovato interessante e vorresti raccomandare ad altri colleghi programmatori? Un nuovo linguaggio, strumento, piattaforma, tecnica, sito web?
Puoi nominare una persona ben nota nel nostro settore di cui ti piace o che ritieni stimolante e perché? (sviluppatore, fondatore di siti web, autore, oratore, ecc.)
Cosa stai leggendo ora o quale era l'ultimo libro relativo al software che hai letto?
Quali siti di programmazione frequenti frequenti?
Anche se non rispondere a queste domande (purtroppo succede molto spesso) non significa "non assumere" per me, dicono molto sul modo in cui una persona si avvicina alla professione di sviluppo del software.
Fagli scrivere codice, codice reale.
L'intervistatore potrebbe permetterti di scegliere il linguaggio di programmazione con cui ti trovi più a tuo agio, sia C ++, Java, C # o qualsiasi altra cosa e chiederti di risolvere un semplice problema, ad es. facendo del lavoro con una stringa o una lista doppiamente collegata o altro. Se hai problemi ad usare la tua migliore lingua per risolvere un problema semplice, allora c'è un problema. Consulta il post del blog di Steve Yegge e in particolare la sezione "Mental Prep".
Chiedi a più persone della tua squadra di intervistarli in modo indipendente. Condividi i tuoi pensieri dopo, non parlare in mezzo prima di intervistarli. Parlare nel mezzo influenzerà il tuo giudizio e non avrai assise indipendenti.
Per le persone tecniche che intervistano li fanno scrivere codice. Per non tecnico, non provare a chiedere cose con cui non hai esperienza. Assicurati di avere almeno un po 'di tecnici intervistatori.
Le interviste non dovrebbero essere condotte solo dai manager, dovrebbe essere estremamente importante 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 quello che era lo scopo del progetto e quale problema di business questo risolto.
Lo faccio per vedere se riescono a articolare in un modo che mi faccia capire cosa stessero facendo, e vedere se hanno capito anche quello che stavano facendo.
È sorprendente che l'ultima domanda sullo scopo del progetto e il problema aziendale risolti faccia scattare un sacco di persone. Non hanno idea di PERCHÉ il progetto su cui stavano lavorando fosse stato fatto. Se non sai perché il tuo progetto esiste in primo luogo, mi chiedo se stai contribuendo alle soluzioni, o semplicemente facendo come ti è stato detto.
(Ho pensato di buttarlo 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 alla fine l'utente non si preoccupa di:)
Chiedigli di prendere una decisione architettonica importante
Ad esempio. Ecco il programma x che esegue il numero y di sottotask contemporaneamente. Quale sceglieresti, una struttura multi-processo o di threading.
Quali sono i vantaggi / gli svantaggi di entrambi. Quanto bene funzionerebbero e come potrebbero essere utilizzati per sfruttare una piattaforma multi-core e multiprocessore, 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 a cui un intervistatore potrebbe venire in questo modo:
La maggior parte di questi argomenti sono i tipi che implicano una conoscenza approfondita di come / perché un sistema di computer funziona come fa. Sono tutti problemi / soluzioni a problemi che non hanno una risposta definita, in modo che diano un'idea di quanto bene quella persona sia capace di adattarsi o superare le sfide a portata di mano. Non il tipo di concetti che possono essere facilmente acquisiti senza alcuna esperienza pratica.
Nota: Avere il candidato scrivere un codice pesudo è un must, ma la risposta è già stata presa.
Basta dare loro un codice base da fare sulla lavagna - ad es. implementazione lista collegata, ordinamento o qualcosa di simile.
Puoi giudicare quanto sono 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 tale cosa - la maggior parte dei "nuovi" programmatori non l'ha mai fatto).
Avere una conversazione, lasciarlo andare alla deriva e vagare lungo il percorso tecnico e professionale e cercare commenti perspicaci o stupidi lungo la strada. Questo ti porta a 3/4 di quello che ti serve da un'intervista, una valutazione di: abilità e personalità delle persone, intelligenza generale e una valutazione approssimativa delle competenze tecniche.
Usa le domande del tuo colloquio come topic starters e per mantenere la conversazione corrallata a argomenti tecnici - potrebbe essere necessario reimpostare la conversazione di volta in volta (come fare un esercizio di codifica) per sondare adeguatamente le aree di interesse / interesse.
Il vero trucco per questa tecnica è assicurarsi che loro facciano tutti i discorsi, altrimenti corri il rischio di una valutazione favorevole perché hanno fatto sì che tu si sentisse intelligente ascoltando per / concordare con tutto ciò che hai detto.