Esempi di codice e interviste? [chiuso]

Ho visto una serie di domande da quando sono stato qui in cui, nella risposta, qualcuno ha affermato che non avrebbero mai usato portafogli o campioni di codice codificati al di fuori del processo di intervista per giudicare un candidato, perché esiste la possibilità che il codice è stato scritto da qualcun altro. Mi trovo sorpreso da questo.

Per come la vedo io, se chiedo a qualcuno di entrare e risolvere un semplice problema sul posto, c'è molto poco che posso imparare da esso. Non lavoro per un'azienda come Google in cui vengono cercati posti di lavoro e posso richiedere un giorno del tempo di qualcuno. Ma una parte sostanziale di codice scritto per hobby può dirmi molto.

Sì, esiste la possibilità di plagio, ma dovranno essere ben addestrati per superare un'ora di discussioni su quel codice. E in tal caso, dovranno essere degli studenti molto veloci per superare la loro prova di 3 mesi (durante la quale posso liberarmene senza motivo e senza preavviso). Se diventano buoni programmatori così rapidamente, abbastanza equamente, sono stato ingannato, ma ho ancora un buon programmatore.

Alla fine, il costo per la nostra azienda e il beneficio per il candidato del plagio sono molto minimi.

Questo mi ha fatto pensare ad altri settori. Artisti, fotografi, designer usano tutti i portafogli e nessuno si preoccupa troppo del plagio lì. Un autore verrà finanziato per un libro basato sui capitoli che ha scritto a suo tempo. Non chiederesti a un architetto di entrare e disegnare le specifiche di progettazione per una casa durante l'intervista.

Quindi cosa ci rende diversi? Perché è così importante mettere qualcuno di fronte a un computer e fargli codificare un'unione di dati o una calcolatrice fattoriale, a volte senza accesso agli strumenti che usiamo quotidianamente, come Internet? Cosa c'è di sbagliato nell'idea di un portafoglio di codici?

Sono sinceramente interessato a saperlo, nel caso in cui sto potenzialmente commettendo un grosso errore che non mi ha ancora bruciato.

La mia obiezione a un portafoglio non ha nulla a che fare con il rischio che la società venga ingannata da qualcuno che sta copiando il codice da Internet o, più probabilmente, passando il codice scritto da un team di sviluppatori come loro lavoro. Come giustamente fai notare, puoi imparare almeno tanto avendo uno sviluppatore a parlare di un progetto che hanno generalmente familiarità per un'ora come puoi facendo loro codificare una calcolatrice fattoriale da zero.

La mia obiezione a un portafoglio è che richiedere un portafoglio elimina molti sviluppatori di talento dalla considerazione. Dal momento che, a differenza di un artista o fotografo, non mantengo il copyright del codice che produco - appartiene al mio datore di lavoro e / o alla ditta che ha stipulato un contratto con il mio datore di lavoro - Non posso mostrare la stragrande maggioranza dei " "codice interessante che ho scritto. Se sto programmando il mio tempo libero, in genere sarà un progetto secondario sul lavoro che mi semplifica la vita o che mi infastidisce e che di nuovo non sarò in grado di mostrare in un portfolio. Ho tonnellate di post in vari forum, ma la maggior parte di questi sono, in base alla progettazione, relativamente superficiali. C'è una popolazione piuttosto consistente di solidi sviluppatori che si trovano in una posizione simile: il loro codice interessante è di proprietà di qualcun altro. E se tu'

Un'intervista tecnica in cui a tutti i candidati viene richiesto di codificare qualcosa da zero fornisce almeno condizioni di parità. Supponendo che tu faccia un lavoro ragionevole nel fare lo schermo del telefono e che tu possa restringere i candidati a un elenco ragionevole, preferirei piuttosto che un candidato ricevesse un problema per risolvere che sai che ci vorranno 8 ore di sforzo piuttosto che inventare un portafoglio coerente di app giocattolo senza problemi di copyright.

Prima di tutto, siamo ingegneri, non artisti. Lavoriamo in gruppo, quindi nella nostra vera esperienza lavorativa, il "nostro" codice è spesso il risultato del lavoro di squadra, perché è così che di solito si fa il vero lavoro. Non c'è molto codice professionale per il quale potrei rivendicare la proprietà esclusiva.

In secondo luogo, la maggior parte del codice nel mio ipotetico portafoglio sarebbe un codice che non potevo mostrare a nessuno, perché è confidenziale. Il codice che ho creato per i miei progetti personali per animali domestici non riflette necessariamente tutte le mie capacità e il mio tipico comportamento lavorativo.

Ho intervistato molte persone durante il mio periodo come professionista del software. Ho raggiunto un punto in cui credo che i quiz e i compiti di programmazione dei giocattoli siano uno spreco di preziosa larghezza di banda. Quiz e compiti di programmazione di giocattoli servono solo a testare ciò che l'intervistatore conosce. Non sono un modo preciso per valutare ciò che un candidato sa. A questo punto della mia carriera, accetto questo tipo di assurdità solo se, e solo se, mi viene data la possibilità di gestire il mio test alla fine del colloquio.

Il modo migliore per valutare le capacità di un professionista del software è parlargli con voce calma e rassicurante. Chiedere al candidato di discutere in merito alla sua posizione attuale. Quando il candidato fa apparire un'area di interesse, chiedigli di elaborare quell'area. L'obiettivo qui è quello di far abbassare la guardia al candidato. Nessuna quantità di coaching può preparare un candidato all'interrogazione "soft touch". Prima o poi, il cappio si stringerà intorno al collo di un candidato che sta cercando di farsi strada attraverso un'intervista.

