Reviewed by Aditya Kumar · Last reviewed 2026-03-24
Broadcasting sends a small table replica to every executor so joins execute locally without shuffle. **Why it matters**: A shuffle join moves both sides across the network; broadcast join moves only the small side once from driver to executors. **Scalability trade-off**: The...
This medium-level Spark/Big Data question appears frequently in data engineering interviews at companies like Altimetrik, Infosys. While less common, it tests deeper understanding that distinguishes strong candidates. Mastering the underlying concepts (join, spark, sql) will help you answer variations of this question confidently.
Break this problem into components. Identify the core trade-offs involved, then walk the interviewer through your reasoning step by step. Demonstrate awareness of edge cases and production considerations - this is what separates good answers from great ones.
Broadcasting sends a small table replica to every executor so joins execute locally without shuffle. Why it matters: A shuffle join moves both sides across the network; broadcast join moves only the small side once from driver to executors. Scalability trade-off: The small table must fit in executor memory; exceeding this causes OOM. As cluster size grows, more copies exist (N executors × table size), so large broadcasts waste memory. Cost implication: Avoids expensive shuffle I/O and disk spill; typical 10–100× faster for dimension–fact joins on large fact tables. Example: from pyspark.sql.functions import broadcast; df_large.join(broadcast(df_small), "key"). Use when one side is < spark.sql.autoBroadcastJoinThreshold (default 10MB). Explicit broadcast() guarantees behavior; Spark may auto-broadcast otherwise. Best practice: Check table size before broadcast; use for lookup/dimension tables in star schema; increase threshold only on small clusters with sufficient memory.
Red Flag: Broadcasting a 500MB table and saying 'it works on my laptop'—production will OOM. Pro-Move: 'I profile dimension sizes with DESCRIBE DETAIL and set broadcast thresholds per job based on executor memory and cluster size.'
Some links below are affiliate links. If you buy through them we may earn a small commission at no extra cost to you — it helps keep DataEngPrep free.
According to DataEngPrep.tech, this is one of the most frequently asked Spark/Big Data interview questions, reported at 2 companies. DataEngPrep.tech maintains an editor-reviewed database of 1,863 data engineering interview questions across 7 categories.