Domande Colloquio PySpark

Potete scrivere PySpark funzionante e comunque inciampare qui, perché queste domande chiedono cosa fa il motore, non cosa dice il vostro codice. Gli intervistatori aprono proprio con queste domande perché separano chi ha ottimizzato un job da chi lo ha solo eseguito. Questa sezione copre le domande sul modello e cosa include una risposta completa.

• Transformation o action, qual è la differenza? Le transformation costruiscono un piano e restituiscono lazy un nuovo DataFrame; action come count, collect o una write attivano l'esecuzione. Nulla viene calcolato finché un'action non richiede un risultato.
• Perché la laziness è utile? L'optimizer vede l'intera catena prima di eseguirla, quindi può riordinare i filtri, potare le colonne e combinare i passaggi.
• Transformation narrow o wide? Le operazioni narrow come filter e select mantengono ogni partizione di output dipendente da una sola partizione di input. Le operazioni wide come groupBy, join e distinct ridistribuiscono i dati tra le partizioni, ed è uno shuffle.
• Cos'è uno shuffle e perché conta? I dati si spostano in rete e toccano il disco, formando un confine di stage. Di solito è la cosa più costosa che un job fa.
• Spiegate job, stage e task. Un'action avvia un job, i confini di shuffle lo dividono in stage, e ogni stage esegue un task per partizione.
• RDD, DataFrame o Dataset? Preferite i DataFrame, perché si applicano l'optimizer Catalyst e l'esecuzione colonnare. Gli RDD restano per il controllo a basso livello. I Dataset tipizzati sono un concetto JVM, quindi in Python la risposta onesta è che non si applicano.

Dite le parole shuffle e stage quando appartengono alla risposta. Gli intervistatori le usano come scorciatoia per capire se avete mai letto una Spark UI.

La maggior parte dei colloqui PySpark senior sono colloqui sulle performance. Le domande arrivano come scenari, non come definizioni.

• Un join è lento. Cosa controllate? Prima la dimensione di ciascun lato. Se uno rientra nella memoria dell'executor, fatene il broadcast e saltate del tutto lo shuffle. Altrimenti guardate partitioning e skew prima di toccare la dimensione del cluster.
• Cos'è il data skew e come si risolve? Poche key contengono la maggior parte delle righe, così un task gira a lungo dopo che gli altri hanno finito. I rimedi includono il salting della hot key, il broadcast del lato piccolo, o il filtraggio dei null che finiscono tutti nello stesso hash. Il segnale diagnostico è la distribuzione della durata dei task nella Spark UI.
• Quando fate cache o persist? Quando un DataFrame viene riutilizzato in più action e ricalcolarlo sarebbe costoso. Fare cache di qualcosa usato una sola volta spreca memoria, e l'unpersist conta nei job lunghi.
• Repartition o coalesce? Repartition shuffla e può aumentare o diminuire le partizioni in modo uniforme; coalesce unisce senza uno shuffle completo, il modo più economico per ridurre i file in output.
• Perché evitare un UDF Python? Le righe vengono serializzate tra la JVM e un processo Python, e l'optimizer non vede dentro la funzione. Preferite le funzioni built-in, e ricorrete a un vectorized UDF solo se non esiste una built-in.
• Perché collect è pericoloso? Tira l'intero risultato verso il driver e può esaurirne la memoria.
• Un job fallisce per out of memory. Qual è il vostro ordine di indagine? Se è driver o executor, poi skew, poi il dimensionamento delle partizioni, poi la configurazione di memoria. Aumentare subito la memoria è la risposta che segnala inesperienza.

A un data engineer che faceva un colloquio per un team platform è stato chiesto perché un job notturno in esecuzione da un anno impiegasse improvvisamente quattro ore. La risposta giusta non era un cambio di configurazione, ma che un partner upstream aveva iniziato a inviare null nella join key, così ogni riga null finiva con lo stesso hash in un'unica partizione. Gli intervistatori premiano quell'ordine: guardare i dati prima del cluster.

Le raccolte di domande correlate per ruolo si trovano sotto interview questions by role.

Le domande restanti verificano se avete rilasciato una pipeline invece di finire solo un tutorial.

• Come leggete i dati in modo efficiente? Formati colonnari come Parquet, partition pruning sulla colonna del filtro, e predicate pushdown. Spiegate perché leggere meno byte batte l'ottimizzare ciò che accade dopo.
• Perché definire uno schema invece di farlo inferire? L'inferenza costa un passaggio extra sui dati e può indovinare i tipi in modo incoerente tra le esecuzioni.
• Come gestite null e duplicati? Le funzioni rilevanti, più il fatto che le join key piene di null creano skew.
• A cosa servono le window function? Ranking, totali progressivi e deduplica all'ultimo record per key, un compito di pipeline molto comune.
• Come scrivete l'output senza produrre migliaia di file piccoli? Coalesce o repartition prima di scrivere, e partizionate l'output su una colonna con cardinalità ragionevole.
• Come testate il codice PySpark? Piccole sessioni locali con DataFrame fixture, e la logica di business scomposta in funzioni che prendono e restituiscono DataFrame.
• Come inviate e configurate un job? Numero di executor, core e memoria, e il ragionamento per cui sia troppi executor piccoli sia troppo pochi grandi sprecano capacità.

Le risposte PySpark falliscono ad alta voce in modo riconoscibile. Il candidato sa che uno shuffle è costoso ma non sa dire quali operazioni ne causano uno, così la risposta diventa un elenco di aggettivi. Leggere una banca di domande produce riconoscimento, e il riconoscimento non è la stessa cosa di una spiegazione data mentre qualcuno aspetta.

Prendete una pipeline che avete costruito e raccontatela dall'inizio alla fine: la read, ogni transformation, dove cadono i confini di stage, e cosa controllereste per primo se rallentasse. Fatelo ad alta voce finché smettete di ricominciare. Esercitarsi con questi prompt contro un intervistatore AI che fa la domanda di follow-up è più vicino a un vero round che rileggere appunti, ed è per questo che è stata costruita la modalità mock interview.

Aaron Cao, fondatore di SubcueAI, ha costruito l'esercizio attorno a quel divario nel parlare piuttosto che attorno a fornire più domande. In un colloquio dal vivo l'app desktop e il Side Panel dell'estensione del browser possono far emergere la struttura mentre l'intervistatore parla, il che aiuta di più sul materiale che avete già provato. La configurazione richiede pochi minuti ed è descritta nella pagina tutorial.