Avete necessario un test di programmazione. Ma dovrebbe durare 5-10 minuti. 30 minuti al massimo. Non c'è un test di 2 ore che vi dica esattamente quanto sia bravo un programmatore. Non sarete in grado di dire se scrivono continuamente codice manutenibile, o se commentano sempre correttamente, o se escono con pasticci illeggibili di soluzioni “intelligenti” ai problemi, ecc. In 2 ore, l'unica cosa che otterrete è scoprire chi sta mentendo apertamente sul fatto di conoscere una lingua/programmazione.

Tranne che dovreste essere in grado di individuare le frodi in molto meno tempo di 2 ore. 5 minuti scrivendo FizzBuzz e 2-3 domande veloci sulle caratteristiche specifiche della lingua vi diranno se sono assolutamente inutili. E questo è il meglio che si può fare in un colloquio di lavoro.

Lasciate che vi dica cosa penserei se ricevessi un esame di 2 ore per il privilegio di condurre un colloquio:

“O queste persone pensano che questo abbia un valore, il che significa che non hanno idea di quello che stanno facendo, OPPURE, sanno che è una perdita di tempo, ma per qualche ragione (probabilmente seguendo ciecamente la burocrazia delle Risorse Umane), sono disposti a sprecare il tempo dei candidati prima ancora che il candidato venga assunto. Immaginate cosa penseranno di poterla fare franca una volta che mi avranno pagato.

In ogni caso, non voglio lavorare lì”

C'è un'altra cosa che potrebbe allontanare i candidati: La durata del colloquio. Ci sono persone che fanno un colloquio telefonico. Poi un test da portare a casa che hanno una settimana di tempo per finire. Poi si passa ai test. Poi si organizza un colloquio faccia a faccia con la direzione. Poi (presumo) fate un paio di colloqui frontali. Poi si fa tornare il tizio che si vuole assumere. Che cosa ci vuole? 2 settimane? Di più?

In questo tempo ho già ricevuto 3 offerte. Ne ho accettata una e comincio la prossima settimana. Pensi che andrò a fare il tuo test di 2 ore?

Permettetemi di iniziare dicendo che l'assunzione di dipendenti in generale è una scienza pateticamente inesatta, e si otterranno vari risultati a prescindere da ciò che si prova. Detto questo, ho sentito di dover condividere i miei pensieri su questo.

Penso che gli esercizi di programmazione siano un fallimento, soprattutto perché si ottengono persone che sono disperate e hanno troppo tempo a disposizione per completarli. Se hanno un lavoro a tempo pieno, dovresti chiedere quanto tempo/energia mentale stanno prendendo dal loro attuale datore di lavoro per lavorare per qualcuno che non li paga nemmeno. Volete che facciano cose del genere a voi?

Inoltre, se sono bravi, molto probabilmente stanno facendo un colloquio con molti datori di lavoro. Indovinate a quali di essi daranno la priorità? Quelli che non chiedono di completare i progetti prima ancora di aver parlato al telefono con un responsabile di ingegneria.

C'è anche il problema del plagio. Certo, lo scopriranno durante il colloquio di persona, ma per allora avrete già sprecato il tempo di (presumibilmente) persone altamente retribuite presso la società che ha intervistato questa persona.

La mia attuale società l'ha fatto bene, e questa è la strada che seguirei nella vostra posizione. Dia loro un piccolo compito che dovrebbe richiedere solo 90-120 minuti, e dica loro di giustificare nei commenti il motivo per cui hanno scelto questo modo di risolvere il problema. Questo è qualcosa che si può fare in una notte, e che vi darà un'idea del loro pensiero.

Posso dirvi subito che se ottengo un progetto che richiede più di 8 ore, dico loro grazie ma non sono interessato. Ho un buon lavoro e una vita. Se un manager lo vede come un problema, mi dice che non si preoccuperebbe del mio equilibrio tra lavoro e vita privata sul lavoro (soprattutto se non gli interessa prima che lo abbia). Nessuna azienda, tranne forse Google, Apple o Facebook, potrebbe farla franca.

Nella mia esperienza, i progetti take-home non eliminano i cattivi codificatori, e probabilmente fanno sì che i buoni codificatori trovino un lavoro in cui non devono saltare attraverso un cerchio per parlare con il responsabile delle assunzioni.

Pensateci in questo modo. Un buon codificatore può facilmente ottenere colloqui telefonici e di persona. Ogni cerchio in più che devono attraversare significa che prenderanno la strada più facile e faranno il colloquio (e saranno assunti) da qualcun altro che pagherà altrettanto. Se fate saltare le persone attraverso i cerchi, assicuratevi che vedano che ne vale la pena fin dall'inizio.

Un cattivo sviluppatore può impiegare tutto il tempo che vuole. Non li vedrete impiegare 4 volte tanto; vedrete solo il test completato. Non li vedrete nemmeno andare da Google o dal loro amico a chiedere aiuto con una dichiarazione di if.

La mia ultima azienda ha fatto questo, e la stragrande maggioranza delle persone che abbiamo portato per un colloquio di persona non è riuscita Fizz buzz (circa il 65%). Penso che questo sia successo perché abbiamo inavvertitamente eliminato persone brave e impegnate che non avevano bisogno di un altro colloquio con un'altra società, e allo stesso tempo, facendo penzolare un'intervista facile davanti a cattivi codificatori.

Cosa penso che avremmo dovuto fare invece

Invece di dare alle persone un incarico da portare a casa che richiedeva 15-20 minuti per essere valutato, avremmo dovuto fare un'intervista su Skype di 15-20 minuti in cui facevamo domande come Fizz buzz. Questo avrebbe richiesto lo stesso tempo, ma probabilmente avrei eliminato i cattivi programmatori prima di un'intervista di due ore di persona.

FYI - > Ecco un articolo molto dettagliato su Fizz-buzz e sulle pratiche generali di intervista.

Una visione contrastante, da parte di qualcuno in trincea da entrambi i lati della questione. Sospetto che questa risposta attirerà voti contrari, ma è un'opinione altamente informata, sviluppatasi nel corso di diversi decenni in questo settore. Poiché mi piace farlo, scrivo ancora codice ogni giorno per vivere e per hobby nel mio “copioso tempo libero”, ma sono stato anche l'ultimo a decidere l'assunzione di un paio di dozzine di programmatori, e ho contribuito a intervistare e consigliare per l'assunzione di un numero piuttosto elevato di programmatori.

