Get to Your Action Fast
Concepts covered: Broadcast Join
Where the first minutes go
Many war stories are lost before the engineering starts. The candidate covers the company, the team, the stack and the job's history, and the interviewer, who has budgeted a few minutes for the whole answer before follow-ups, hears none of the work being graded. Context earns its place only when the listener needs it to follow your action. For a Spark speedup that is 2 facts: what the job produces, and why its runtime mattered.
| Segment | Slow opening | Fast opening |
|---|---|---|
| Headline sentence | none | 8 s |
| Company and team | 60 s | left out |
| Tech stack | 50 s | named only where the fix touches it |
| History of the job | 70 s | left out |
| Who uses the output | 60 s | a clause: the 05:00 dashboards |
| Time before the action | 240 s | 28 s |
| Action starts at | not reached | 0:28 |
The slow column is the opening Priya gave in the interview from the intro. At 4 minutes she still had not reached the change, and the interviewer had to ask for it.
The fast opening, word for word
Priya rebuilt her opening as the headline sentence from the last section followed by 2 sentences of context. Here is the context she says after the headline, and then she stops setting the scene.
Leave out the company name, the team size, the scheduler and the year. If the interviewer wants any of those, they will ask, and answering a question in 5 seconds costs less than a paragraph they did not need. The 2 sentences keep the fact an interviewer will use later: the deadline, which is what makes 94 minutes a problem and 21 a fix.
Tell the action as a chain of evidence
The action is what the interviewer is scoring, so tell it in the order you lived it, and tie each step to a place in the Spark UI and the figure it showed. That proves you investigated, and every figure becomes a handle the interviewer can pull with a follow-up.
- Noticed: the Jobs tab put the nightly job at 94 minutes, past the 05:00 refresh on every run that month.
- Looked: in the Stages tab, one stage ran 68 minutes with 140 GB of shuffle read and 61 GB spilled to disk.
- Found: the SQL tab showed a SortMergeJoin, fed by an Exchange from orders and another from the 3 MB stores.
- Read: an Exchange node is a shuffle, so both inputs were being repartitioned across the network.
- Asked why: 3 MB is far under the 10MB broadcast default, so I opened the Environment tab.
- Cause: spark.sql.autoBroadcastJoinThreshold was -1, inherited from a shared config template.
- Changed: dropped the inherited setting from this job and added a broadcast hint on stores.
- Measured: 7 runs on each side, comparing runtime, plan and output.
Read the chain back and notice that the plan did the diagnosing. The Stages tab said where the time went, the SQL tab said what kind of join was running, and the clash between a tiny table and a shuffle on both join inputs pointed at a setting. That reasoning, spoken out loud, is the strongest minute of the answer.
template: batch_default
spark_conf:
spark.executor.instances: 40
spark.executor.cores: 4
spark.executor.memory: 16g
spark.sql.shuffle.partitions: 200
spark.sql.autoBroadcastJoinThreshold: -1
Say 'I' for your part
Interviewers listen for 'we' in the action and follow it with 'what was your part?' Use 'I' for what you did: the investigation, the change, the comparison. Use 'we' for what the team decided, such as when to roll the change out. If a teammate found the cause, the story can still work: tell the part you owned, such as the measurement or the reconciliation, and name who found the cause.
About this lesson
This section is part of the The War Story lesson on DataDriven, the home of data engineering. Lessons cover SQL, Python, Spark, data modeling and pipeline architecture, and each section pairs its explanation with worked examples and practice you run as you go.