Domande di Intervista per Ingegnere dei Dati: SQL, Pipeline e Affidabilità Sotto Pressione

Il ciclo di intervista di questo ruolo è costruito intorno a una preoccupazione centrale: puoi spostare e trasformare i dati correttamente su larga scala senza che nessuno debba stare a bada. Questo si manifesta come quattro aree di competenza collegate: SQL e modellazione dei dati, progettazione di pipeline tra pattern ETL e ELT, affidabilità in caso di guasto e il giudizio di comunicare compromessi a persone che non scrivono codice.

La maggior parte dei cicli mescola un turno SQL pratico, un turno di progettazione del sistema focalizzato su una pipeline o piattaforma di dati, e un turno comportamentale che esamina come gestisci dati corrotti, requisiti mancanti e disaccordi con data scientist o analisti. Alcune aziende eseguono anche un esercizio da portare a casa dove costruisci una piccola pipeline da un dataset grezzo, il quale testa le stesse competenze senza un pubblico dal vivo.

Gli intervistatori non stanno solo valutando se la tua query restituisce le righe giuste. Stanno ascoltando come racconti il tuo ragionamento: perché hai scelto una window function invece di un self-join, perché hai scelto un carico incrementale invece di un refresh completo, perché avviseresti su uno scostamento del conteggio delle righe invece di solo conteggi null. Un candidato che borbotta attraverso una risposta corretta spesso perde rispetto a chi spiega una risposta leggermente più approssimativa chiaramente.

Prima del tuo colloquio, crea una breve lista di pipeline, tabelle o incidenti dal tuo lavoro che puoi descrivere in due o tre frasi ciascuno. Li userai costantemente nei turni SQL, progettazione e comportamentali.

SQL è ancora il gate più comune negli intervisti degli ingegneri dei dati, anche presso aziende che funzionano principalmente su Spark o dbt. Aspettati prompt come: scrivi una query che restituisce l'ordine più recente di ciascun cliente, trova gap in una sequenza di date per account, calcola un totale mobile di sette giorni delle entrate giornaliere, o deduplicare righe senza perdere la versione più recente.

Le window function emergono costantemente. ROW_NUMBER() con una clausola PARTITION BY è lo strumento standard per problemi "record più recente per chiave"; LAG() e LEAD() gestiscono domande di gap-and-island e rilevamento dei cambiamenti; SUM() OVER una finestra ordinata gestisce i totali mobili senza un self-join. Gli intervistatori vogliono anche che ragioni ad alta voce di un piano di query: quale ordine di join l'ottimizzatore potrebbe scegliere, dove un indice aiuterebbe, e quando una query è lenta a causa di un filtro di partizione mancante piuttosto che un join cattivo.

Le domande di modellazione dei dati testano un muscolo diverso: progettazione di schema sotto vincoli conflittuali. Un prompt comune è progettare uno schema a stella per un dataset di e-commerce o abbonamento, con tabelle di fatti per ordini o eventi e tabelle di dimensioni per clienti, prodotti e tempo. Sii pronto a spiegare lentamente dimensioni che cambiano: quando un aggiornamento di Tipo 1 (sovrascrivi) va bene rispetto a quando hai bisogno di Tipo 2 (nuova riga, date di efficacia) per preservare la cronologia per una metrica come "segmento cliente al momento dell'acquisto".

Dovresti anche essere in grado di giustificare i compromessi di normalizzazione. I sistemi OLTP favoriscono tabelle normalizzate per proteggere la coerenza di scrittura; i warehouse di analitici spesso denormalizzano intenzionalmente in modo che uno strumento BI possa interrogare una singola tabella ampia invece di cinque join. Nominare quel compromesso, piuttosto che trattare uno stile come universalmente corretto, è quello che separa una risposta forte da una da libro di testo.

Le domande di progettazione di pipeline ti chiedono di abbozzare come i dati grezzi diventano una tabella affidabile. Un prompt tipico: progetta una pipeline che acquisisce eventi clickstream e produce una tabella di utenti attivi giornalieri che il team di prodotto può interrogare ogni mattina. Una risposta forte inizia con la fonte, non gli strumenti: da dove originano i dati, con quale frequenza arrivano, quale è la latenza accettabile, e cosa succede se un batch è in ritardo o uno stream si interrompe.

Aspettati di confrontare esplicitamente ETL e ELT. In ETL, trasformi i dati prima di caricarli nel warehouse, il che si adatta a volumi minori o rigorosi requisiti di conformità. In ELT, carichi prima i dati grezzi e li trasformi dentro il warehouse con uno strumento come dbt, che è ormai il pattern più comune perché il calcolo warehouse è economico e preserva la cronologia grezza per la rielaborazione. Sii in grado di spiegare perché sceglieresti uno rispetto all'altro per una data fonte di dati.

Le domande di orchestrazione testano se pensi al fallimento, non solo al percorso felice. Gli intervistatori vogliono ascoltare di DAG in uno strumento come Airflow o Dagster, retry a livello di task, backfill per uno schema che è cambiato a metà cronologia, e carichi incrementali che elaborano solo righe nuove o modificate invece di rielaborare un'intera tabella ad ogni esecuzione. L'idempotenza è un follow-up preferito: se un task fallisce a metà strada e viene rieseguito, produce righe duplicate o lo stesso risultato corretto?