Lawrence ha ragione: l'assunzione è tristemente inesatta. Ma con il tempo stiamo migliorando. Più che chiacchiere faccia a faccia, più che domande banali, le brevi sfide di programmazione in loco sono una parte sempre più essenziale di questo: non solo per abilità, ma per attitudine.

Si noti che ho detto “breve ”. Diamo ai candidati un computer portatile con un Eclipse (il nostro IDE scelto) correttamente installato quando arrivano per il colloquio. Se configurato correttamente significa che hanno accesso alla fonte jdk, ma non ha internet, e viene chiesto loro di non usare i cellulari durante il test. Hanno un'ora di tempo per risolvere da zero a cinque problemi, partendo da “FizzBuzz”, e salendo nella complessità fino a qualcosa dell'ordine di un semplice sistema multithreaded produttore/multiplo-consumatore.

Nessuno ha mai risolto tutti e cinque i problemi in un'ora, e non mi aspetto che nessuno lo farà mai (posso scrivere soluzioni per cinque in meno di un'ora, ma naturalmente ho visto i problemi e li ho risolti tutti in precedenza, quindi non sono un test corretto).

Tra l'altro, abbiamo avuto programmatori apparentemente esperti fail per far funzionare bene FizzBuzz. Lasciatemelo dire ancora una volta: abbiamo avuto una manciata di candidati che non sono riusciti a completare FizzBuzz correttamente. Di solito non seguendo le indicazioni, ma leggere le specifiche è una parte essenziale dell'essere uno sviluppatore.

Li facciamo scrivere codice mentre sono qui in sede piuttosto che dare loro compiti a casa per diversi motivi, in parte per il rischio di imbrogliare, e in parte per dare a ogni candidato un'uguale opportunità di lavorare ai problemi. Inoltre, ruotiamo i problemi dentro e fuori dalla sfida stabilita e discutiamo le soluzioni con i candidati in seguito.

Mi sento molto convinto su questo argomento. Non ho mai visto un candidato rifiutare una posizione o abbandonare il processo di colloquio a causa del nostro test di programmazione. Ma questo può essere influenzato dal fatto che diciamo ai selezionatori che ci servono che il processo include la programmazione in loco. Quindi potremmo non vedere i candidati che pensano che essere invitati a scrivere un'ora di codice sia un “lavoro non retribuito”. Se è così, che liberazione! Se pensano che un'ora di codice sia più simile a “lavoro” che a un'ora di risposte a domande banali, o che le loro risposte ai problemi del test possano produrre qualcosa di utile, non ho bisogno del loro atteggiamento.

Una volta abbiamo avuto un candidato che si è lamentato del test, perché pensava di essere troppo anziano per doversi dimostrare (non è una congettura - ha detto così). Ed è andato bene nelle sfide, e ha avuto tutta l'esperienza che volevamo. Ma era un dipendente terribile: a quanto pare pensava anche di essere troppo anziano per prendere la direzione o imparare, e alla fine abbiamo dovuto lasciarlo andare.

Una delle cose che ho deciso negli anni che abbiamo fatto è che qualsiasi azienda che non fa il test è meno probabile che mi prenda come dipendente. Come le loro risposte a domande come cosa usano per il controllo dei sorgenti, ecc., se i test di un'azienda mi dicono molto su quanto sono bravi nel business dello sviluppo software.

** Quindi, cosa dovresti fare? ** Dovresti fare quello che funziona per la tua organizzazione, ma il mio consiglio è di continuare i test, ma di farli in loco, come parte del colloquio. Dite loro in anticipo che questo fa parte del processo, e fatelo prima che si incontrino con i dirigenti superiori (ma dovreste prima incontrarli per aiutarli a mettersi a proprio agio). E davvero: saltate il colloquio con i dirigenti superiori se non riescono. Non preoccupatevi della popolarità dei candidati o dei poster su internet. Il costo di una cattiva assunzione è molto peggiore del costo di un ritardo fino a quando non si effettua una buona assunzione.

Anche se ignoriamo la possibilità di imbrogliare, e il filtro inverso che fa sì che i candidati buoni e onesti evitino le aziende con test di codifica a casa, il valore dei test di codifica a casa è limitato.

Se si tratta di un senior position , uno sviluppatore senior con competenze sulle persone sarà in grado di capire in meno di 10 minuti se lo sviluppatore senior all'altro capo del telefono è qualsiasi buono, o sta solo inventando cose. Non sapremo esattamente quanto sia buono, ma sapremo altrettanto, se non più di quanto ci dicono tutti i possibili test di codifica a casa.

Se è per un posizionamento junior , non ci aspettiamo molto in termini di competenze tecniche. Cerchiamo entusiasmo, voglia di imparare e talento - nessuno dei quali viene notato da un test di codifica a casa. Ci sono troppe cose che i junior possono ignorare. Se li assumiamo, dobbiamo comunque addestrarli.

Come fare un test invece?

Come filtro, basta dare loro 10 minuti per risolvere una variazione FizzBuzz sul posto durante la prima tornata di colloqui o, se siete sommersi da buoni CV e avete bisogno di un altro filtro, fatelo su Skype prima della prima vera tornata di colloqui.

Una volta che hanno superato i filtri, dovete sapere di più sulle capacità di codifica dei vostri candidati. Raccomando di passare da 30 minuti a un massimo di 2 ore di programmazione in coppia o di revisione del codice - un vero e proprio lavoro reale, piuttosto che un esercizio. Ripetere 1-2 volte con partner diversi. Il vantaggio della programmazione a coppie e delle revisioni del codice è che lo sviluppatore ha già conoscenze sufficienti per contribuire.

Non preoccupatevi che il test sia diverso per ogni assunzione - l'obiettivo del processo di assunzione non è quello di trovare la persona che ottiene il miglior punteggio in un paio di test misurabili e ripetibili. **L'obiettivo è assumere una sola persona che faccia bene il lavoro.

