Domande da Colloquio per Data Engineer, per Fase

Potresti prepararti nello stesso modo in cui ti prepareresti per un percorso da software engineer, chiedendoti cosa cambia. Questa sezione mappa le fasi che questi colloqui riutilizzano, così puoi dedicare il tempo alle due che davvero distinguono i candidati. Il filtro tecnico raramente è dove si perdono le offerte.

• SQL. Window function, deduplicazione e prestazioni delle query, di solito dal vivo.
• Modellazione dati. Progettare tabelle per un business descritto, e difendere il grain scelto.
• Progettazione di pipeline ed ETL. Una fase di system design aperta, focalizzata sul movimento dei dati.
• Elaborazione distribuita. Come un framework esegue davvero il tuo job, e perché è lento.
• Coding. Python o Scala, spesso più leggero di una fase da software engineer.
• Comportamentale. Incidenti in reperibilità, dashboard rotte, e stakeholder che volevano il numero ieri.

I titoli si sovrappongono molto ai ruoli di analytics engineering e platform, quindi il mix cambia. I question bank per ruoli correlati si trovano nell'hub domande per colloquio per ruolo.

SQL

• Deduplica una tabella mantenendo solo la riga più recente per ogni chiave.
• Scrivi una query che restituisce il conteggio di sessioni di ogni utente usando un gap di inattività di 30 minuti.
• Calcola un totale progressivo e una variazione mese su mese in un'unica query.
• Trova le righe presenti nello snapshot di ieri ma mancanti in quello di oggi.
• Cosa fa QUALIFY, e cosa scriveresti senza di esso?
• Questa query scansiona un miliardo di righe e impiega venti minuti. Come la diagnostichi?
• Spiega la differenza tra partitioning e clustering, e quando ciascuno aiuta.

Modellazione dati

• Progetta le tabelle per lo storico ordini di un marketplace online. Qual è il grain della tua fact table?
• Spiega uno star schema, e quando denormalizzeresti deliberatamente ulteriormente.
• Cos'è una slowly changing dimension, e come implementi il tipo due?
• Uno stakeholder vuole che il reporting storico rifletta la regione attuale di un cliente. Cosa si rompe?
• Come modelleresti un event stream che arriva fuori ordine?
• Quando sceglieresti una tabella ampia rispetto a un modello normalizzato?

La fase di modellazione premia chi si impegna su un grain e lo difende. I candidati che descrivono tre possibili design senza sceglierne uno ottengono punteggi peggiori rispetto a chi sceglie un design ragionevole e ne nomina il punto debole.

Progettazione di pipeline ed ETL

• Progetta una pipeline che carica le transazioni giornaliere in un warehouse per il reporting.
• La fonte upstream invia di nuovo i dati di ieri. Cosa succede al tuo job?
• Come rendi idempotente una pipeline, e perché conta per le riesecuzioni?
• Come faresti il backfill di due anni di storico senza interrompere il caricamento giornaliero?
• Dati in ritardo emergono tre giorni dopo la chiusura della partizione. Cosa fai?
• Come rilevi che una pipeline è riuscita ma ha prodotto dati sbagliati?
• Cosa monitori, e cosa fa suonare il cercapersone di qualcuno alle tre di notte?

Elaborazione distribuita e streaming

• Cosa causa uno shuffle, e perché è costoso?
• Il tuo job è lento e un task impiega molto più tempo degli altri. Cosa sta succedendo?
• Spiega il data skew e due modi per gestirlo.
• Quando sceglieresti lo streaming rispetto a un job batch pianificato?
• Cosa garantisce davvero l'exactly once processing, e dove non vale?
• Come gestiscono i watermark gli eventi fuori ordine in un'aggregazione windowed?

Nota quante poche di queste domande ti chiedono di nominare uno strumento. Nominarne uno è l'inizio della risposta, non la risposta. La domanda di follow-up è sempre perché, e cosa si rompe.

Leggere queste liste crea riconoscimento. Le fasi di design testano altro: tenere un sistema in testa mentre qualcuno ti interrompe con un caso di guasto. Questo si ottiene solo dicendo i design ad alta voce.

• Disegna e narra una pipeline in quindici minuti. Source, landing, transform, serve, più come fallisce ogni fase.
• Attacca il tuo stesso design. Dopo ogni sessione di pratica, chiediti cosa succede a una riesecuzione, a dati in ritardo, e a un cambio di schema.
• Tieni pronto un numero per la scala. Righe al giorno, dimensione, budget di latenza. Dichiarare per primo la scala assunta viene valutato.
• Scrivi SQL a mano. Le fasi dal vivo spesso usano un editor semplice, senza autocomplete e senza esecuzione.
• Prova bene una storia di incidente. Cosa si è rotto, come l'hai scoperto, cosa hai cambiato perché non potesse ripetersi.

Una data engineer con sei anni su pipeline batch si è preparata rivedendo gli interni dei framework, poi si è bloccata su "la fonte upstream ha rimandato il file di ieri" perché lo aveva sempre gestito a mano, mai spiegato. La conoscenza c'era; la risposta parlata no. Esercitarsi sulla fase di design con i follow-up è esattamente ciò per cui è costruita la modalità mock interview.