Esempi di codice e interviste? [chiuso]

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 codice da Internet o, più probabilmente, trasmettendo codice scritto da un team di sviluppatori come loro lavoro. Come giustamente fai notare, puoi imparare almeno tanto facendo in modo che uno sviluppatore parli di un progetto a cui generalmente hanno familiarità per un'ora, facendoli codificare da zero una calcolatrice fattoriale.

La mia obiezione a un portafoglio è che richiedere un portafoglio elimina molti sviluppatori di talento. Dal momento che io, a differenza di un artista o fotografo, non conservo il copyright del codice che produco, appartiene al mio datore di lavoro e / o all'impresa che ha stipulato un contratto con il mio datore di lavoro ... Non posso mostrare la stragrande maggioranza dei " interessante "codice che ho scritto. Se sto programmando il mio tempo, in genere sarà un progetto parallelo al lavoro che mi faciliterà la vita o che mi infastidisce e che ancora non riuscirò a mostrare in un portfolio. Ho un sacco di post in vari forum, ma la maggior parte di questi sono, per impostazione, relativamente superficiali. Esiste una popolazione piuttosto consistente di sviluppatori solidi che si trovano in una posizione simile: il loro codice interessante è di proprietà di qualcun altro. E se non sei una società di alto livello, ti stai perdendo i solidi sviluppatori che sono felici di entrare, lavorare duramente per 8 ore e poi tornare a casa per stare con la loro famiglia piuttosto che svilupparsi per divertimento al di fuori di lavoro.

Un'intervista tecnica in cui tutti i candidati sono invitati a codificare qualcosa da zero fornisce almeno una parità di condizioni. Supponendo che tu faccia un lavoro ragionevole di fare lo schermo del telefono e che tu possa limitare i candidati ad una lista ragionevole, preferirei che un candidato abbia un problema da risolvere che tu sappia impiegherà 8 ore di sforzo piuttosto che creare un portafoglio coerente di app giocattolo che non hanno problemi di copyright.

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

In secondo luogo, la maggior parte del codice nel mio portafoglio ipotetico sarebbe un codice che non potrei mostrare a nessuno, perché è riservato. 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 consulente software. Ho raggiunto un punto in cui credo che i quiz e gli incarichi di programmazione dei giocattoli siano uno spreco di preziosa larghezza di banda. Quiz e compiti di programmazione dei giocattoli servono solo a testare ciò che l'intervistatore conosce. Non sono un modo accurato 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 l'opportunità di amministrare il mio test alla fine dell'intervista.

Il modo migliore per valutare le capacità di un terapeuta è parlargli in una voce calma e rassicurante. Chiedere al candidato di discutere di quale sia la sua posizione attuale. Quando il candidato espone un'area di interesse, chiedigli di approfondire l'argomento. L'obiettivo qui è quello di convincere il candidato ad abbassare la guardia. Nessuna quantità di coaching può preparare un candidato per l'interrogatorio "soft touch". Prima o poi, il cappio si stringerà intorno al collo di un candidato che sta cercando di convincere a modo suo attraverso un'intervista.

Chiedo un campione di codice per i candidati e viene referenziato durante l'intervista. Tuttavia di solito conferisco più peso alla codifica della lavagna fatta durante l'intervista.

Ogni intervista per sviluppatori che faccio coinvolge la lavagna per implementare la soluzione a un problema semplice. Tuttavia, ci sono regole:

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

• Posso valutare in che modo si avvicinano a un problema.
• Riesco a vedere quanto bene può comunicare.
• Posso valutare la velocità con un obiettivo chiaro.

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

• Posso vedere se possono ritirarsi per dare un'occhiata all'immagine più grande.
• Posso vedere se implementano e refactor o saltano alla generalizzazione.
• Posso avere un'idea più chiara di quanto bene ordini i loro pensieri.

Il punto di tutto questo, di qualsiasi intervista è di provare e avere una buona idea delle capacità dei candidati e di come potrebbero essere all'altezza del lavoro. La parte "pratica" dell'intervista nella mia esperienza ha contribuito parecchio a questo riguardo. 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 efficace per escludere i candidati: posso giudicare un campione di codice in 5-10 minuti, ma anche uno schermo del telefono richiede 15 minuti e necessita di pianificazione (e non è molto utile per eliminare qualsiasi cosa ma il fondo della pila nella mia esperienza).

Penso che le principali obiezioni ai campioni di codice siano due volte e siano facilmente superabili:

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

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

Ciò a cui penso la maggior parte della gente manca, tuttavia, è che intervistare e assumere è fondamentalmente un gioco di "trovare un motivo non per assumere questa persona". Per qualsiasi lavoro decente, ci sono molti candidati qualificati - l'ultimo in piedi è di solito quello che non ha fatto scattare nessuna bandiera rossa lungo la strada. È facile vedere il meglio delle persone o essere non impegnativo, ma questo non ti rende utile nelle assunzioni perché ti ritroverai con 10 candidati diversi con cui ti senti a tuo agio. Questo non ti avvicina a una decisione.

Ogni boccone raccolto durante il processo di revisione, screening, colloquio ecc. potrebbe potenzialmente innescare una decisione di non assunzione. Devi bilanciare la sensibilità del tuo trigger no-rent con il tuo attuale (e potenziale futuro). Se ti trovi in un settore noioso, con un sacco di codice legacy, burocrazia e scarso stipendio (spesso fuori dal tuo controllo), il tuo trigger deve essere meno sensibile di quello di Google. Altrimenti, corri il rischio di non assumere mai nessuno.

Personalmente, trovo che il compromesso più semplice per me sia stato quello di request ma non richiedere un esempio di codice. Se ne ottengo uno, è solo un punto dati aggiuntivo per valutare il candidato con. Allo stesso modo, se mi capita di avere un conoscente che ha lavorato con il candidato in passato, attribuirò un po 'di peso alle opinioni di questa conoscenza. Non avendo lavorato con nessuno che conosco, certamente non squalifica nessun candidato - significa solo che il mio lavoro nel valutarli è un po 'più difficile (e probabilmente includerà un esercizio di codifica se lo faranno in un'intervista). Se il tuo campione è povero (o la mia conoscenza è una brutta bocca), è praticamente un no-hire. Quelli che forniscono un campione possono o non possono avere una piccola gamba su quelli che non sono sottoposti a screening iniziale - a seconda della qualità e della quantità della pila di resume e dei campioni, maggiori informazioni potrebbero essere migliori o peggiori di nessuna informazione.

• i campioni sono facilmente falsi

Bene, si. Così sono i curriculum - ma li raccogliamo ancora. Perché? Per tre ragioni principali: un curriculum o un campione mediocri è un no-hire facile, essere scoperti a fingere un curriculum o un campione è un semplice no-hire, e sono argomenti di conversazione validi in un'intervista. Il più veloce riesco a capire il candidato è un dolt, il migliore per tutti.

Se sei abbastanza intelligente da plagiare un buon campione senza essere catturato, parla in modo intelligente e passa il colloquio - non ho particolarmente problemi con il modo in cui hai superato lo screening. Potrebbero esserci alcune preoccupazioni etiche qui, ma questa non è la mia area di competenza, quindi non sto andando fuori dal mio modo di 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 favore. Una volta che sei nella fase dell'intervista, non importa davvero come ci sei arrivato visto che ci sono molte più informazioni migliori che verranno fuori durante l'intervista.

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, pesare l'intervista molto più in alto di un campione.