Introduzione

Uno degli aspetti di TANTI LinkedIn che mi disturba è il 'come intervistare gli sviluppatori' post. C'e' un TON di loro e sono in tre campi:

1. La - Come muoveresti il Monte Fuji? approccio con enigmi logici e teaser del cervello.
2. L'approccio 'Vediamo quanto si può ricordare dal vostro grado di Informatica' con le domande algoritmiche.
3. L'approccio 'guardare mentre si scrive codice' con esercizi di codifica.

Nel corso degli anni ho intervistato decine di volte e assunto centinaia di sviluppatori per varie aziende da Microsoft a Dell per piccole startup. Stranamente sono stato anche uno psicologo della ricerca specializzato in psicometria (la scienza della misurazione delle capacità mentali) e uno sviluppatore di software. Quindi ho visto il processo da ogni parte.

Il problema

La codificazione spesso non è un'attività sociale. Certo'soft skills' sono di vitale importanza, ma sono spesso ortogonali per la pratica di scrivere codice per risolvere i problemi degli utenti. Allora, come si fa a interrogare qualcuno per un lavoro che riguarda principalmente la scrittura di codice?

Anche la nostra professione è piena di sindrome da impostore. L'ho visto in me stesso e in molti altri. E' una cosa vera. Allora, come fai a intervistare qualcuno che si sente gia' un imbroglione?

La nostra professione è piena di imbarazzo sociale (e sì come me leggermente autistico); un'intervista che è sia stressante e richiede interazione sociale, mentre risolvere problemi di codifica è una ricetta per il disastro. Allora, come fai a intervistare qualcuno che e' socialmente imbarazzante?

La soluzione

Prima leggere il loro curriculum; non parlare con loro se il loro curriculum non rende chiaro che hanno esperienza sufficiente per il lavoro che si sta assumendo per. Questo non è solo rispettoso del loro tempo, ma anche del vostro.

In secondo luogo, la creazione dell'intervista (o dell'intervista) dovrebbe essere quanto più possibile priva di stress per i partecipanti. Ciò significa:

1. Dare un preavviso adeguato. Non esporre un colloquio su qualcuno con 24 ore di preavviso (o peggio lo stesso giorno).
2. Mettete in chiaro quale sarà il formato dell'intervista, chi ci sarà e quali saranno i risultati attesi (è la finale, uno schermo tecnico ecc.).
3. Leggi il resume della persona. Non posso stressarlo abbastanza. Se stai interrogando qualcuno, dovresti conoscere il loro curriculum. Questo non è solo rispettoso, ma ti dà anche la possibilità di fare domande sulla loro esperienza.
4. Assicurati di avere i dettagli nella mail; se si tratta di Teams / Zoom assicurarsi che abbiano il link. Se e' di persona, assicurati che sappiano dove andare.

L'intervista

Essere in tempo; niente rende una persona più ansiosa di aspettare un colloquio per iniziare. Se sei in ritardo stai gia' iniziando col piede sbagliato. Se sono in ritardo dare loro un paio di minuti, probabilmente non sono stati a back meeting in modo che il loro set-up potrebbe essere fottuto.

Sembrano qualcuno che si adatta alla squadra in termini di temperamento; sono una buona misura per la squadra? Questo è importante; si può avere il miglior programmatore del mondo, ma se sono un idiota non ne vale la pena.

Un suggerimento che ho inventato (dopo anni di domande di sequenza di Fibonacci, array di inversione, liste collegate ecc.) è.

CODERS like talking about CODE they know

Ciò significa che se si sta facendo una valutazione tecnica la persona che fa il colloquio deve essere in grado di parlare del codice che stanno vedendo. Se è un framework che non conosci (come me che intervistavo gli angolari) non ti preoccupare troppo.

Quindi, prima dell'intervista con abbastanza preavviso (5 giorni è generalmente buono) dire loro che sarà chiedere loro di parlare di un pezzo di codice che hanno scritto. Non chiedo GENERALMENTE un collegamento GitHub (molte persone a livelli anche senior potrebbero non avere questo; ho lavorato su molti progetti che sono proprietari e non possono essere condivisi).

Metti in chiaro che non stai chiedendo un grande progetto / qualche codice innovativo incredibile. E' solo un codice di cui possono parlare. Molte persone hanno queste cose 'famiglia', è probabile che non sono stati un 365 giorno streak contributore a un grande progetto Open Source.

Non stai assumendo in base a quanto tempo libero qualcuno ha

Perche'?

Allora perché preferisco questo approccio? Perché penso che questo sia un modo migliore per intervistare gli sviluppatori?

1. E' meno stressante. La persona che viene interrogata sta parlando di qualcosa che sa. Non stanno cercando di risolvere un problema che non hanno mai visto prima; in realtà la maggior parte del tempo quando si codifica si è preoccupati di come scrivono il codice quando viene dato il tempo di scriverlo. La maggior parte di noi non sta frustando algoritmi folli per fare cose che il nostro quadro di scelta già fa per noi.
2. Puoi capire se mentono sulla loro esperienza. Se non possono parlare di un pezzo di codice che hanno scritto allora probabilmente non l'hanno scritto.
3. È possibile scavare nel codice in modi più naturali; perché hanno scelto quell'approccio rispetto ad uno diverso, perché non hanno usato una libreria ecc.
4. Stai vedendo il codice che vogliono mostrarti. Questa e' grossa. Se stai chiedendo loro di scrivere codice sul posto vedi codice che stanno scrivendo sotto pressione. Se stai chiedendo loro di parlare di codice che hanno scritto, vedi codice che hanno scritto quando non sono sotto pressione. Ancora una volta, a meno che il vostro posto di lavoro è un caso cestino la maggior parte del tempo che non stai scrivendo codice sotto pressione.

Eccezioni all'articolo

Quindi ci sono eccezioni qui, i programmatori super junior a volte hanno bisogno di un piccolo esercizio di codifica, ma prendilo lentamente. Chiedere loro di analizzare e refactor / risolvere qualche enorme base di codice è solo crudele. Per loro si può chiedere circa concetti di base come loop, condizionamenti ecc (mantenere focalizzato sul lavoro che si sta assumendo per). Pattern? Beh, ho visto un sacco di persone che non sanno dare un nome a uno schema, ma che possono dirti quando l'hanno usato. Quindi non farti coinvolgere troppo.

Logic Puzzle? Non ne ho mai visto il senso. Non ho mai visto un lavoro dove devi spostare il Monte Fuji. Non ho mai visto un lavoro dove hai bisogno di sapere quante palle da golf entrano in un 747. Non ho mai visto un lavoro dove devi sapere quanti sintonizzatori di piano ci sono a New York.

Follow Up

Dopo l'intervista assicurarsi di seguire con il candidato. Se non hanno ottenuto il lavoro dire loro perché (non mi hai mostrato abbastanza della vostra esperienza, non era chiaro quando spiegare il vostro codice ecc). Questo non è solo rispettoso, ma li aiuta anche a migliorare per la prossima intervista. Se hanno ottenuto il lavoro assicurarsi di sapere cosa aspettarsi dopo.