Valutazioni tecniche per data scientist che non sono solo trivia SQL

Cosa significa davvero "data scientist" nella tua azienda

Prima di disegnare la valutazione, nomina il ruolo onestamente. L'etichetta copre lavori selvaggiamente diversi:

• DS analitica. SQL, dashboard, analisi esperimenti, comunicazione con stakeholder.
• DS ML. Training modelli, feature engineering, valutazione, a volte produzionizzazione.
• DS di ricerca. Modellazione novel, rigore statistico, lavoro pubblicabile.

Un singolo test non può misurare tutte e tre. Scegliere quale è questa assunzione è la prima decisione.

Forme di valutazione per sapore di ruolo

DS analitica

Dai loro un dataset disordinato (CSV, ~10MB, intenzionalmente con duplicati, null e un sottile mismatch di definizione in una colonna). Chiedi tre cose di business di ambiguità crescente:

1. Concreto: "Qual è il tasso di retention a 7 giorni?"
2. Leggermente ambiguo: "La retention è cambiata da quando è stata lanciata la feature X?"
3. Aperto: "Cosa in questi dati il team di prodotto dovrebbe sapere?"

Punteggia: correttezza SQL/Python su Q1, ragionamento statistico su Q2, giudizio e comunicazione su Q3.

DS ML

Dataset tabulare con un target. 90 minuti. Ambiente notebook.

Punteggia: scelte di feature engineering, metodologia di model evaluation (non metrica finale — come hanno valutato), consapevolezza di leakage e overfitting, comunicazione di trade-off in un writeup breve.

La metrica non conta. Una candidata che ottiene 0,82 AUC con cross-validation pulita batte una che ottiene 0,91 leakando il target attraverso una feature.

DS di ricerca

Una review breve di paper o proposta tecnica. O una critica metodologica di un'analisi difettosa. Testa rigore e capacità di lettura, entrambe più importanti del coding per questo sapore.

Valutare senza bias

Anonimizza. Sempre. Nomi, scuole, datori di lavoro precedenti — toglili prima della revisione.

Usa valutazione ancorata su rubrica. Il servizio di valutazione di ClarityHire fa la prima passata di rubrica con un LLM, anonimizzato; i reviewer vedono il punteggio IA più il lavoro e sovrascrivono con motivazione. Per le submission DS specifically, questo fa emergere cose come cross-validation mancante o split train/test impropri che il reviewer può verificare rapidamente.

Cosa non fare mai

• Domande SQL alla lavagna. Il mezzo cambia la skill — molte grandi analiste non sanno scrivere join a memoria ma le scrivono fluentemente contro un vero DB.
• "Implementa gradient descent da zero." Testa la memorizzazione di un esercizio undergraduate, non skill di lavoro.
• Take-home più lunghi di 3 ore per fase di screen. Stai pagando in larghezza di pipeline.

Abbina a un colloquio

Qualunque sia la valutazione, falla seguire da una discussione di 45 minuti sulla submission della candidata. Il walkthrough intercetta quasi tutti i problemi di integrità che la valutazione da sola perde, e la rubrica per la discussione (sondando profondità sulle loro stesse scelte) è diretta.