Le metriche SQL che interessano davvero agli intervistatori (da colloqui reali)

Dopo alcuni colloqui SQL, è facile supporre che ogni azienda verifichi qualcosa di diverso. Dopo 11 colloqui, questa supposizione ha smesso di reggere. Nonostante le differenze tra le aziende e i formati, le stesse domande sulle metriche continuavano a ripetersi. Questo articolo riassume ciò che ho visto più spesso e ciò che questi modelli dicono su come funzionano realmente i colloqui SQL.

Tra novembre 2023 e aprile 2025, ho partecipato a 11 colloqui per analisti di dati che includevano test tecnici SQL. Sebbene le aziende e i formati fossero diversi, le domande SQL seguivano modelli chiari e ripetibili. Gli stessi tipi di metriche ricorrevano continuamente, indipendentemente dalle dimensioni dell'azienda o dal settore.

In questo articolo, analizzo le domande dei colloqui SQL di quei colloqui e le classifico utilizzando i modelli metrici SQL introdotti in articoli precedenti, tra cui la serie Sales Growth Dataset Exploration . Invece di esplorare le metriche all'interno di un singolo set di dati, questo articolo si concentra su come le domande dei colloqui SQL si raggruppano attorno a tipi di metriche specifici.

L'obiettivo di questo articolo è semplice: mostrare quali metriche SQL compaiono più spesso nei colloqui reali, in modo da poter dare priorità alla preparazione in modo più efficace. Piuttosto che cercare di coprire ogni possibile argomento SQL, questa analisi evidenzia dove il tempo dedicato allo studio tende a dare i risultati migliori. Questo è anche il motivo per cui la pratica strutturata di SQL incentrata su problemi di reporting reali, come gli esercizi utilizzati nei corsi LearnSQL.it, tende ad allinearsi più strettamente con ciò che viene effettivamente testato nei colloqui rispetto alla preparazione SQL ad hoc o in stile puzzle.

Nel corso dell'articolo, accenno anche a come viene testato l'SQL nei colloqui, come vengono valutate le risposte e perché alcuni modelli di metriche compaiono molto più frequentemente di altri. Questa non è una guida alla strategia di colloquio per azienda o settore, e non include domande esatte o nomi di aziende. L'attenzione è rivolta ai modelli ricorrenti e a ciò che rivelano sulle competenze SQL fondamentali che gli intervistatori testano costantemente.

Se ti stai preparando per colloqui di lavoro come analista di dati con un forte focus sull'SQL e vuoi concentrarti su ciò che effettivamente viene richiesto nella pratica, questo articolo riassume i modelli che ho incontrato più spesso e le lezioni che ne derivano.

Metodi di valutazione SQL incontrati nei colloqui

Nel corso delle 11 interviste, l'SQL è stato valutato utilizzando tre diversi formati di test. Sebbene le competenze SQL di base fossero simili, il formato del test ha influenzato in modo significativo il modo in cui sono state valutate le risposte e ciò che gli intervistatori sembravano privilegiare.

Portali online a tempo

Il primo formato era un portale online a tempo, tipicamente ospitato su piattaforme come HackerRank. Questi test erano limitati a circa 20-50 minuti e di solito consistevano in una o due domande SQL. Poiché l'ambiente è standardizzato e non assistito, le domande tendono ad essere più semplici nella struttura ma rigorose nell'esecuzione. La correttezza e la velocità sono fondamentali e le soluzioni vengono generalmente valutate come superate o fallite.

Colloqui SQL dal vivo utilizzando un IDE condiviso

Il secondo formato era un colloquio SQL dal vivo condotto in un IDE condiviso durante una sessione virtuale. In questi colloqui, spesso mi era permesso scrivere SQL senza eseguirlo, il che riduceva l'enfasi sulla sintassi esatta e spostava l'attenzione verso la correttezza logica e il ragionamento. Poiché gli errori di sintassi erano meno costosi, gli intervistatori tendevano a porre più domande o a introdurre ambiguità, a volte aggiungendo ulteriori domande a quelle iniziali. La valutazione in questo formato era raramente binaria e rifletteva invece la chiarezza con cui veniva comunicato il ragionamento.

Compiti SQL da svolgere a casa

