Per valutare bene una risorsa occorre leggere il codice sorgente che ha consegnato e che è stato utilizzato oltre che rivisto, le soluzioni che ha escogitato, modi e tempi in cui ha corretto i bug, e poi anche farsi un'idea delle persone che usano le sue soluzioni, dei feedback che hanno dato... Insomma, non storcete il naso: bisogna davvero guardare ai suoi contributi open source: sono sotto gli occhi di tutti (cappellate e genialate incluse), non sono protetti da clausole di segretezza, confermano se c'è una passione oltre che una capacità, fanno capire come scrive e cosa rilascia... Molto meglio di ciò che possono fare un curriculum e diversi colloqui.
Perciò la prima domanda deve essere: quali sono i progetti open source a cui hai collaborato? Quale è il tuo portafoglio progetti su Github o piattaforma simile?
Se uno ha pubblicato poco o niente, significa che o è troppo timido (teme che i suoi sorgenti facciano schifo? ha paura di ricevere feedback negativi o di non riuscire a migliorarsi?), oppure che lavora solo per sopravvivere (per cui al di fuori dell'orario di lavoro pensa ad altro, cioè non ha passione), o che non riesce a rendere minimum viable product i propri progetti perennemente incompleti, o semplicemente gli manca creatività. Tutti e quattro sono pessimi indicatori, tanto più che la maggioranza dei tool indispensabili in ambiente di lavoro sono open source.
La seconda domanda deve essere: quali sono i tuoi contributi al risolvere problemi pubblicati on-line? Per esempio: quale è la tua "reputazione" su domande fatte e domande a cui hai dato risposta su siti come StackOverflow?
Infatti chi non domanda non apprende, oppure si limita a chiedere a Google qualcosa di già pronto, o semplicemente non sa domandare (non necessariamente per timidezza). Inoltre, chi non risponde non ha niente da dire, cioè non sa cimentarsi su problemi complicati o assai specifici. Troppo facile mettere insieme soluzioni già pronte e incassare lo stipendio a fine mese e chiamarla "esperienza pluriennale" (come se questa, da sola e senza bisogno di verifiche, garantisse automaticamente qualità e utilità).
Spesso questi soggetti si giustificano dicendo che basta parlare coi colleghi per trovare soluzioni. Se in certi casi può essere vero, in generale significa dipendere troppo dai propri senpai - e se capita qualcosa di urgente e i tuoi colleghi esperti sono assenti? Quando si viene pagati a deliverables, nessuno ha voglia di aiutarti per più di venti secondi (e ti è già andata bene), e a memoria d'uomo nessun problema tecnico serio è mai stato veramente risolto con due chiacchiere in pausa caffè (cioè stando lontani dai documenti e concentrati su altro); telefonate e meeting sono una pura perdita di tempo (impossibile negarlo, al massimo servono per dire chi fa cosa), le email richiedono troppo tempo per essere ordinate (e restano comunque dispersive); solo i sistemi di ticketing sono meno inefficienti (a condizione che vengano usati con serietà anziché come l'ennesimo ammennicolo di cui sotto sotto tutti vorrebbero fare a meno).
La terza domanda deve riguardare quanto si investe su sé stessi. Cioè - ad esempio - le certificazioni prese a pagamento, specialmente quelle in cui non superando l'esame finale sono persi i soldi spesi per prenderle. Se uno cresce quasi esclusivamente per contributi "esterni" significa che non investe nella propria crescita, aspettando che vi investano "altri".
Chi investe su sé stesso lo fa per non essere come la massa: lo fa su qualcosa di nicchia, e lo fa bene. Di "programmatori Java" o di "esperti SQL" se ne trovano fin troppo facilmente: cos'è che ti distingue? Quando uno si qualifica come "esperto MySQL + Oracle + SQLite + PostgreSQL" significa che di database ne capisce il minimo indispensabile. Come il resto della massa di "esperti SQL".
Vale anche per attività esterne, come ad esempio l'aver tenuto una talk a qualche conferenza o aver pubblicato un libro o un brevetto: se uno riesce a tenere una talk non dico al Chaos Communication Congress ma almeno a PGconf.eu, RustFest, RubyConf o simili, significa che ha superato una non banale peer review oltre ad aver investito tempo e soldi. Anche un blog su temi informatici può essere un buon indice, qualora i contenuti siano di qualità (non un Aranzulla) e il contenuto dei commenti lo confermi (più con le domande specifiche che con i complimenti).
Inutile aggiungere che tutti questi esempi già da soli dimostrano la padronanza dell'inglese ed eventualmente di altre lingue, la capacità di pianificare, organizzarsi, collaborare, la creatività, il saper estrarre conoscenze e risultati, la capacità di trovare soluzioni... Nelle aziende generalmente si ignora che il vero lavoro in team è quello fatto da individualisti capaci che fanno la propria parte senza coinvolgere (cioè rallentare) gli altri. Ignorandolo, diventa statisticamente normale che più di due terzi dei progetti IT falliscano.
Insomma, le robette che si scrivono nei curriculum - aziende presso cui si è prestato servizio, anni di "esperienza", titoli di studio (tranne che di università estere particolarmente selettive), non significano granché. E non vale la pena assumere uno con tante conoscenze ma poca capacità di sfruttarle e di farle crescere.
Nessun commento:
Posta un commento