Ecco un altro punto che non vedo trattato nelle risposte esistenti (che credo trattino bene l'argomento in generale). Vorrei esaminare da vicino e seriamente il tempo che le persone impiegano a completare. Ho avuto quattro colloqui di lavoro durante i quali ho avuto un esercizio di programmazione da completare, ognuno dei quali è stato fatto in modo diverso (e ognuno ha avuto i suoi vantaggi e svantaggi). Due dei quattro (i numeri 3 e 4 qui sotto) hanno richiesto molto più tempo di quanto dicevano, e ho finito per rinunciare ad entrambi a causa del difficile livello. Li ho descritti qui sotto e li ho classificati dal mio punto di vista dal migliore al peggiore.

1. Durante il colloquio tecnico, mi hanno fatto sedere ad un computer che aveva una versione ridotta del loro codice base e mi hanno fatto risolvere tre problemi relativamente brevi ad esso collegati (trovare e correggere un bug che avevano aggiunto di proposito, aggiungere un nuovo campo ad una tabella informativa, ecc.) Mi hanno dato esattamente un'ora per farlo, e dopo un'ora hanno ripassato la mia soluzione e il modo in cui ho affrontato i problemi. Questo ha dato loro maggiori informazioni su di me come programmatore, pur rispettando il mio tempo, mantenendolo breve e puntuale. Durante il colloquio tecnico mi hanno fatto lavorare su un problema che avevano incontrato durante lo sviluppo su una lavagna bianca, pur essendo in grado di far rimbalzare le idee su di loro. Questa è stata l'opzione più breve, pur dando loro la possibilità di vedere come lavoro attraverso i problemi e quanto posso effettivamente fare il lavoro necessario. 3. Durante il colloquio tecnico (per una posizione di Ruby on Rails Web Development junior) mi hanno incaricato di costruire un'applicazione web da zero che navigasse su un sito web, compilasse più moduli man mano che venivano presentati, raschiasse i dati dalla pagina risultante e li presentasse all'utente. Hanno detto che questo dovrebbe essere un esercizio veloce, e che potrebbe essere stato per uno sviluppatore web di livello senior, ma avendo avuto solo un anno di esperienza professionale a quel punto, ho passato quattro ore a cercare di far funzionare il tutto prima di mollare e tornare a casa (tutti gli intervistatori avevano lasciato ore prima di me perché era un colloquio pomeridiano, hanno detto che avrei dovuto salvare il programma finito quando avevo finito). Questo è un incarico ridicolo per la posizione elencata, non ha dato loro idea delle mie capacità di codifica, e mi è sembrato che stessero solo cercando di ottenere un lavoro gratuito dall'accordo. Inutile dire che non volevo nemmeno il lavoro quando me ne andai quel giorno.
2. Prima ancora di avere un colloquio tecnico, mi hanno dato l'incarico di creare un'applicazione web che sfruttasse un'API che la loro azienda usava per “fare qualcosa di interessante”. Questo era esattamente così ampio come sembra. Questo mi ha richiesto di fare quanto segue prima ancora di tentare di creare l'applicazione: creare un account di sviluppo per l'API, scaricare il kit di sviluppo dell'API, creare un'applicazione web accessibile al pubblico (con un altro account di sviluppo), imparare l'API e creare un repository di dati a cui accedere con l'API. Questo naturalmente ha richiesto molte ore solo per iniziare, e poco dopo aver iniziato a lavorare sull'applicazione web stessa, ho ottenuto un altro colloquio di lavoro e poco dopo un'offerta di lavoro, così ho interrotto il lavoro sull'incarico. È una cosa folle da avere come parte di un processo di colloquio, perché chi vuole dedicare tutto quel tempo e quegli sforzi allo sviluppo di un programma solo per avere una piccola possibilità di andare avanti nel processo di colloquio?

Quindi, per rispondere più direttamente alla tua domanda, dovresti fare un esercizio di programmazione? Sì, ma assicuratevi che sia fatto su misura per testare ciò che vi interessa realmente e non richieda un sacco di lavoro estraneo per l'intervistato. Volete conoscere il loro pensiero algoritmico? Date loro un problema di algoritmo. Volete conoscere il loro stile di codifica? Date loro un problema di codifica. Volete sapere del loro processo di sviluppo? Discutete con loro il loro processo mentre lavorano su un problema.

Iniziamo con:

• Mi sono stati dati test da completare a casa che andavano da 15 minuti a 10 ore.
• Mi sono stati dati test online da eseguire.
• Mi è stato affidato il compito di scrivere la risposta a FizzBuzz e ad altri test di moda su internet su lavagne.
• Mi è stato chiesto dei chiusini quadrati o rotondi.

In breve, mi sono occupato praticamente di tutti i diversi modi in cui gli sviluppatori amano gestire le interviste. Ad essere sincero, dubito seriamente che la stragrande maggioranza delle persone che mi hanno intervistato abbia compreso i potenziali risultati di ognuno di questi test e alla fine ha assunto solo persone che hanno deciso se gli sono “piaciuti” o meno.

Prima ancora di mettere un annuncio di lavoro, dovreste sedervi e passare in rassegna esattamente quello che state cercando di assumere e “sviluppatore” non è una risposta, almeno, non è una risposta vera e propria. Una buona risposta a questo sarebbe qualcosa come “esperto di domini ipotecari”.

Trovare qualcuno che possa scrivere un po’ di codice o cercare su Google come applicare un particolare modello è banale rispetto a trovare qualcuno che sia stato nel business in cui ti trovi e che possa sfruttare questa conoscenza. In altre parole, se stessi assumendo per una società di documentazione ipotecaria, prenderei qualcuno che potrebbe parlare della differenza tra il prestito fisso a 15 anni e il prestito ARM rispetto a qualcuno che potrebbe scrivere un algoritmo di tipo bubble sort in 2 minuti. Il motivo è che gli uomini d'affari “normali” fanno ogni sorta di richieste strane e gli esperti di dominio possono arrivare più facilmente al cuore di ciò che è necessario, mentre qualcuno che non sa nulla aggiungerà volentieri cose inutili o renderà l'app davvero pessima.

Tornando alle domande, solo domande ask go / no go.

È fondamentale che la persona possa dirti la differenza tra un metodo virtuale e un metodo astratto? Potrebbe essere, di solito non lo è. Scommetterei che una buona parte degli sviluppatori sa a malapena quando usare quelle parole chiave, ma non sono le tue superstar, sono il rango e il file che non possono usare il codice senza i visual designer.

È fondamentale individuare quando una query è aperta per l'iniezione di sql? Per una posizione Sr. - assolutamente; per una posizione Jr. no. Questo è qualcosa che è facilmente addestrabile e gestibile tramite la revisione del codice. Da qui il motivo per cui volete che i sr. lo sappiano dentro e fuori - in modo che possano addestrare i junior.

È fondamentale che conoscano l'esatto valore massimo di un tipo di dati Int32? Normalmente no - quel livello di conoscenza banale serve a Google; ma forse la tua esigenza è quella di codificare su dispositivi vincolati alla memoria - in questo caso: assolutamente.

Ho fatto un colloquio e ho assunto degli sviluppatori. Non mando test a casa - è troppo facile avere l'aiuto di un amico. Non uso siti di test online - dato il modo in cui il punteggio deve essere automatizzato è banale da giocare. Non chiedo ai candidati di scrivere la risposta a fizzbuzz - quasi tutti hanno visto quel test e dovrebbero conoscere la risposta a memoria; tutti gli altri sono entrati in campo nell'ultimo anno e sono comunque jr. Non faccio nemmeno domande banali - essere in grado di recitare la risposta di solito significa solo che hai già sentito la domanda.

Cosa faccio per intervistare le persone:

• chiedo loro di descrivere un progetto precedente o due. L'unica cosa che mi interessa a questo punto è metterli a loro agio e farli parlare. Questo è un go/nogo, perché se non riesco a capire quello che dicono non posso lavorare con loro.

• Faccio loro alcune domande specifiche nella tecnologia che mi serve. Se si tratta di un server SQL, gli chiedo di aggiornare un'unità. Se è HTML, gli passo un file html a 10 linee con un paio di classi css e chiedo loro qual è l'output. Queste sono domande banali per persone con esperienza in queste aree, e rapidamente eliminano i pretendenti.

• Se cerco un Sr. dev, allora farò domande sulla conoscenza del dominio. Non cose sui casi limite, ma piuttosto sui principi fondamentali. Se ho bisogno di voi per condurre un progetto su un back end di contabilità, allora è meglio che abbiate una conoscenza di base dei principi contabili.

• Se sto cercando un Jr. dev, allora vi chiederò dei progetti pet. tutto quello che voglio sapere è il tipo di tecnologia utilizzata. Questo dovrebbe darti un indizio su quello che vogliono davvero fare. In altre parole, è improbabile che uno sviluppatore di C# faccia progetti in php. Onestamente non mi aspetto molto da un jr dev se non di essere addestrabile. Se stanno lavorando attivamente ad un progetto in un pet, allora posso addestrarli. Se sono il tipo che ha bisogno di persone che dicano loro cosa fare ci sono aziende molto più grandi in cui questi ragazzi possono lavorare.

Non faccio queste domande al volo, le potenziali risposte sono considerate in anticipo e si adattano a uno schema go/no go. Se una domanda non rientra in questo schema, allora non è rilevante. Inoltre, chiedo a ogni candidato le stesse domande, a meno che non sia convinto al 100% che non lo stia assumendo e a quel punto interrompo il colloquio.

Se per qualche motivo insistete ancora nel voler mandare a casa un test - assicuratevi che le competenze richieste per completare con successo il test siano sufficienti. in un ragionevole lasso di tempo sono in realtà le competenze che ti interessano.

Ho avuto una società che mi ha fatto fare un test a domicilio che prevedeva la scrittura di un fornitore di servizi di crittografia personalizzato. Ho completato il test perché era piuttosto interessante; mi hanno assunto. In nessun momento del mio tempo ho mai fatto qualcosa che riguardasse anche solo lontanamente la sicurezza, la crittografia o la matematica, a parte l'aggiunta di qualche numero. Mi chiedo quante persone hanno portato via con loro con quel test?

Un tempo credevo fermamente nei test di codifica e nella codifica delle lavagne bianche, ma ho iniziato a capire che sono praticamente inutili, perché

Cosa stai testando, comunque?

Un test sulle lavagne bianche, o un breve test di programmazione, ti dà qualche idea dell'individuo, ma in realtà non così tanto. A meno che non pensiate di far passare il tempo a qualcuno a scrivere codice su una lavagna bianca o codice in stile FizzBuzz.

Cosa vuoi?

Vuoi qualcuno che sia:

• appassionato
• disposto a imparare
• capace di risolvere problemi*
• risonantemente tecnico
• che aiuti il tuo team migliorare

*Nota, la maggior parte degli sviluppatori risolve i propri problemi sapendo quali termini cercare in Google.

L'ultima_ cosa che volete assumere è qualcuno che non è adatto al vostro team perché lo trascinerà in basso.

Come potete testarli?

• Chiedete loro di un progetto che gli è piaciuto. Se sembrano riluttanti a parlarne, prova a esprimere una leggera incredulità, ad esempio: “Non puoi fare X, vero? Se è qualcosa che li appassiona, ti correggeranno. Questo vi aiuterà anche a capire se sono tecnici o meno.
• Chiedete loro cose che hanno imparato di recente. O cosa hanno imparato dal progetto a cui hanno lavorato.
• Chiedete loro dell'ultima volta (o di una volta) in cui hanno perso qualche conoscenza. Come hanno ottenuto le informazioni di cui avevano bisogno? Sono andati da un compagno di squadra? Hanno cercato su Internet?
• Chiedete loro se c'è qualcosa che vorrebbero vedere migliorato nel loro attuale/ultimo team. Avevano bisogno di migliorare i messaggi di commit? Altre recensioni di codici? Più test? Più automazione?
• Chiedete loro quale tecnologia li entusiasma e perché.

Se avete qualcuno che è tecnicamente in grado di partecipare a questa conversazione, sarà la cosa più facile al mondo da dire se questa persona sarà la peggiore. Un esempio: abbiamo fatto venire un ragazzino a intervistarci - ha detto che in una scala da 1 a 10, le sue abilità Java erano come un 7-8. Non credo che sapesse nemmeno che Java era stato compilato in un file jar che è stato poi compilato in linguaggio macchina dalla JVM. Io mi classificherei forse un 2 o un 3 e _lo so.

In realtà gli è stata fatta la stessa domanda dal nostro CTO in un'intervista del giorno precedente, e il nostro CTO lo ha chiamato e gli ha spiegato che non c'era modo che fosse un 7-8.

Il nostro CTO gli ha anche chiesto del suo progetto preferito, che aveva a che fare con gli scanner portatili. Ma non è riuscito a spiegare nulla su come funzionassero, né sul fatto che usassero i sondaggi per evitare le attese. Non riusciva a spiegare una sola cosa tecnica.

Quel tizio non è stato assunto.

Capire il tipo di attributi che stai cercando, e poi capire come testare per questi

Ma devo proprio_ vedere come codifica!

Ok, va bene - ma a meno che non debba codificare in un silo, la cosa migliore da fare sarà assumerla come appaltatrice per un progetto piccolo e ben definito. Forse sta aggiungendo la possibilità di scaricare alcuni file da un FTP e poi scaricarli nel suo database. Qualcosa di semplice, che non richiede molte/qualsiasi conoscenza del dominio.

Fate lavorare i vostri candidati con uno o due dipendenti esistenti e pagateli per il loro tempo. Vedrete esattamente come lavorano e come lavorano bene con il team. Comunicano bene? Si frustrano facilmente? Sono persistenti?

Ci sono cose che si possono fare per assumere dipendenti migliori… ma un concorso di programmazione probabilmente non è uno di questi.

Dal punto di vista di una persona in cerca di lavoro, in genere evito i posti che richiedono più di 1 ora per codificare. Una volta sono andato in questo posto che richiedeva un progetto di codifica java di quasi 3 giorni. Ho fatto tutto e il tizio è rimasto impressionato, ma mi hanno detto di aver assunto qualcun altro dopo la seconda fase del colloquio. Quindi, dopo di allora, se vengo in un'azienda, ignorerei/passerei qualsiasi progetto che richieda più di un paio d'ore per essere completato. Il mio tempo è prezioso quanto il loro e preferisco non sprecarlo in cose che non mi porteranno da nessuna parte.

Detto questo, se il tuo esercizio di codifica è troppo lungo, forse la gente non è disposta a metterci il tempo. Io cercherei di ridurlo in modo tale che ci voglia al massimo un'ora, ma allo stesso tempo dimostrerei una comprensione della codifica e forse metterci una scadenza come “Per favore completare entro domani da COB” o qualcosa del genere. Possono ancora “copiare e incollare” qualcosa online, ma lo rendono difficile essendo specifici piuttosto che qualcosa che si legge online.

Come altri hanno notato, alcuni sviluppatori possono essere rimandati da un esercizio di programmazione di 1-2 ore per fare domanda di lavoro. Ciò che può funzionare meglio è una sessione di white-boarding, in cui il candidato risolve un problema su una lavagna durante il colloquio. In questo modo si ha l'opportunità di avere un colloquio di persona e al tempo stesso ci si assicura che ci siano anche delle scappatoie tecniche.

Questi problemi non dovrebbero essere estremamente difficili, o progettati per far inciampare uno sviluppatore. Un esempio classico è FizzBuzz . Questo permette di vedere come pensano, e anche di sapere che possono almeno programmare e non hanno bisogno di google come fare un loop.

A mio parere, il problema che avete qui non è necessariamente il test di programmazione. Prima c'è il colloquio tecnico telefonico e poi un test di lavoro da casa prima di un colloquio faccia a faccia. Sembra che stiate tenendo i vostri candidati a distanza e che li stiate lasciando all'ultimo minuto prima di incontrarli. A che punto vi aspettate che i candidati decidano che vogliono lavorare per voi ?

Presumo che il vostro annuncio di assunzione sia simile alla maggior parte e quindi si concentri sulla posizione, lo stipendio e una lista di competenze (desiderate). I candidati non sanno davvero su cosa lavorerebbero, né su cosa sarebbe il loro lavoro, né sull'ambiente o sulle persone con cui dovrebbero interagire. Non avete ancora venduto il lavoro a loro, e qui chiedete loro di dimostrare le loro capacità tecniche due volte prima che possano fare una sola domanda sul lavoro.

Vi suggerisco di provare a cambiare il formato del colloquio telefonico tecnico in una chat di 30-45 minuti sul lavoro che includa un sacco di opportunità per le domande dei candidati, poi 15 minuti di domande tecniche come schermo in modo da avere ancora la possibilità di scegliere i candidati migliori senza renderlo troppo oneroso.

Prenderei anche in considerazione di spostare la sfida della programmazione da fare sul posto prima dei colloqui. Sembrerebbe più realizzabile per i candidati, darebbe loro uno stimolo a rimanere in linea con il processo e si otterrebbe il vantaggio di osservare il vero tempo speso per la sfida (penso che potreste rimanere sorpresi).

Vuoi assumere programmatori che non sanno programmare?

Ho intenzione di azzardare che non lo fai.

Assumere programmatori che non riescono a risolvere i problemi e scrivere codice è un buon modo per rovinare una società tecnologica. E non sarai efficace nel disertare i programmatori che non sono in grado di programmare (e ce ne sono molti altri) se il tuo processo di assunzione non include una sorta di test di programmazione.

**Sei disposto ad abbassare i tuoi standard perché tutti stanno cercando di assumere programmatori? Come è stato notato nei commenti e nelle risposte, ci sono candidati che non si prenderanno la briga di fare esercizi di programmazione come parte di un colloquio di lavoro perché non ne hanno bisogno per ottenere un lavoro.

Ma sono davvero queste le persone che vuole assumere? Quelli che seguono il percorso di minor resistenza, che fanno ciò che è più vantaggioso per loro nel breve periodo, e che non si preoccupano abbastanza della vostra azienda per completare un semplice esercizio di programmazione? Questi non sembrano attributi positivi, e non danno molta fiducia in termini di capacità di trattenere quei candidati a lungo termine (il che è importante anche per un'azienda tecnologica, dato che le curve di apprendimento tendono ad essere ripide e il costo della sostituzione del personale esistente è molto alto).

Quindi lasciate che le altre aziende abbiano i programmatori che non possono nemmeno essere disturbati. Non volete assumerli in ogni caso. A differenza di loro, voi avete un piano. Uno che non si basa sulla fallacia “un programmatore è un programmatore”. Il vostro obiettivo dovrebbe essere la qualità e la sostenibilità, non il numero di persone.

**È spaventare i candidati un problema?

Generalmente no, purché siano spaventati per una buona ragione. Non volete assumere persone che non sono all'altezza. E alcune delle persone che dicono di “non potersi preoccupare” a causa dell'alta domanda potrebbero in realtà usarlo come scusa per coprire una situazione “non proprio così brava a programmare, quindi ci vorrebbe tutta la settimana per completare un esercizio di un'ora”.

E’ buono spaventare quei candidati. Volete assumere candidati capaci e motivati. Finché non spaventate anche quelli, siete bravi.

Ogni candidato che non spaventate è uno che dovete provare a valutare. E questo può essere difficile da fare se non date ai vostri candidati tecnici degli esercizi tecnici da utilizzare per la valutazione.

** Come posso migliorare il nostro processo di assunzione? **

Controlla il contenuto del tuo esercizio di programmazione. È ragionevole e appropriato per un contesto di colloquio?

Non vuoi che qualcosa che richieda giorni (o anche ore) per essere completato. Quello che volete è qualcosa di semplice per eliminare le persone che non sanno programmare, idealmente con abbastanza spazio per le sfumature che le persone che sanno programmare _sono in grado di differenziarsi. Tenete a mente ciò che state cercando di realizzare (eliminare i candidati non qualificati e non seri) e assicuratevi che i vostri contenuti siano adeguati a questo obiettivo. Non esagerate.

Se avete già del personale tecnico, potete usarlo per controllare la sanità mentale (e/o aiutare a progettare) il vostro esercizio.

E considerate anche il modo in cui amministrate l'esercizio. Se date loro un po’ di documentazione e dite “ecco, fatelo la prossima settimana e mandatemela per e-mail”, probabilmente sarà solo minimamente efficace.

Meglio se potete eseguire l'esercizio attraverso un portale web, che i candidati possono controllare e iniziare l'esercizio, e una volta iniziato un timer inizia il conto alla rovescia a partire da 1 ora. Poi o presentano qualcosa entro quell'ora, oppure no. Questo è meno aperto, mantiene meglio l'attenzione del candidato e fornisce una chiara scadenza/scatola del tempo, in modo che 1) non si resti ad aspettare tutta la settimana per un risultato che non arriverà mai, e 2) i candidati non qualificati non buttino via una settimana del loro tempo per cercare di completare l'esercizio di programmazione. Ottengono 1 ora, o risolvono il problema o non lo fanno, e si conosce immediatamente il risultato.