Il terzo formato era un compito SQL da svolgere a casa, solitamente consegnato sotto forma di documento contenente schemi, istruzioni per la creazione di tabelle e domande multiple. Questi compiti dovevano essere completati in uno o due giorni e includevano un numero maggiore di domande, spesso da cinque a dieci. Sebbene le singole domande non fossero sempre più difficili dal punto di vista concettuale, erano più dettagliate e richiedevano più tempo. Come i colloqui IDE dal vivo, i test da svolgere a casa venivano valutati in modo soggettivo, con la struttura, la spiegazione e le ipotesi che giocavano un ruolo più importante nella valutazione finale.

In tutti e tre i formati, il metodo di valutazione influiva direttamente sul significato di "buona prestazione". I portali a tempo premiavano soluzioni rapide e precise. I formati dal vivo e da svolgere a casa attribuivano maggiore importanza al modo in cui le risposte erano strutturate, spiegate e adattate a enunciati vaghi o imperfetti. Questa differenza nel contesto di valutazione diventa importante quando si interpretano i modelli metrici SQL che compaiono più frequentemente nei colloqui.

Come sono state valutate le risposte SQL

Il modo in cui sono state valutate le risposte SQL variava in modo significativo a seconda del formato di prova. Nelle valutazioni a tempo sui portali, la valutazione era tipicamente binaria. Le query producevano il risultato atteso entro i limiti della piattaforma oppure no. C'era poco spazio per crediti parziali, approcci alternativi o spiegazioni. In questi contesti, la correttezza e la velocità hanno superato tutte le altre considerazioni.

I colloqui SQL dal vivo e i compiti da svolgere a casa sono stati valutati in modo diverso. In entrambi i casi, le risposte sono state raramente giudicate semplicemente come giuste o sbagliate. La valutazione si è invece basata su una scala che teneva conto di come era stata costruita la soluzione, di come erano state gestite le ipotesi e di quanto fosse stato comunicato chiaramente il ragionamento. Gli intervistatori spesso cercavano segnali al di là della query finale, ad esempio se il candidato avesse compreso la granularità dei dati, gestito i casi limite o scelto un approccio ragionevolmente scalabile.

In diversi colloqui, ho riscontrato schemi di valutazione che assomigliavano più a un punteggio informale che a un rigido sistema di promossi o bocciati. Una soluzione che soddisfaceva i requisiti di base poteva essere considerata accettabile, mentre una performance migliore richiedeva la dimostrazione di un approccio alternativo, la discussione dei compromessi o l'identificazione di potenziali problemi con i dati. In alcuni casi, due candidati potevano arrivare a risultati corretti ma essere valutati in modo diverso in base alla qualità della spiegazione delle loro decisioni.

Un altro fattore era che le prestazioni SQL non venivano sempre valutate isolatamente. Alcuni processi di colloquio includevano più round tecnici e le decisioni finali venivano prese tenendo conto di tutti i round. Un colloquio SQL forte poteva essere compensato da prestazioni più deboli in altri ambiti e viceversa. Per questo motivo, spesso era difficile determinare se un rifiuto riflettesse specificamente le prestazioni SQL o il risultato complessivo del colloquio.

Nel loro insieme, queste differenze di valutazione spiegano perché i risultati di superamento o fallimento da soli non sono un modo affidabile per valutare le prestazioni del colloquio SQL. Aiutano anche a chiarire perché i modelli metrici SQL ricorrenti sono più utili da studiare rispetto alle singole domande. La sezione successiva introduce il framework dei modelli metrici utilizzato per classificare le domande del colloquio in questa analisi.

Breve riassunto del quadro dei modelli metrici SQL

In questa analisi, ho classificato le domande del colloquio SQL utilizzando il quadro dei modelli metrici SQL introdotto in un precedente articolo sulla risoluzione dei problemi SQL basata sui modelli. Tale quadro raggruppa le domande SQL in base al tipo di modello calcolato piuttosto che in base a caratteristiche o funzioni SQL specifiche.

I modelli utilizzati in questo articolo sono:

• KPI: metriche a valore singolo che riassumono le prestazioni complessive
• Breakdown – metriche segmentate in base a una o più dimensioni
• Ratio – metriche formate dalla divisione di due aggregati correlati
• Rank – metriche ordinate all'interno di un gruppo
• Totale cumulativo/corrente – metriche che si accumulano nel tempo
• Media mobile – metriche livellate su un intervallo di tempo variabile
• Variazione percentuale/Crescita – metriche che confrontano i valori tra periodi diversi

