Le 25 domande piu frequenti nei colloqui di Data Engineering nel 2026

Le domande nei colloqui di data engineering nel 2026 vanno ben oltre le basi di SQL. I team di selezione esplorano oggi il system design, le architetture in tempo reale, l'ottimizzazione dei costi e la preparazione all'intelligenza artificiale. Questa guida copre le 25 domande che compaiono con maggiore frequenza nei colloqui per data engineer, dalle startup alle aziende FAANG, con risposte pensate per chi lavora sul campo.

SQL e ottimizzazione delle query

SQL resta il fondamento di ogni colloquio di data engineering. Anche i candidati senior affrontano domande SQL, in genere incentrate sulle prestazioni piuttosto che sulla sintassi.

1. Qual e la differenza tra una window function e GROUP BY?

GROUP BY riduce le righe in risultati aggregati, diminuendo il numero totale di righe. Le window function calcolano valori su un insieme di righe correlate alla riga corrente senza ridurle. L'output conserva ogni riga originale.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

La versione con window function e essenziale quando la query necessita contemporaneamente del dettaglio a livello di riga e del contesto aggregato, un requisito comune nei controlli di qualita dei dati e nelle pipeline di reporting.

2. Come si ottimizza una query lenta su una tabella fact da 500 milioni di righe?

Un approccio strutturato funziona meglio:

1. Controllare il piano di esecuzione (EXPLAIN ANALYZE) per identificare scansioni complete della tabella, hash join su colonne non indicizzate o riversamenti su disco.
2. Partizionare la tabella per data o un'altra colonna ad alta cardinalita che corrisponda ai filtri delle query.
3. Aggiungere indici mirati sulle colonne filtrate frequentemente, evitando l'eccesso di indicizzazione (ogni indice aggiunge overhead in scrittura).
4. Materializzare i risultati intermedi se la stessa subquery viene eseguita ripetutamente su piu dashboard.
5. Applicare i predicati il prima possibile per filtrare presto e ridurre i dati trasferiti tra le fasi.

Il segnale chiave che i selezionatori cercano: la comprensione che l'ottimizzazione e iterativa e dipende dal contesto, non una semplice checklist.

3. CTE vs subquery vs tabelle temporanee: quando si usa ciascuno?

Le CTE (Common Table Expression) migliorano la leggibilita e permettono query ricorsive. La maggior parte dei motori di query le esegue inline, quindi le prestazioni corrispondono a quelle delle subquery. Le tabelle temporanee materializzano fisicamente i dati, il che risulta utile quando lo stesso risultato intermedio alimenta piu query a valle nella stessa sessione. Le subquery funzionano bene per trasformazioni semplici e occasionali.

Regola pratica: CTE per la chiarezza, tabella temporanea per il riutilizzo, subquery per filtri inline banali.

Per un approfondimento sui pattern SQL avanzati, consultare SQL per Data Analyst: Window Functions, CTE e query avanzate.

ETL vs ELT e architettura delle data pipeline

Le domande sulla progettazione delle pipeline testano il pensiero architetturale. I selezionatori vogliono vedere un'analisi dei compromessi, non la promozione di uno strumento specifico.

4. ETL vs ELT: quando scegliere uno o l'altro?

| Criterio | ETL | ELT | |----------|-----|-----| | Luogo della trasformazione | Prima del caricamento (compute esterno) | Dopo il caricamento (compute del warehouse) | | Ideale per | Sistemi legacy, schemi rigidi | Cloud warehouse (BigQuery, Snowflake) | | Flessibilita dello schema | Bassa (la trasformazione blocca lo schema presto) | Alta (dati grezzi disponibili per ri-trasformazione) | | Modello di costo | Compute esterno al warehouse | I costi di compute del warehouse scalano con le trasformazioni | | Freschezza dei dati | Latenza maggiore (fase di trasformazione) | Latenza minore (caricamento prima, trasformazione on demand) |

ELT domina negli stack cloud-native moderni perche lo storage e economico, il compute scala elasticamente e conservare i dati grezzi abilita l'evoluzione dello schema. ETL resta rilevante quando requisiti normativi impongono la trasformazione dei dati prima dell'ingresso nel warehouse (ad esempio la rimozione di PII).