E ancora meglio sarebbe portarli qui per un colloquio sul posto. Presentateli a un membro del vostro team di sviluppo. Chiudeteli in una stanza insieme a una postazione di lavoro. Chiedete al vostro sviluppatore di iniziare con alcune domande generiche/soft per il colloquio, e poi possono programmare in coppia con il candidato per risolvere l'esercizio di programmazione. Questo vi dirà non solo se il candidato è in grado di codificare o meno, ma anche quanto bene lavora con il vostro team. Il vostro sviluppatore dovrebbe anche essere in grado di raccogliere molte informazioni aggiuntive che non otterrete guardando un mucchio di codice che un candidato ha scritto e poi vi ha inviato via e-mail.

Bottom line

No, non volete liberarvi del vostro esercizio di programmazione. Ma potreste volerlo rivedere per trovare il contenuto appropriato, assicurarvi che non ci voglia troppo tempo per risolverlo e guardare anche come lo state inserendo nel vostro processo di colloquio generale.

Un esercizio di take-home auto-diretto non è probabilmente l'approccio migliore. Ma la soluzione non è quella di eliminare completamente l'esercizio. No, a meno che non si sia d'accordo con l'assunzione di programmatori di merda, in ogni caso.

Meglio spaventare un sacco di candidati cattivi e una manciata di buoni che aprire le porte e assumerne alcuni cattivi.

