Siamo onesti: preparare un colloquio SQL studiando a memoria liste infinite di domande e risposte è il modo migliore per fare scena muta alla prima vera domanda tecnica.

Dopo aver visto 20 query fondamentali nel nostro articolo precedente, è il momento di fare un salto di qualità. Quando un Senior Data Engineer o un Lead Analyst ti fa una domanda apparentemente banale come “Che cos’è un NULL?” o “Che differenza c’è tra TRUNCATE e DELETE?”, non sta valutando la tua grammatica SQL. Sta cercando di capire se hai mai fatto crashare un database in produzione, se sai come vengono gestiti i dati sul disco e se hai chiaro il concetto di transazione.

In questa prima parte delle 100 domande che possono cambiarti un colloquio, non ti darò i “compitini” da ripetere a pappagallo.

L’obiettivo non è superare il test, ma dimostrare che sei un professionista a cui si possono affidare i dati aziendali senza sudare freddo.

1. Fondamenti SQL: Oltre le definizioni

Le prime domande di un colloquio tecnico sembrano sempre innocue: cos’è SQL? Cos’è una tabella?
La verità? L’intervistatore non vuole la definizione da manuale. Vuole capire se sai come il motore del database ragiona dietro le quinte.

Cos’è SQL?

SQL (Structured Query Language) non è un linguaggio di programmazione procedurale dove spieghi come estrarre il dato riga per riga. È un linguaggio dichiarativo: gli descrivi cosa vuoi ottenere, e il Query Optimizer decide il piano di esecuzione più efficiente.
Al colloquio, dimostra di sapere che SQL non è solo SELECT. Si divide in macro-categorie fondamentali per l’amministrazione:

• DDL (Data Definition Language): definisce la struttura (CREATE, ALTER, DROP).
• DML (Data Manipulation Language): gestisce i dati (SELECT, INSERT, UPDATE, DELETE).
• DCL (Data Control Language): gestisce i permessi (GRANT, REVOKE).
• TCL (Transaction Control): gestisce la coerenza (COMMIT, ROLLBACK).

-- Esempio TCL: il pane quotidiano per non fare danni in produzione
BEGIN TRANSACTION;
UPDATE dipendenti SET nome = 'Alicia' WHERE id = 1;
COMMIT; -- Senza questo, i dati restano bloccati o non visibili agli altri

Cos’è una tabella e cos’è una chiave primaria?

Una tabella è l’incarnazione dell’algebra relazionale: una griglia bidimensionale dove ogni cella deve contenere un valore atomico. Ma la vera domanda trabocchetto verte quasi sempre sulla Primary Key (PK).

La chiave primaria garantisce unicità e non nullità. Ma la vera risposta che fa brillare gli occhi a un Senior è questa: in quasi tutti i motori relazionali (come InnoDB su MySQL o SQL Server), la PK crea automaticamente un indice cluster. Questo significa che i dati vengono scritti fisicamente sul disco ordinati secondo quella chiave, rendendo le ricerche per PK istantanee.

Il consiglio per il colloquio: Specifica sempre la differenza tra chiave naturale (es. Codice Fiscale, fragile perché può cambiare) e chiave surrogata (un intero auto-incrementante o un UUID, la scelta raccomandata nel 99% dei casi aziendali).

Qual è la differenza tra CHAR e VARCHAR?

Questa è la classica domanda che svela se hai davvero gestito volumi di dati o se hai solo fatto query su database giocattolo. La differenza sta nella gestione della memoria e nel padding.

Regola d’oro: Usa CHAR solo per campi a lunghezza fissa e corti (es. codici ISO come CHAR(2), sesso, flag). Usa VARCHAR per descrizioni o nomi.

CREATE TABLE test_stringhe (
    codice_stato CHAR(2) NOT NULL,      -- es. 'IT' (sempre 2)
    descrizione VARCHAR(255) NOT NULL   -- es. 'Italia' (6 + overhead)
);

INSERT INTO test_stringhe VALUES ('IT', 'Italia');

-- ATTENZIONE ALLA LUNGHEZZA AL COLLOQUIO
SELECT 
    codice_stato,
    CHAR_LENGTH(codice_stato) AS caratteri, -- Conta i caratteri
    LENGTH(codice_stato) AS byte_usati      -- Conta i byte fisici (in UTF-8 le accentate pesano di più!)
FROM test_stringhe;

Che cosa rappresenta NULL?

NULL non è un valore (non è 0, non è ”).

È un marcatore che indica un dato sconosciuto o mancante.

Ha un comportamento “contagioso”: qualsiasi operazione matematica con un NULL restituisce NULL.

Le trappole classiche nei colloqui:

• WHERE colonna = NULL non funziona mai. Due entità sconosciute non sono confrontabili. Si deve usare IS NULL.
• Le funzioni aggregate (SUM, AVG, COUNT(colonna)) ignorano i NULL.

CREATE TABLE ordini (
    ordine_id INT PRIMARY KEY,
    data_spedizione DATE NULL         -- NULL = non spedito
);

INSERT INTO ordini VALUES (1, '2026-07-10'), (2, NULL);

-- ERRORE CLASSICO
SELECT * FROM ordini WHERE data_spedizione = NULL;  -- Restituisce 0 righe!  -- CORRETTO
SELECT * FROM ordini WHERE data_spedizione IS NULL; 

-- Funzioni aggregate
SELECT 
    COUNT(*) AS totale_righe,          -- 2
    COUNT(data_spedizione) AS spediti, -- 1 
    AVG(EXTRACT(DAY FROM data_spedizione)) -- Calcola solo sull'ordine 1!
FROM ordini;

-- Gestione corretta
SELECT COALESCE(data_spedizione, CURRENT_DATE) FROM ordini;