Raggruppare le domande in base al modello di metrica rende più facile identificare ciò che le interviste verificano costantemente: non la sintassi o trucchi SQL isolati, ma la capacità di definire, calcolare e ragionare sulle metriche aziendali.

Una spiegazione completa del framework, inclusi esempi e insidie comuni, è riportata nell'articolo originale: Esplorazione del set di
dati sulla crescita delle vendite – Utilizzo della cheat sheet dell'analista di dati su dati di vendita reali.

Con questo framework in atto, la sezione successiva riporta la frequenza con cui ciascun modello di metrica è apparso nei colloqui.

Risultati: campione di colloqui e distribuzione delle domande

Questa analisi si basa su 11 colloqui con analisti di dati condotti tra novembre 2023 e aprile 2025 che includevano domande tecniche su SQL. Sono stati inclusi solo i colloqui con una valutazione esplicita di SQL. Nel corso di questi colloqui sono state poste diverse domande su SQL, ottenendo un campione totale sufficientemente ampio da osservare una chiara ripetizione nei tipi di metriche.

Distribuzione delle interviste per gruppo aziendale

Le interviste hanno riguardato aziende di diverse dimensioni e settori. Per evitare di dare eccessiva rilevanza a singole aziende, le interviste sono state raggruppate per categoria.

Totale interviste: 11

Sebbene il campione sia limitato e concentrato geograficamente, la ripetizione dei tipi di domande SQL in diversi gruppi aziendali suggerisce che i modelli osservati non sono isolati a una singola categoria.

Domande dell'intervista SQL per modello di metrica

Ogni domanda SQL è stata classificata utilizzando il framework dei modelli metrici SQL descritto in precedenza. La tabella seguente mostra la frequenza con cui ciascun modello è apparso nelle interviste.

La distribuzione mostra una forte concentrazione in un numero limitato di modelli metrici, con domande di tipo Breakdown e Ratio che compaiono molto più frequentemente di tutte le altre. Metriche più avanzate basate sul tempo e su finestre sono apparse raramente in questa serie di interviste.

La sezione successiva interpreta questi risultati e spiega perché determinati modelli metrici dominano i colloqui SQL.

Interpretazione: perché determinati modelli metrici dominano i colloqui SQL

La distribuzione dei modelli metrici SQL in queste interviste mostra una chiara concentrazione intorno alle domande di tipo Breakdown e Ratio. Questo non è casuale. Questi due modelli rappresentano il fondamento del modo in cui le aziende pongono domande analitiche e di come ci si aspetta che gli analisti di dati ragionino sulle prestazioni.

Le domande di tipo Breakdown appaiono più frequentemente perché verificano se un candidato è in grado di passare da una metrica di alto livello a una visione segmentata. In pratica, ciò significa comprendere come definire la granularità corretta dei dati, applicare i join senza gonfiare i risultati e raggruppare le metriche in base a dimensioni rilevanti come tempo, regione, prodotto o tipo di utente. Una query Breakdown corretta dimostra che il candidato comprende non solo la sintassi SQL, ma anche come si comportano le metriche quando vengono suddivise per dimensioni.

Le domande sul rapporto appaiono frequentemente per ragioni simili. I rapporti richiedono un attento allineamento tra numeratore e denominatore, un filtraggio coerente e la consapevolezza dei casi limite, come la divisione per zero o i dati mancanti. Dal punto di vista del colloquio, le metriche di rapporto rivelano rapidamente se un candidato comprende cosa rappresenta una metrica o se si limita ad aggregare meccanicamente le colonne. Anche quando l'SQL è relativamente breve, il ragionamento che sta dietro spesso non lo è.

Le domande su KPI e classifiche compaiono meno frequentemente, ma comunque in modo costante. I KPI a valore singolo verificano se un candidato è in grado di definire chiaramente una metrica e aggregarla correttamente, mentre le domande sulle classifiche introducono concetti di ordinamento e partizionamento comuni nella reportistica, ma secondari rispetto alla costruzione delle metriche di base.