Una cosa che nessuno sembra aver menzionato; anche se il test non è il vostro problema, dovreste cercare altri modi per attirare i talenti.

Se siete a caccia di brave persone sulla base del loro lavoro già pubblicato, non avete bisogno di eseguire il test su di loro.

Se vi mandano solo persone attraverso i reclutatori e il filtraggio, siete vulnerabili al fatto che le vostre esigenze e quelle dei reclutatori non si sincronizzano perfettamente. Vogliono mettere qualcuno con voi. Volete un ingegnere di alto livello. Se riescono a trovare un ingegnere di alto livello che sia fantastico perché tornerai da loro, ma se non ci riescono (e gli ingegneri di alto livello tendono ad avere cose che lasciano poco tempo per i colloqui), si accontenteranno di mettere solo un ingegnere moderato con un bel vestito. La perdita per loro è un po’ di reputazione a lungo termine, ma è minore rispetto al mancato raggiungimento dei loro obiettivi. Se questo non è vero nel tuo caso, tieniti forte a quel reclutatore e non lasciarlo mai andare, i reclutatori che danno priorità a un rapporto a lungo termine rispetto agli obiettivi sono diamanti preziosi in un oceano di caldarrosti.

Quello che vuoi fare è trovare candidati interessanti. Cacciare attraverso StackOverflow e GitHub per i migliori ingegneri (ho sentito che StackOverflow ha uno strumento per aiutare con questo ), controllare per le aziende tecnicamente interessanti che hanno prodotto un buon software ma che hanno incasinato le loro finanze o la monetizzazione, e appena licenziato 10 ingegneri di alto livello. Trascorrete il tempo lavorando presso le università, assistendo i progetti dell'ultimo anno. Individuare buoni candidati potenziali e fare amicizia con loro, preferibilmente di persona, in alternativa via remoto; anche se hanno delle offerte, i buoni ingegneri escono con buoni ingegneri. Inoltre, possono dirti cosa ne pensano del tuo processo di assunzione.

