Come valutare un data scientist e un profilo tecnico specializzato

Assumere il primo data scientist, o il primo specialista di sicurezza, pone un problema particolare: nessuno in azienda sa fare quel lavoro, quindi nessuno sa riconoscere chi lo fa bene. Il rischio è scegliere chi usa le parole giuste invece di chi risolve i problemi.

Il metodo che segue parte dal data scientist e vale, con le dovute differenze, per qualunque profilo specializzato.

Parti dal problema da risolvere

Prima di cercare, scrivi in poche righe che cosa vuoi ottenere. Quali dati hai, dove stanno, quanto sono puliti? Quale decisione vuoi migliorare? Il risultato atteso è un report, una previsione da usare ogni giorno, una funzione dentro un'applicazione?

Le risposte possono cambiare il ruolo da cercare:

• Data Scientist: analizza i dati e costruisce modelli statistici o di machine learning per rispondere a domande di business.
• Data Engineer: costruisce e mantiene le pipeline che raccolgono, puliscono e rendono disponibili i dati.
• AI Engineer: integra modelli, compresi i modelli linguistici, in applicazioni che funzionano in produzione.
• Business Intelligence Specialist: trasforma i dati in report e cruscotti per chi decide.

Se i tuoi dati sono sparsi in fogli di calcolo e gestionali che non si parlano, il primo profilo che ti serve è probabilmente un data engineer, non un data scientist.

Cosa guardare nel percorso

Nel CV e nel primo colloquio cerca progetti concreti, non elenchi di strumenti. Le domande utili sono semplici: che problema c'era, che dati c'erano, che cosa ha fatto la persona e che cosa è successo dopo.

• Risultati in produzione: un modello usato davvero da qualcuno dice più di dieci analisi rimaste in un notebook.
• Lavoro con dati reali: i dati aziendali sono incompleti e disordinati; chi ci ha lavorato lo racconta senza che tu lo chieda.
• Capacità di spiegare: il valore di un'analisi dipende da quanto bene arriva a chi deve decidere.
• Lavoro riproducibile: versionamento del codice e dei dati, ambienti documentati, controlli automatici sui dati. Sono il segno di chi ha lavorato in un team, non da solo.
• Lavoro pubblico: repository, articoli, interventi a conferenze. Sono segnali utili, ma la loro assenza non è un difetto: chi lavora su dati aziendali di solito non può pubblicarli.

Una prova pratica realistica

La prova è il momento in cui vedi la persona al lavoro. Per un data scientist funziona bene un caso costruito su un problema simile al tuo: un dataset anonimo o inventato, una domanda di business e un tempo massimo dichiarato.

Non valutare solo il risultato finale. Guarda:

• come esplora i dati e quali controlli di qualità fa prima di costruire un modello;
• quale metrica sceglie e perché, rispetto all'obiettivo di business;
• quali alternative scarta e con quali argomenti;
• come presenta il risultato a una persona che non è del mestiere;
• che cosa farebbe con più tempo o più dati.

Chiudi con una discussione sulla prova: è lì che capisci se le scelte erano ragionate o fortunate. E chiedi un lavoro che non userai: la prova serve a valutare, non a ottenere lavoro gratis.

Le domande da fare

• Raccontami un modello che hai portato in produzione. Che cosa è andato storto dopo il rilascio?
• Come hai capito che i dati erano affidabili? Che cosa hai fatto quando non lo erano?
• Come spiegheresti questo risultato a un direttore commerciale?
• Quando hai deciso che il machine learning non serviva?
• Come controlli che un modello continui a funzionare nel tempo?

Non cercare la risposta perfetta. Cerca esempi concreti, la capacità di ammettere un errore e il collegamento costante con il problema di business.

I segnali d'allarme

• parla di strumenti e librerie, ma non dei problemi che ha risolto;
• non sa spiegare la metrica che ha usato né perché l'ha scelta;
• non fa domande sui dati né sull'obiettivo prima di proporre una soluzione;
• promette un'accuratezza precisa prima di aver visto i dati;
• non riesce a spiegare il proprio lavoro senza gergo.

Un solo segnale non basta a scartare un candidato. Due o tre insieme, invece, meritano un approfondimento prima di andare avanti.

Lo stesso metodo per altri profili

Problema chiaro, prova realistica, domande su casi concreti: lo schema vale per ogni ruolo specializzato. Cambia il contenuto della prova:

• per un profilo di cyber security, commentare un rapporto di vulnerabilità o descrivere come proteggerebbe un servizio esposto su internet;
• per un DevOps / SRE, ricostruire un incidente reale: che cosa è successo, come l'avrebbe individuato, che cosa cambierebbe dopo;
• per un Cloud Engineer, disegnare un'architettura con un vincolo di costo e uno di disponibilità;
• per un AI Engineer, progettare una funzione basata su un modello linguistico: come ne misurerebbe la qualità, come gestirebbe le risposte sbagliate, quanto costerebbe farla funzionare ogni giorno.

Chi fa la valutazione

Serve qualcuno che conosca la materia. Se in azienda non c'è, hai due strade: farti affiancare da un tecnico esterno per la prova e i colloqui, oppure affidare la ricerca a chi fa ricerca e selezione personale IT con la valutazione tecnica inclusa.

Per un ruolo specializzato contano anche le referenze. Chiedi di parlare con chi ha lavorato con il candidato su un progetto simile e fai domande precise: che cosa ha consegnato, come lavorava con il resto del team, a chi lo affiderebbe di nuovo.

Con il servizio di recruitment di RelyBytes i candidati passano da colloqui tecnici dal vivo prima di arrivare a te, la ricerca è gratuita e ricevi una shortlist garantita entro 4 giorni lavorativi. Se invece ti serve il profilo per un progetto a termine, con Talent as a Service lo inserisci nel team senza assumerlo.