5. Come si progetta una data pipeline idempotente? Perche l'idempotenza e importante?

L'idempotenza garantisce che l'esecuzione ripetuta di una pipeline con lo stesso input produca lo stesso risultato senza duplicare i dati. Questo e fondamentale perche le pipeline falliscono e vengono rieseguite.

Strategie di implementazione:

• Pattern upsert (MERGE o INSERT ... ON CONFLICT) con chiave naturale o composita
• Sovrascrittura della partizione: sostituire intere partizioni per data invece di aggiungere in append
• Deduplicazione in scrittura: assegnare ID deterministici (hash della chiave business + timestamp dell'evento)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Questo approccio garantisce che una riesecuzione del job dell'11 aprile sovrascriva la partizione dell'11 aprile anziche aggiungere righe duplicate.

6. Cos'e la data lineage e perche e fondamentale nelle pipeline di produzione?

La data lineage traccia l'origine, il movimento e la trasformazione dei dati lungo tutta la pipeline. Risponde alle domande: da dove proviene questo numero, quali trasformazioni sono state applicate e quali sistemi a valle dipendono da esso.

Valore pratico: quando una dashboard mostra valori inattesi, la lineage permette l'analisi delle cause in pochi minuti anziche in ore. Strumenti come OpenLineage, dbt docs e le funzionalita native di lineage cloud (ad esempio la lineage a livello di colonna di BigQuery) automatizzano questo processo.

Streaming ed elaborazione dati in tempo reale

Le domande sullo streaming si sono evolute da "cos'e Kafka" a decisioni architetturali su quando e come utilizzare lo streaming.

7. Batch vs streaming: come si decide quale approccio adottare?

La decisione dipende dai requisiti di latenza, non dalla preferenza tecnologica:

• Batch: accettabile quando i consumatori di dati tollerano un ritardo da minuti a ore. Piu semplice da costruire, testare e debuggare. Costo operativo inferiore per la maggior parte dei carichi di lavoro.
• Streaming: necessario quando la logica di business dipende da una freschezza inferiore al minuto: rilevamento frodi, pricing in tempo reale, dashboard live.
• Micro-batch: un compromesso pragmatico (Spark Structured Streaming, ad esempio) che fornisce latenza quasi in tempo reale con la semplicita del batch.

La risposta piu solida riconosce che la maggior parte delle pipeline dovrebbe iniziare in batch e passare allo streaming solo quando un SLA di latenza concreto lo richiede.

8. Architettura di Kafka: topic, partizioni, consumer group

Kafka organizza i dati in topic (canali logici). Ogni topic si suddivide in partizioni (log ordinati e immutabili) distribuiti tra i broker. I producer scrivono record nelle partizioni (round-robin o basato su chiave). I consumer group parallelizzano le letture: ogni partizione viene assegnata a esattamente un consumer all'interno del gruppo, abilitando lo scaling orizzontale.

Compromesso chiave: piu partizioni aumentano il parallelismo ma aggiungono overhead al broker (file handle, replicazione). Un punto di partenza tipico e 6-12 partizioni per topic, con scaling basato sui requisiti di throughput.

9. Come si gestiscono i dati in ritardo in una pipeline di streaming?

I dati in ritardo sono inevitabili nei sistemi distribuiti. Tre approcci:

1. Watermark: definire una soglia (ad esempio 10 minuti) oltre la quale i dati in ritardo vengono scartati. Apache Flink e Spark Structured Streaming supportano questa funzionalita nativamente.
2. Finestre di rielaborazione: rieseguire periodicamente le aggregazioni per le finestre temporali recenti per catturare i ritardatari.
3. Sink delta/upsert: scrivere su uno store mutabile (Delta Lake, Apache Iceberg) che supporta gli aggiornamenti, permettendo ai record in ritardo di correggere i risultati precedenti.

L'approccio corretto dipende dal fatto che i consumatori a valle necessitino di semantica exactly-once o possano tollerare la consistenza eventuale.

Data modeling e progettazione degli schemi

Le domande sul data modeling rivelano se un candidato ragiona su come i dati verranno consumati, non solo su come vengono archiviati.

10. Star schema vs snowflake schema: quali compromessi?

Lo star schema denormalizza le tabelle dimensionali in tabelle piatte e ampie collegate a una tabella fact centrale. Lo snowflake schema normalizza le dimensioni in sotto-dimensioni.

| Aspetto | Star | Snowflake | |---------|------|-----------| | Prestazioni query | Piu veloci (meno join) | Piu lente (piu join) | | Storage | Maggiore (dati ridondanti) | Minore (normalizzato) | | Complessita | Semplice da comprendere | Relazioni piu complesse | | Manutenzione | Piu difficile aggiornare le dimensioni | Piu facile aggiornare le sotto-dimensioni | | Ideale per | BI/reporting (lettura intensiva) | Situazioni che richiedono normalizzazione rigorosa |

In pratica, gli star schema dominano nei warehouse analitici (BigQuery, Snowflake, Redshift) perche le prestazioni delle query e la semplicita superano i risparmi di storage. Per approfondire, consultare il modulo interview data modeling.

11. Cos'e una slowly changing dimension (SCD)? Spiegare il Tipo 1, 2 e 3.

Le SCD tracciano come gli attributi dimensionali cambiano nel tempo:

• Tipo 1: Sovrascrivere il vecchio valore. Nessuno storico. Semplice ma con perdita di dati.
• Tipo 2: Aggiungere una nuova riga con tracciamento delle versioni (valid_from, valid_to, is_current). Storico completo preservato. Il piu comune nei warehouse di produzione.
• Tipo 3: Aggiungere una colonna per il valore precedente (current_city, previous_city). Storico limitato (solo una modifica tracciata).

Il Tipo 2 e la scelta predefinita per la maggior parte delle dimensioni aziendali (indirizzo cliente, categoria prodotto, dipartimento dipendente) perche le tracce di audit e il reporting storico lo richiedono.

12. Come si modellano i dati evento per analisi in tempo reale e archiviazione a lungo termine?

Un approccio a doppio livello:

1. Livello hot: trasmettere gli eventi in uno store in tempo reale (Apache Druid, ClickHouse o viste materializzate nel warehouse) ottimizzato per aggregazioni a bassa latenza sui dati recenti.
2. Livello cold: archiviare gli eventi grezzi in un lakehouse (Delta Lake, Iceberg) partizionato per data, conservato indefinitamente per analisi ad hoc e feature engineering per ML.

Il livello hot utilizza schemi pre-aggregati o denormalizzati per la velocita. Il livello cold conserva la granularita completa. Un job di riconciliazione verifica periodicamente che entrambi i livelli siano allineati.

Apache Spark ed elaborazione distribuita

Le domande su Spark si concentrano sulla comprensione del parallelismo e delle prestazioni, non solo sulle chiamate API.

13. Cosa causa il data skew in Spark e come si risolve?

Il data skew si verifica quando una partizione contiene una quantita di dati sproporzionatamente maggiore rispetto alle altre, causando il rallentamento di un singolo task che diventa il collo di bottiglia dell'intero stage.

Cause comuni: join su una chiave con pochi valori dominanti (chiavi null, un singolo ID prodotto molto popolare) o partizionamento su una colonna a bassa cardinalita.

Soluzioni:

• Salting: aggiungere un suffisso casuale alla chiave sbilanciata, eseguire il join sulla chiave salata, quindi aggregare per rimuovere il sale.
• Broadcast join: se uno dei lati e sufficientemente piccolo (tipicamente <200MB), effettuarne il broadcast per evitare completamente lo shuffle.
• AQE (Adaptive Query Execution): Spark 3.x+ puo rilevare automaticamente e suddividere le partizioni sbilanciate a runtime.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Questo distribuisce il carico di lavoro uniformemente tra gli executor, eliminando il collo di bottiglia.

14. Qual e la differenza tra trasformazioni e azioni in Spark?

Le trasformazioni (map, filter, select, join) sono lazy: costruiscono un piano logico ma non eseguono nulla. Le azioni (count, collect, write) attivano il calcolo effettivo inviando il piano al cluster.

Questa valutazione lazy permette all'ottimizzatore Catalyst di Spark di riordinare le operazioni, applicare i predicati anticipatamente ed eliminare shuffle non necessari prima che qualsiasi dato venga spostato. Comprendere questa distinzione e essenziale per il debugging: una trasformazione che sembra lenta in realta non ha problemi; il collo di bottiglia e nell'azione che la attiva.

15. Qual e la differenza tra repartition() e coalesce()?

repartition(n) esegue uno shuffle completo per creare esattamente n partizioni, distribuendo i dati uniformemente. Si utilizza per aumentare il parallelismo o riequilibrare partizioni sbilanciate.

coalesce(n) riduce le partizioni senza shuffle unendo partizioni adiacenti. Si utilizza per diminuire il numero di partizioni prima della scrittura (evitando molti file piccoli).

Regola: coalesce per ridurre, repartition per aumentare o riequilibrare.

Orchestrazione e gestione delle pipeline

Le domande sull'orchestrazione testano la maturita operativa: come le pipeline vengono eseguite, falliscono e recuperano in produzione.

16. Confronto tra Airflow, Dagster e Prefect: quando scegliere ciascuno?

| Caratteristica | Airflow | Dagster | Prefect | |----------------|---------|---------|---------| | Maturita | Il piu maturo, community piu ampia | In crescita, forte nei team ML/dati | Cloud-first, ottima developer experience | | Astrazione principale | DAG di task | Asset (orientato ai dati) | Flow e task | | Testing | Piu difficile (a livello di DAG) | Testing degli asset integrato | Buon testing a livello di task | | Sviluppo locale | Richiede Docker/container | Esecuzione locale nativa | Esecuzione locale nativa | | Ideale per | ETL complessi e di lunga durata | Team data mesh / orientati agli asset | Team che vogliono orchestrazione con meno infrastruttura |

Airflow resta lo standard del settore per le piattaforme dati mature. Dagster si adatta ai team che ragionano in termini di asset di dati piuttosto che sequenze di task. Prefect attrae i team che desiderano un'orchestrazione simile ad Airflow con meno overhead operativo. Per la preparazione specifica su Airflow, consultare il modulo fondamenti di Airflow.

17. Come si gestiscono i fallimenti delle pipeline e gli alert in produzione?

Una strategia di gestione dei fallimenti production-grade include:

1. Retry con backoff: i fallimenti transitori (timeout di rete, rate limit delle API) si risolvono con retry esponenziale.
2. Dead-letter queue: i messaggi problematici vengono instradati verso una coda separata per l'ispezione manuale senza bloccare la pipeline.
3. Circuit breaker: dopo N fallimenti consecutivi, la pipeline si mette in pausa e genera un alert anziche inondare i sistemi a valle con dati errati.
4. Osservabilita: log strutturati, metriche (durata dei task, conteggio righe, tassi di errore) e controlli di qualita dei dati (Great Expectations, dbt test) a ogni fase della pipeline.
5. Livelli di alerting: P1 (pipeline down, dati mancanti) chiama il reperibile. P2 (drift nella qualita dei dati) invia una notifica Slack per il giorno lavorativo successivo.

18. Cosa rende una pipeline "pronta per la produzione" rispetto a un prototipo?

La prontezza per la produzione significa: esecuzioni idempotenti, retry automatizzati, monitoraggio e alerting, validazione dei dati nelle fasi di ingestione e trasformazione, documentazione dei data contract, definizioni delle pipeline sotto controllo di versione e un percorso di rollback testato. Un prototipo non ha nessuna di queste caratteristiche. Il divario tra i due e il punto in cui si accumula la maggior parte del debito tecnico delle pipeline.

Piattaforme dati cloud e architettura lakehouse

Le domande sulle piattaforme cloud valutano se i candidati comprendono i compromessi tra costo, scala e architettura oltre la sintassi specifica del vendor.

19. Cos'e un lakehouse e perche e diventata l'architettura dominante?

Un lakehouse combina la flessibilita di un data lake (schema-on-read, archiviazione di dati grezzi, formati di file multipli) con l'affidabilita di un data warehouse (transazioni ACID, enforcement dello schema, ottimizzazione delle query). Tecnologie come Delta Lake, Apache Iceberg e Apache Hudi abilitano questo approccio aggiungendo un livello di metadati e transazioni sopra lo storage a oggetti (S3, GCS, ADLS).

Il lakehouse si impone perche elimina il costoso livello ETL tra lake e warehouse, supporta sia query BI che workload ML sugli stessi dati e sfrutta lo storage a oggetti a basso costo.

20. Come si ottimizzano i costi del cloud warehouse (BigQuery, Snowflake, Redshift)?

Strategie di ottimizzazione dei costi:

• Partizionare e clusterizzare le tabelle per ridurre i byte scansionati per query
• Dimensionare correttamente i warehouse (Snowflake) o le slot reservation (BigQuery) in base ai pattern di carico
• Auto-sospendere le risorse inattive: i warehouse Snowflake dovrebbero auto-sospendersi dopo 1-5 minuti di inattivita
• Monitorare i costi per query: la vista INFORMATION_SCHEMA.JOBS di BigQuery rivela le query costose
• Utilizzare viste materializzate per aggregazioni calcolate ripetutamente
• Archiviare i dati freddi verso tier di storage piu economici con policy di lifecycle

Il segnale nel colloquio: candidati che considerano il costo come un vincolo ingegneristico di primo livello, non un ripensamento.

Qualita dei dati e governance

Le domande sulla qualita dei dati distinguono gli ingegneri che rilasciano pipeline da quelli che mantengono piattaforme dati affidabili.

21. Come si implementano i controlli di qualita dei dati in una pipeline?

I controlli di qualita dei dati appartengono a tre fasi:

1. Ingestione: validare la conformita dello schema, verificare le chiavi primarie null, controllare le soglie di conteggio righe rispetto alla sorgente.
2. Trasformazione: asserire regole di business (ad esempio fatturato > 0, date in range valido), verificare l'integrita referenziale tra le tabelle.
3. Servizio: monitorare il drift delle metriche (un calo improvviso del 50% degli utenti attivi giornalieri indica probabilmente un problema della pipeline, non un cambiamento di business).

Strumenti: dbt test (schema e custom), Great Expectations, Soda Core, Monte Carlo (osservabilita dei dati). L'approccio migliore integra i controlli direttamente nel DAG della pipeline in modo che i fallimenti blocchino l'elaborazione a valle.

22. Cos'e un data contract e come previene la rottura delle pipeline?

Un data contract e un accordo formale tra un produttore di dati e i suoi consumatori che specifica: schema (nomi delle colonne, tipi, nullabilita), SLA di freschezza (dati disponibili entro le 6:00 UTC), aspettative di volume (tra 1 milione e 10 milioni di righe giornaliere) e regole semantiche (il campo status contiene solo ACTIVE, INACTIVE, SUSPENDED).

Quando i produttori modificano il loro schema senza aggiornare il contratto, la validazione automatica rileva la discrepanza prima che si propaghi a valle. Questo trasforma i fallimenti delle pipeline da corruzione silenziosa dei dati in errori espliciti e risolvibili.

System design e architettura

I round di system design sono standard per i ruoli di data engineering di livello medio-senior. Questi testano il pensiero end-to-end.

23. Progettare una pipeline di analisi in tempo reale per una piattaforma e-commerce.

Un design solido affronta:

Ingestione: gli eventi clickstream e gli eventi transazionali confluiscono in topic Kafka, partizionati per user_id per garantire l'ordinamento all'interno della sessione utente.

Elaborazione: un job Flink o Spark Structured Streaming consuma da Kafka, arricchisce gli eventi con i dati del catalogo prodotti (broadcast join da una tabella dimensionale), calcola aggregazioni a livello di sessione e a intervalli di 5 minuti.

Servizio: le metriche aggregate atterrano in uno store OLAP in tempo reale (ClickHouse o Apache Druid) per query della dashboard con latenza sub-secondo. Gli eventi grezzi atterrano in Delta Lake/Iceberg per l'analisi storica.

Qualita dei dati: uno schema registry (Confluent o AWS Glue) valida gli schemi degli eventi all'ingestione. Controlli di qualita dei dati in streaming segnalano anomalie (calo improvviso del volume degli eventi) e instradano verso un dead-letter topic.

Gestione dei fallimenti: gli offset dei consumer di Kafka abilitano l'elaborazione exactly-once con checkpointing. Il job di streaming si riavvia automaticamente dall'ultimo checkpoint in caso di fallimento.

24. Come si migra una pipeline ETL legacy verso uno stack moderno?

La migrazione segue un pattern strangler fig:

1. Audit: catalogare tutte le pipeline esistenti, le loro sorgenti, trasformazioni e consumatori. Identificare dipendenze e SLA.
2. Esecuzione parallela: costruire la nuova pipeline accanto a quella vecchia. Entrambe consumano le stesse sorgenti e scrivono su target separati.
3. Validazione: confrontare gli output tra le pipeline vecchia e nuova. Query di riconciliazione automatizzate segnalano le discrepanze.
4. Cutover: una volta che gli output corrispondono entro la tolleranza per piu di 2 settimane, spostare i consumatori sul nuovo target. Mantenere la vecchia pipeline in modalita sola lettura per il rollback.
5. Dismissione: dopo un periodo di stabilita, spegnere la pipeline legacy.

L'intuizione chiave: non eseguire mai una migrazione big-bang. Eseguire entrambi i sistemi in parallelo fino a quando la fiducia non e consolidata.

25. Una dashboard critica mostra numeri errati. Descrivere il processo di debugging.

Un approccio sistematico:

1. Definire il perimetro del problema: quali metriche sono errate? Da quando? Tutte le dimensioni o filtri specifici?
2. Controllare il livello di servizio: interrogare direttamente il warehouse per confermare se il problema e nello strumento della dashboard (caching, logica dei filtri) o nei dati stessi.
3. Tracciare la lineage a monte: seguire i dati dalla tabella della dashboard attraverso ogni fase di trasformazione. Controllare conteggi righe e metriche chiave a ogni passaggio.
4. Identificare il punto di rottura: la fase in cui i valori attesi divergono da quelli effettivi e la posizione della causa radice.
5. Verificare le cause comuni: modifiche dello schema nei sistemi sorgente, esecuzioni di pipeline fallite senza alert, dati in ritardo che hanno mancato la finestra di elaborazione o un deploy che ha modificato la logica di trasformazione.
6. Correggere e prevenire: risolvere il problema immediato, aggiungere un controllo di qualita dei dati che lo avrebbe intercettato e aggiornare il runbook.

Questa domanda testa la maturita nella gestione degli incidenti. I selezionatori vogliono vedere un pensiero strutturato, non tentativi casuali.

Prepararsi al colloquio di Data Engineering

Il percorso preparazione Data Engineering su SharpSkill copre questi argomenti con esercitazioni pratiche interattive su pattern ETL/ELT, data modeling, Airflow, BigQuery e altro ancora.

Conclusione

• Le window function SQL, le CTE e l'ottimizzazione delle query restano fondamentali indipendentemente dal livello di seniority
• Le decisioni ETL vs ELT devono essere guidate dai requisiti di latenza, dalle esigenze di governance dei dati e dai costi dell'infrastruttura piuttosto che dall'inseguimento delle tendenze
• Idempotenza, data contract e controlli di qualita dei dati distinguono le pipeline production-grade dai prototipi
• Le domande sull'architettura di streaming si concentrano sui compromessi (batch vs streaming vs micro-batch) piuttosto che sulla conoscenza di strumenti specifici
• Le scelte di data modeling (star vs snowflake, tipi SCD) devono essere allineate ai pattern di consumo, non alle best practice teoriche
• Le risposte di system design devono affrontare la gestione dei fallimenti, l'ottimizzazione dei costi e l'osservabilita insieme al percorso ideale
• I candidati piu forti dimostrano una risoluzione strutturata dei problemi e un ragionamento onesto sui compromessi