Ti sembra un lavoro impegnativo? Dovrebbe. Uno dei motivi per cui le assunzioni sembrano così “difficili” è che si cerca di farlo nel modo più efficiente possibile. Più tempo, cervello e risorse ci si dedica ad esso, più è facile. Se queste risorse sarebbero meglio spese per la spedizione del prodotto è l'eterna questione di gestione. Ma se si spende molto tempo in “filtraggio dei programmatori di merda”, questo è combustione del denaro. Almeno le fasi sopra descritte hanno un valore intrinseco che va oltre il processo di assunzione.

(*): Diavolo, assumili.

Non mi piacciono i test a domicilio come parte dei colloqui, per molti dei motivi già citati - prolungare il processo di assunzione, svalutare il tempo del candidato, potrebbe non essere richiamato comunque, ecc.

Il mio problema principale è che non è realistico il modo in cui il team lavora effettivamente e rende il processo di colloquio unilaterale. Un candidato vuole sapere se questo posto è adatto a lui, anche per quanto riguarda la cultura, il modo in cui il team si avvicina e risolve i problemi. In primo luogo si cerca anche la forma, compreso il modo in cui lavorano e se hanno le giuste competenze. Un test da portare a casa non offre al candidato l'opportunità di valutare le qualità morbide di un posto di lavoro e i datori di lavoro non possono imparare come il candidato ha affrontato il problema.

Una soluzione migliore potrebbe essere quella di dare al candidato un problema più aperto che può essere risolto in qualsiasi tipo di modo creativo. Si potrebbe anche limitarlo alla lingua X. Piuttosto che inviarlo via e-mail, invitateli a presentarlo a voi stessi e alla direzione. Questo dà loro autonomia e li incentiva a fare bene, perché promette un altro colloquio e dimostra che ci tenete a sapere cosa ne pensano.

Se dovete usare un test per vagliare quali candidati fanno il colloquio con i dirigenti superiori, includerei il test nel colloquio in modo che possiate discutere insieme il loro processo di pensiero.

Penso che lei abbia formulato la sua domanda in modo un po’ sbagliato, ma il modo in cui l'ha formulata riflette un comune malinteso sull'assunzione di programmatori. I candidati sono “spaventati” dal compito di programmazione, o stanno filtrando la vostra azienda a causa del compito?