Modelli più avanzati, come i totali cumulativi, le medie mobili e la variazione percentuale, compaiono molto meno spesso in questa serie di colloqui. Questi modelli si basano in genere su funzioni a finestra e logica delle serie temporali, che sono competenze importanti ma non fondamentali per la maggior parte delle attività quotidiane di reporting degli analisti di dati. La loro minore frequenza suggerisce che i colloqui danno la priorità alla correttezza e alla chiarezza nella logica metrica di base rispetto alle funzionalità SQL avanzate.

Nel complesso, la distribuzione dei modelli indica che i colloqui SQL enfatizzano la definizione, la segmentazione e il confronto delle metriche piuttosto che la complessità sintattica. Gli intervistatori sembrano utilizzare SQL come un modo per valutare il modo in cui i candidati ragionano sui dati e sulle questioni aziendali, non quante tecniche SQL avanzate sono in grado di applicare isolatamente.

Conclusioni

Questa analisi si basa su un campione limitato di 11 colloqui con analisti di dati della Bay Area, ma la concentrazione dei tipi di domande era sufficientemente coerente da far emergere priorità chiare.

Le domande di scomposizione e rapporto hanno dominato il set di colloqui. Il tempo di preparazione è meglio impiegato per ottenere risultati corretti: definire le metriche con la giusta granularità, unire le tabelle senza gonfiare i risultati e raggruppare i dati in modo che corrispondano alla questione aziendale. Queste competenze sono rafforzate in corsi fondamentali incentrati sulla reportistica, come SQL per principianti , Funzioni SQL standard e SQL Basic Reporting su LearnSQL.it , dove le query sono strutturate attorno a metriche reali piuttosto che a sintassi isolate.

I modelli metrici avanzati, come i totali parziali, le medie mobili o i calcoli di crescita, sono apparsi molto meno spesso. Si tratta di aggiunte utili, soprattutto per i ruoli che richiedono un uso intensivo di reportistica, ma non sostituiscono le solide basi. I corsi che trattano argomenti come Window Functions (Funzioni Finestra) , Query ricorsive e SQL GROUP BY Extensions su LearnSQL.it hanno più senso una volta che i modelli Breakdown e Ratio sono già consolidati.

Nel complesso, i risultati suggeriscono che i colloqui SQL premiano la chiarezza nel ragionamento metrico più che l'ampiezza delle funzionalità SQL. Una preparazione che enfatizza la costruzione di metriche di base e l'uso corretto dei join è più in linea con ciò che appare nelle domande dei colloqui reali.

Conclusioni

Questo articolo ha analizzato le domande dei colloqui SQL di 11 colloqui reali con analisti di dati per identificare quali modelli metrici appaiono più spesso nella pratica. Anziché concentrarsi su tecniche SQL isolate, l'analisi ha raggruppato le domande in base al tipo di metrica calcolata, rivelando una chiara concentrazione intorno ai modelli di suddivisione e rapporto in tutte le aziende e in tutti i formati di colloquio.

I risultati suggeriscono che i colloqui SQL enfatizzano costantemente la costruzione delle metriche e la logica di reporting rispetto alle funzionalità SQL avanzate. Gli intervistatori sembrano utilizzare queste domande per valutare se i candidati sono in grado di definire correttamente le metriche, segmentarle in modo significativo e ragionare sui confronti in modo da riflettere il lavoro analitico reale.

Il framework SQL Metric Pattern e il Data Analyst Cheat Sheet offrono un modo strutturato per affrontare questi problemi combinando la tecnica SQL, la definizione delle metriche e il contesto aziendale. Per i candidati che desiderano esercitare ripetutamente queste competenze su diversi set di dati e livelli di difficoltà, l'accesso a una serie ampia e strutturata di corsi è più importante che passare da una risorsa all'altra senza alcun collegamento. È qui che un'opzione come il piano SQL Completo per sempre trova la sua naturale collocazione, poiché consente la pratica a lungo termine di modelli metrici sia di base che avanzati senza dover ottimizzare la selezione dei singoli corsi.

Questo articolo si concentra deliberatamente sui modelli di base piuttosto che sulla strategia di colloquio. Un'analisi più approfondita potrebbe suddividere ulteriormente le domande in base al formato di prova o esplorare i sottomodelli comuni all'interno di ciascun tipo di metrica, ma i risultati qui riportati indicano già una conclusione chiara: padroneggiare la logica metrica di base offre il massimo rendimento nella preparazione al colloquio SQL.