Le domande specifiche di streaming emergono più presso aziende con requisiti real-time. Ti potrebbe essere chiesto di confrontare una pipeline di streaming basata su Kafka contro un approccio micro-batch, o di spiegare esattamente una volta rispetto alla semantica di consegna almeno-una-volta e quale strategia di deduplicazione useresti downstream quando un sistema garantisce solo almeno-una-volta.

Le domande di affidabilità per gli ingegneri dei dati di solito iniziano con uno scenario: un dashboard mostra zero ricavi questa mattina, cammina attraverso come lo debuggeresti. Una buona risposta lavora all'indietro attraverso la pipeline in ordine piuttosto che indovinare a caso. Controlla se il sistema di origine ha effettivamente prodotto dati, controlla i log del job di ingestione e i conteggi delle righe, controlla il livello di trasformazione per un'esecuzione fallita o saltata silenziosamente, e controlla se il dashboard stesso punta a una tabella stale o cache.

I controlli di qualità dei dati sono un argomento frequente di per sé. Gli intervistatori vogliono specifici: controlli di tasso null su campi obbligatori, rilevamento di anomalie di conteggio righe rispetto a una baseline storica, controlli di freschezza che avvertono quando una tabella non è stata aggiornata entro la sua finestra prevista, e controlli referenziali che catturano chiavi esterne orfane dopo un cambio di schema a monte. Strumenti come test dbt o Great Expectations emergono spesso, ma nominare uno strumento importa meno che spiegare cosa controlleresti effettivamente e perché quel controllo cattura la modalità di fallimento di cui ti importa.

Dovresti anche aspettarti domande su SLA e SLO per la freschezza dei dati, e come progetteresti gli avvisi in modo che la persona giusta sia contattata per un problema reale senza sommergere il team in rumore da varianze previste. Parla di come imposteresti soglie, instradaresti avvisi per gravità ed eviti un avviso che si attiva ogni giorno e viene ignorato.

Un tema comportamentale correlato è la postmortem: descrivi un incidente in cui dati non validi hanno raggiunto un report o un modello prima che qualcuno lo catturasse. Gli intervistatori ascoltano proprietà e cambiamento di processo, non colpa. Una risposta forte nomina la causa principale, la correzione immediata e la protezione specifica che hai aggiunto dopo, come un nuovo controllo di convalida o una modifica al modo in cui i backfill sono revisionati.

Le domande comportamentali per gli ingegneri dei dati si concentrano meno su eroismo individuale e più su come gestisci richieste contrastanti da persone che dipendono dalle tue pipeline. I prompt comuni includono: raccontami di un momento in cui uno stakeholder aveva bisogno di dati più velocemente di quanto la tua pipeline potesse consegnare; raccontami di un disaccordo con uno data scientist o analista su uno schema o una definizione di metrica; raccontami di un momento in cui hai trovato un errore nei dati di produzione dopo che era già stato utilizzato in un report.

Usa STAR, ma mantieni la sezione azione specifica per il lavoro sui dati. Per la storia "dati già utilizzati in un report cattivo", spiega come hai scoperto l'errore, chi hai detto e quanto velocemente, come hai corretto i numeri downstream e quale convalida hai aggiunto in modo che la stessa classe di errore non potesse passare inosservata di nuovo. Gli intervistatori vogliono vedere che tratti gli incidenti di dati come un ingegnere software tratta un'interruzione di produzione, non come un fastidio minore.

Per disaccordi su schema o metrica, mostra che puoi tenere una posizione tecnica mentre raggiungi comunque una decisione con cui il team può convivere. Spiega il compromesso che stavi difendendo, come le prestazioni delle query rispetto al costo di archiviazione, o uno schema più rigoroso rispetto a un'integrazione più veloce di una nuova fonte di dati, e come lo hai risolto senza semplicemente ignorare l'altra persona.

Le domande di prioritizzazione sono anche comuni: come decidi tra correggere una pipeline instabile, costruire una nuova fonte di dati che uno stakeholder sta aspettando e ripagare il debito tecnico in un vecchio modello. Una risposta credibile pesa l'impatto aziendale, il blast radius se la pipeline instabile fallisce di nuovo, e per quanto tempo il team può tollerare il debito prima che rallenti ogni cambiamento futuro.

Queste domande sono più facili da rispondere su carta che ad alta voce. Spiegare una window function, una progettazione di pipeline, o una postmortem di incidente in frasi parlate chiare è un'abilità diversa dallo scrivere l'SQL corretto o disegnare il DAG giusto, e gli intervistatori valutano la spiegazione tanto quanto la risposta.

Pratica a narrare soluzioni SQL prima di toccare una tastiera: dichiara l'approccio, nomina la window function o la strategia di join che utilizzerai, quindi scrivi la query. Per i prompt di progettazione della pipeline, pratica a parlare attraverso sorgente, requisiti di latenza, logica di trasformazione e gestione del fallimento in quell'ordine ogni volta, così la struttura diventa automatica sotto pressione. Per le storie comportamentali, esercitati finché il dettaglio tecnico rimane specifico senza trasformarsi in un monologo.

Registra te stesso rispondendo a poche di queste domande e ascolta per parole di riempimento, setup prolissi prima di arrivare al punto, o passaggi saltati in una spiegazione della pipeline. SayNow AI può aiutarti a praticare le domande di intervista per ingegnere dei dati ad alta voce, con feedback su chiarezza e ritmo in modo che il tuo ragionamento tecnico emerga con la fiducia che legge sulla pagina.