Un aneddoto per dimostrare il mio punto di vista: mentre cercavo lavoro non molto tempo fa, ho visto una posizione per un'azienda che sembrava nella media. Il modo in cui descrivevano il loro processo di programmazione lo faceva sembrare abbastanza buono, ma c'erano pochissimi dettagli, quindi ero scettico. Forse erano un buon posto di lavoro, forse no. Ma ho pensato che avrei visto di arrivare ad una schermata telefonica in modo da poter capire i dettagli e vedere se erano così buoni come sembravano.

Ho cliccato sul posto di lavoro, e mi è stato subito chiesto di scrivere una lettera di presentazione. Ugh. Penso che ogni candidato odi le lettere di presentazione. Non conoscevo questa azienda né utilizzavo i loro prodotti, quindi cosa potevo dire di loro? Li ho cercati su Google, ho letto il loro sito web e le loro offerte di prodotti, ho capito dove avrei potuto inserirmi nel loro organigramma se fossi stata assunta, e ho trovato alcuni paragrafi che mi hanno “venduto”.

Successivamente ho fornito il mio curriculum e l'accesso al mio LinkedIn - ma subito dopo mi hanno chiesto di compilare la mia esperienza lavorativa con date e descrizioni. Queste informazioni sono sia sul mio LinkedIn che sul mio curriculum, era ridicolo dover fornire le stesse informazioni 3 volte. Ho chiuso la scheda del browser. 5 minuti dopo stavo facendo domanda ad un'altra azienda che offriva alcuni vantaggi davvero fantastici che la prima non offriva. Potevo candidarmi a un'altra azienda che offriva vantaggi migliori, più velocemente di quanto potessi saltare i cerchi che la prima azienda voleva da me.

Dovete essere sicuri che i vostri candidati siano investiti in la vostra azienda in particolare prima di presentare loro dei cerchi da saltare, altrimenti non salteranno. Fate questo?

Esempi di vantaggi qualitativi che vedo comunemente offrire dalle aziende tecnologiche:

1. 1. Lavoro a distanza.
2. 2. Computer/monitor gratuiti come bonus di firma. 3. L'azienda contribuisce a progetti open-source rispettati. 4. Rimborso per formazione professionale e/o conferenze.
3. Pranzi di ristorazione.
4. Pranzi di catering.
5. Opportunità di lavorare con tecnologie nuove o sconosciute. 8. “Cultura dell'avvio”, ovvero mancanza di politica/burocrazia. 10. Riconoscimento del nome: la vostra azienda o il vostro prodotto è ben noto. Ai candidati piace menzionare dove lavorano e sentire le persone rispondere con “Oh, che bello! Mi piacciono i loro prodotti”
6. 12. Obiettivi/visione aziendale caritatevole o rivoluzionaria. Alle persone piace scrivere codice che rende migliore la vita delle persone.
7. 12. Retribuzione superiore alla media. Il denaro copre una moltitudine di peccati organizzativi.

8. Questa lista non è completa, ma se la vostra azienda non offre una o più cose come le voci di quella lista, allora qualsiasi ostacolo nel vostro processo di assunzione potrebbe mandare un candidato a cercarne uno che lo faccia.

9. Quindi diciamo che, per qualsiasi ragione, non offrite o non potete offrire incentivi come quelli di cui sopra ai vostri candidati per convincerli a spendere gratuitamente per scrivere codice per voi. Allora cosa potete fare? Ho due alternative che la maggior parte dei candidati preferirà alle attività di programmazione impegnative:

Alternativa #1 - Pagare loro una tariffa oraria per fare il vostro compito di programmazione come se fossero un appaltatore. Questo li incoraggia a prendere la cosa sul serio sia per motivi professionali sia perché… vengono pagati. Questo vi costa denaro, ma anche qualsiasi forma di reclutamento. Se siete davvero bravi, potete anche trovare un modo per fargli diagnosticare e correggere un vero e proprio bug nel vostro codice, nel qual caso otterrete qualcosa di utile per i vostri soldi.

Alternativa #2 - Probabilmente hanno già scritto del codice gratis che vi mostreranno se glielo chiederete. La maggior parte dei programmatori hanno codice su Github, Bitbucket, siti web Q&A come Stack Overflow, o potrebbero fornirvi del codice che non hanno già pubblicato.

Perché fargli scrivere codice che non gli interessa quando invece potreste fargli condividere un progetto di passione con voi? E’ garantito che sarà meno noioso che leggere l'ennesima soluzione allo stesso problema generico per la centesima volta. E poiché il codice è già scritto, fa risparmiare tempo sia a voi che al vostro candidato. In più, potrete vedere che tipo di codice si divertono a scrivere, il che dà un'idea della loro personalità e di quanto si adatta bene alla vostra cultura aziendale.

Come risposta diretta alla risposta di Bobo (che è la risposta accettata perché il ragazzo l'ha scritta e l'ha accettata lui stesso, cosa che francamente mi sembra un po’ patetica):

Lei viene da una premessa totalmente sbagliata. Non voglio lavorare per te. Da dove ti viene l'idea che qualcuno voglia lavorare per te? Lei è solo una delle tante aziende che offrono un lavoro. Non voglio lavorare per voi. Voglio valutare la sua azienda, e se lei supera tutte le altre, è allora che voglio lavorare per lei.

Ci sono una dozzina di aziende in cui posso lavorare, lei è proprio da qualche parte nella fila. Prima guardo quali aziende ci sono, mando loro il mio CV, possono leggerlo ed essere adeguatamente impressionati o meno, poi di solito si ha una rapida conversazione telefonica in cui mi dimostrano di avere un lavoro interessante e io dimostro di avere le capacità, e qualsiasi test di codifica potrebbe arrivare proprio alla fine.

Il tuo test di portabilità ti mette proprio alla fine della coda. Per compensare dovrai inserire un range di stipendio che è di 10.000 sterline più alto degli altri. Trovare un lavoro richiede comunque molto tempo; chi lo fa dieci volte di più è alla fine della lista. Se posso scegliere tra l'invio di un CV e un colloquio telefonico con dieci aziende, e fare i compiti per voi, indovinate cosa farò.

Quindi, quello che succede è che trovate dei candidati che vogliono lavorare per voi perché non troveranno lavoro altrove.

Credo davvero che possa aiutare a stabilire chi conosce davvero le lingue elencate sul proprio curriculum.