Chiedo un campione di codice per i candidati e viene referenziato durante il colloquio. Comunque di solito do più peso alla lavagna programmata durante l'intervista.

Ogni intervista con lo sviluppatore che faccio implica andare alla lavagna per implementare la soluzione a un semplice problema. Tuttavia, ci sono regole:

Il richiedente deve parlare dell'attuazione mentre lo sta facendo.

• Posso valutare come affrontano un problema.
• Vedo quanto bene può comunicare.
• Posso valutare la loro velocità con un obiettivo chiaro.

Ho tre problemi le cui implementazioni sono tutte simili e faccio loro sapere che possono riutilizzare o riformattare il codice che hanno scritto.

• Vedo se riescono a tirarsi indietro per dare un'occhiata al quadro più grande.
• Posso vedere se implementano e refactoring, o saltano alla generalizzazione.
• Posso avere un'idea più solida di quanto bene l'ordine dei loro pensieri.

Il punto di tutto questo, di qualsiasi colloquio è quello di cercare di farsi una buona idea delle capacità dei candidati e di come possano adattarsi al lavoro. La parte "pratica" dell'intervista nella mia esperienza mi ha aiutato molto in questo senso. Mi aiuta anche a valutare il codice di esempio perché so molto di più sul modo in cui il programma.

Un esempio di codice è un modo abbastanza efficiente di eliminare i candidati: posso giudicare un campione di codice in 5-10 minuti, ma anche uno schermo del telefono impiega 15 minuti e ha bisogno di essere programmato (e non è terribilmente utile per eliminare tutto tranne che fondo della pila nella mia esperienza).

Penso che le principali obiezioni agli esempi di codice siano duplici e possano essere facilmente superate:

• quello che richiede un esempio di codice crea una barriera artificiale per alcuni sviluppatori di talento

Ovviamente, questo è vero. Qualsiasi barriera nella domanda o nel processo di assunzione può potenzialmente eliminare un candidato desiderabile. La cosa importante qui è conoscere il tuo pubblico: se hai 1000 curriculum per la tua unica apertura, puoi permetterti alcuni falsi negativi al servizio dell'efficienza. Se hai cinque curriculum, puoi permetterti alcune inefficienze nel processo di screening.

Ciò che penso alla maggior parte delle persone, però, è che intervistare e assumere è fondamentalmente un gioco di "trovare un motivo per non assumere questa persona". Per qualsiasi lavoro dignitoso, ci sono molti candidati qualificati - l'ultimo in piedi è di solito quello che non ha dato il via a nessuna bandiera rossa lungo la strada. È facile vedere il meglio nelle persone o non essere impegnativi, ma questo non ti fa bene assumere, perché finirai con 10 candidati diversi con cui ti senti a tuo agio. Questo non ti avvicina di più a una decisione.

Ogni bocconcino che raccogli durante il processo di revisione, screening, intervista, ecc. Potrebbe potenzialmente innescare una decisione senza assunzione. Devi bilanciare la sensibilità del tuo trigger senza assunzione con le tue prospettive attuali (e potenziali future). Se sei in un settore noioso, con un sacco di codice legacy, burocrazia e stipendio scarso (spesso cose fuori dal tuo controllo), il tuo trigger deve essere meno sensibile di quanto si pensi, Google. Altrimenti, rischi di non assumere mai nessuno.

Personalmente, trovo che il compromesso più semplice per me sia stato richiedere ma non richiedereun esempio di codice. Se ne ottengo uno, è solo un punto dati aggiuntivo con cui valutare il candidato. Allo stesso modo, se mi capita di avere una conoscenza che ha lavorato con il candidato in passato, attribuirò un certo peso alle opinioni di quella conoscenza. Non aver lavorato con nessuno che conosco certamente non squalifica nessun candidato, ma significa solo che il mio lavoro nel valutarli è un po 'più difficile (e probabilmente includerà un esercizio di codifica se lo fanno a un'intervista). Se il tuo campione è scadente (o la mia conoscenza ti fa venire la bocca male), è praticamente un non-noleggio. Quelli che forniscono un campione possono o meno avere un piccolo vantaggio rispetto a quelli che non fanno parte dello screening iniziale - a seconda della qualità e della quantità della pila di curriculum e dei campioni, più informazioni possono essere migliori o peggiori di nessuna informazione.

• che i campioni sono facilmente falsificati

Bene sì. Lo sono anche i curriculum, ma li raccogliamo ancora. Perché? Per tre ragioni principali: un curriculum o un campione scadente è un semplice non-assunzione, essere sorpresi a simulare un curriculum o un campione è un semplice non-assunzione, e sono buoni argomenti di conversazione in un'intervista. Quanto più velocemente riesco a capire che il candidato è uno sciocco, tanto meglio per tutti.

Se sei abbastanza intelligente da plagiare un buon campione senza essere catturato, parlane in modo intelligente e supera l'intervista - Non ho particolari problemi con il modo in cui hai superato la proiezione. Potrebbero esserci alcune preoccupazioni etiche qui, ma non è proprio la mia area di competenza, quindi non farò di tutto per valutare il carattere morale durante un'intervista. Per me è praticamente lo stesso del mio capo che mi chiede di intervistare qualcuno che non ha superato il processo di screening come un favore. Una volta che sei nella fase del colloquio, non importa davvero come ci sei arrivato dato che ci sono molte più e migliori informazioni che usciranno durante il colloquio.

TL; DR : un esempio di codice è un ottimo strumento di screening, ma dovresti pensare attentamente se puoi farlo o meno. Una volta superato lo screening, soppesare l'intervista molto più in alto di un campione.