Qual è la differenza tra DELETE, TRUNCATE e DROP?

Questo è il discriminator definitivo tra un “utente di query” e un vero Data Engineer. Per rispondere bene, chiudiamo l’editor SQL e guardiamo come il motore gestisce lo spazio su disco.

Cosa succede nel dettaglio?

DELETE (Rimozione riga per riga):

Legge ogni riga, scrive nel Transaction Log l’immagine “prima” e “dopo” per poter fare un eventuale rollback. I trigger vengono eseguiti.

L’impatto? Su milioni di righe, blocca il server, riempie il disco e crea frammentazione (lascia “buchi” fisici).

TRUNCATE (Rimozione a livello di pagina):

Non legge le righe. Dealloca interi extent (gruppi di pagine fisiche) dedicati alla tabella e resetta i contatori di auto-incremento. È come strappare un capitolo intero da un libro invece di cancellarlo lettera per lettera con la gomma. È fulmineo.

DROP (Rimozione strutturale):

Cancella i metadati dal dizionario del DB, dealloca le pagine fisiche ed elimina gli indici.

Vediamo lo script di simulazione che scriverei  durante il colloquio:

-- Preparazione ambiente
CREATE TABLE test_log (
    id INT AUTO_INCREMENT PRIMARY KEY,
    valore INT NOT NULL
);

-- Caso 1: DELETE in transazione 
START TRANSACTION;
    DELETE FROM test_log WHERE valore < 500;  -- Operazione loggata riga per riga
ROLLBACK;  -- Il log di undo riscrive tutto perfettamente.

-- Caso 2: TRUNCATE in transazione 
START TRANSACTION;
    TRUNCATE TABLE test_log;  
ROLLBACK;  
-- ATTENZIONE AL COLLOQUIO: 
-- In PostgreSQL: La tabella riappare con i dati. TRUNCATE è transazionale (MVCC-safe).
-- In MySQL/Oracle: Il TRUNCATE esegue un COMMIT IMPLICITO. Chiude la transazione corrente senza preavviso. Il Rollback fallisce e i dati sono persi per sempre!

-- APPROCCIO SBAGLIATO (Cade il 50% dei candidati Junior)
SELECT AVG(commissione_bonus) AS media_errata FROM venditori; 
-- Risultato: 1250 (Calcola solo (1000+1500) / 2)

-- APPROCCIO CORRETTO
SELECT AVG(COALESCE(commissione_bonus, 0)) AS media_reale FROM venditori;
-- Risultato: 625 (Calcola (1000+1500+0+0) / 4)

SELECT id_cliente, nome 
FROM clienti 
WHERE id_cliente NOT IN (SELECT id_cliente_fk FROM ordini);

-- RISCRITTURA SICURA 1: Uso di NOT EXISTS (Ottima performance)
SELECT c.id_cliente, c.nome 
FROM clienti c
WHERE NOT EXISTS (
    SELECT 1 FROM ordini o WHERE o.id_cliente_fk = c.id_cliente
);

-- RISCRITTURA SICURA 2: Uso del LEFT JOIN (Anti-Join pattern)
SELECT c.id_cliente, c.nome 
FROM clienti c
LEFT JOIN ordini o ON c.id_cliente = o.id_cliente_fk
WHERE o.id_cliente_fk IS NULL;

-- 1. Pulizia dei dati (Rimuove gli spazi iniziali e finali)
UPDATE utenti_tmp 
SET codice_nazione = TRIM(codice_nazione);

-- 2. Ottimizzazione della struttura (DDL)
-- Essendo codici nazione standard (es. IT, FR, US), la lunghezza fissa è a 2.
ALTER TABLE utenti_tmp 
MODIFY codice_nazione CHAR(2) NOT NULL; 
-- (Nota: la sintassi esatta di ALTER TABLE varia leggermente tra MySQL, PostgreSQL e SQL Server)

-- Comando corretto
TRUNCATE TABLE log_eventi_staging;

-- Comando da EVITARE in questo scenario:
-- DELETE FROM log_eventi_staging;

-- Soluzione con Self-Join (Molto efficiente, sintassi tipica MySQL)
DELETE t1 
FROM newsletter t1
JOIN newsletter t2 
  ON t1.email = t2.email 
  AND t1.id > t2.id;

-- Alternativa standard ANSI (Usando una CTE o Subquery)
DELETE FROM newsletter 
WHERE id NOT IN (
    SELECT MIN(id) 
    FROM newsletter 
    GROUP BY email
);

-- DDL Proposto dal candidato
CREATE TABLE clickstream (
    id BIGINT AUTO_INCREMENT PRIMARY KEY, -- Rifiuto l'UUID
    user_id INT NOT NULL,
    timestamp_click TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    url_visitata VARCHAR(500)
);

Il percorso continua

Questo articolo è solo la punta dell’iceberg. Nel prossimo articolo spiegheremo la differenza tra una GROUP BY e una Window Function con esercizi reali.

Gli strumenti di AI oggi generano query SQL in pochi secondi, ma è il professionista umano che deve comprendere il modello fisico dei dati, anticipare le criticità di sistema e scegliere l’approccio che non faccia cadere il database di produzione.

Ecco perché l’SQL, inteso come architettura e non solo come sintassi, rimarrà centrale per molto tempo.

Colloqui tecnici,  Data Science, Data Engineering e AI

👉Checklist tecnico per Data Scientist: la guida completa al colloquio entry level

👉Colloquio Databricks e PySpark: domande reali e risposte per superarlo

👉Perché i conti non quadrano: cinque casi reali per brillare ai colloqui

👉Quadratura dei dati e Mass Balance: controlli di integrità con SQL e Python

👉Come diventare Junior AI Engineer: cosa chiedono davvero le aziende

👉Leggere tra le righe di un annuncio da Data Engineer