Se questo è davvero il tuo obiettivo, prenderei in considerazione un approccio diverso. Come indicano altre risposte, SÌ, si dovrebbe sempre avere una domanda di codifica, ma le domande di codifica raramente entrano nei dettagli della lingua. Ho visto alcune domande che sono utili per testare questo:

1. 1. Confrontare e confrontare Java e C (o qualunque siano i due linguaggi rilevanti, sono sul curriculum del candidato, ecc. Quali sono le caratteristiche che secondo lei dovrebbero essere aggiunte al linguaggio? (O meglio, cosa ne pensa di questo particolare cambiamento proposto/recente del linguaggio?)

Gli ingegneri che hanno visto una cosa o due sanno come rispondere a queste domande abbastanza facilmente, e in pochi minuti.

Qual è il vostro problema aziendale?

Ignorando tutti gli argomenti a favore o contro particolari test, tutto si riduce ad un compromesso - più filtri spaventeranno alcuni buoni candidati, meno filtri faranno passare i candidati poveri che potreste dover sostituire subito dopo l'assunzione.

Tutto si riduce a guardare alla vostra situazione aziendale invece che alle pratiche generali.

Avete attualmente un problema in cui vi mancano candidati qualificati e non siete in grado di assumere con la rapidità necessaria per raggiungere i vostri obiettivi aziendali? Deve abbandonare questo compito di programmazione iniziale.

Attualmente ha un problema che non la soddisfa con la qualità delle sue recenti assunzioni? Allora è necessario implementare altri filtri come questo.

Avete tutti questi problemi, ed entrambi sono ugualmente dolorosi? Congratulazioni, avete trovato il giusto equilibrio per questo compromesso.

IMHO c'è quasi lo 0% di possibilità che un laureato fresco di laurea sia in grado di fare un codice di programmazione difficile a un livello di ingresso. Se il vostro test di codifica richiede una settimana di tempo per essere completato, allora dovreste chiaramente indicare nel vostro requisito che state cercando programmatori con almeno 2+ anni di esperienza, perché penso che dovrebbe essere richiesta molta esperienza per completare un lavoro di codice che richiede una settimana per essere completato. E penso che se siete alla ricerca di nuovi laureati, allora progettate il vostro test di conseguenza e potete trovare molte idee su internet oppure potete chiedere ai programmatori senior che lavorano per voi di progettare un test adatto per i nuovi laureati.

Pensavo di rispondere a questa domanda, è passato un anno da quando è stata pubblicata, e ci siamo attenuti ad essa.

TROVAZIONI

Positivi di approccio

1) Portate a casa i candidati demotivati e sostituiteli con candidati che vogliono davvero lavorare per voi. Questo da solo rende la cosa interessante, poiché persone motivate = dipendenti produttivi. Se non possono essere disturbati a fare un compito di 1 ora, questo la dice lunga sulla loro attitudine ad ottenere il lavoro.

2) Sono d'accordo con gli altri, che il test di portabilità a casa non dovrebbe durare più di un'ora - il mio è molto semplice. Ho avuto i seguenti risultati dall'averlo aggiunto nel processo di reclutamento-

a) Alcuni candidati non lo completano. Non vale la pena di essere assunto.

b) Alcuni candidati tentano ma lo completano male. Non vale la pena di essere assunto.

c) Alcuni candidati imbrogliano, a quel punto vale la pena di fare domande sul loro incarico. Lo abbiamo fatto con un candidato recente che non si è preoccupato di rispondere alla nostra e-mail sull'incarico. Non vale la pena di assumere.

d) Alcuni candidati, dopo aver sentito che c'è un incarico tecnico, ritirano improvvisamente la loro candidatura, dove prima mostravano un sacco di interesse. Probabilmente hanno schivato un proiettile.

e) Alcuni candidati si comportano molto bene, commentano il loro codice e in una o due occasioni forniscono la documentazione. Assunzioni degne di nota.

Negativi dell'approccio

1) Il ritiro della candidatura da parte dei candidati che vengono scoraggiati dal compito di portare a casa rende più lunga la ricerca di una persona adatta. 2) Non sempre si capisce se qualcuno ha imbrogliato, ma è per questo motivo che spesso viene supportato da un colloquio telefonico tecnico.

Esito di questo approccio

Esito di questo approccio

Uno dei nostri dipendenti che ho assunto con questo approccio si è rivelato essere un dipendente di spicco. Lavora ancora per noi dopo oltre un anno. È affidabile e tecnicamente talentuoso.

Un mouse sconosciuto o un layout di tastiera inaspettato (specialmente Mac vs PC), o un IDE diverso possono rallentare drasticamente le prestazioni senza alcuna differenza di competenza. Inoltre, un'applicazione completa spesso richiede molto codice boilerplate che uno sviluppatore potrebbe non avere abbastanza tempo per digitare o addirittura non ricordare. Avviare una nuova applicazione completamente da zero è in realtà un compito molto raro; la maggior parte del lavoro si concentra sull'estensione o sul miglioramento del codice esistente.

Quindi suggerisco di dare solo compiti molto brevi e più attentamente preparati durante il colloquio. La cosa migliore è chiedere di scrivere una funzione che deve prendere determinati parametri e restituire il risultato spiegato e vi consiglio di farlo su carta, evitando del tutto il computer.

Li manderei a un quiz online dove puoi filtrare le persone che non ne hanno la minima idea. Almeno avresti un'idea se sanno di cosa stanno parlando.

All'inizio della mia carriera i cacciatori di teste mi hanno detto che “hai a che fare con persone che leggono la scatola e mettono un'applicazione sul loro curriculum”. Suppongo che questo possa ancora accadere ai giovani e agli ingenui, ma una volta che vieni distrutto in qualche colloquio impari che questo è un pessimo consiglio…

Di recente ho ricevuto un test di ammissione a casa. Si trattava di un'applicazione completa che aveva bisogno di connettersi a un socket server che doveva simulare un feed lento. Il client si aggiornava dinamicamente, era in grado di annullare il feed, e di scrivere e leggere XML.

Ho avuto voglia di imparare i socket in ogni caso, visto che sto pensando di usarli per un server di poker che sto scrivendo.

Volevo imparare XMLreader e XMLwriter.

All'inizio pensavo di dimenticarlo. Ma poi l'ho vista come un'opportunità per dimostrare cosa sono in grado di fare. Non ho una laurea in CS, quindi mi mancano alcune cose teoriche. Mi hanno chiesto quali sono i 3 pilastri dell'OOP e hanno voluto dire chi se ne frega.

Il mio messaggio è che le persone che vogliono il lavoro devono completare il test.