9 Data Modeling Questions That Win $200k Databricks Offers
Why 3NF loses and query patterns win
Two engineers get the same take-home: model a retail analytics layer from a stream of order events. The first normalizes everything to third normal form, proud of a clean schema with zero redundancy. The second asks one question before writing a single line: how will this get queried, and what will each query cost?
Only one of them gets the $200k offer.
Data modeling is where senior Databricks interviews quietly separate people. Anyone can copy a pipeline off a blog. Almost nobody can defend a table layout against real query patterns and real compute cost. That defense is the signal - it tells the interviewer you have run something in production long enough to feel the difference between a schema that reads clean and a schema that reads cheap.
Here are the nine data modeling questions senior interviews actually test, and the answers that prove you think past the pipeline.
Question 1: “Walk me through what data modeling looks like across Bronze, Silver, and Gold. Where does the actual modeling happen?”
The Junior Answer: “Bronze is raw, Silver is cleaned, Gold is aggregated. So the modeling happens in Gold.”
Why this fails: it treats medallion as three copies of increasing cleanliness. It misses that the modeling intent is different at every layer, which is the whole point of the architecture.
The Senior Answer: “Each layer models for a different job. Bronze preserves raw source fidelity - append-only, minimal transformation, so I can always replay if a downstream assumption breaks. Silver is where I conform: dedupe, enforce schema, resolve business keys, and shape data into clean queryable entities. That layer can stay lightly normalized. Gold is where I model for consumption - star schemas, denormalized marts, pre-aggregations shaped to the exact way the BI tool and the analysts hit it. Bronze optimizes for trust, Silver for conformance, Gold for read cost.”
Key concepts to mention:
Bronze as replayable source of truth, not a staging dump
Silver conformance: business keys, dedup, schema enforcement
Gold shaped to consumption, not to storage neatness
Modeling intent differs per layer (fidelity vs conformance vs read cost)
Replay-ability as the reason Bronze stays raw
What Interviewers Are Testing: Do you understand that medallion is a modeling discipline, not a folder-naming convention? Engineers who say “Bronze, Silver, Gold” without explaining the why per layer signal they inherited a pattern instead of designing one.
Question 2: “Would you build a star schema or one wide denormalized table for your Gold layer?”
The Junior Answer: “Star schema. It’s the standard for analytics.”
Why this fails: reciting Kimball as a default, with no read of the actual workload, is exactly the textbook-first instinct that gets you capped at mid-level.
The Senior Answer: “It depends on the query pattern and what the join costs. On a columnar lakehouse with Photon, a well-clustered star with broadcastable dimensions is flexible and keeps dimensions conformed across marts, so I reach for it when many marts reuse the same dimensions. But if a dashboard hammers one predictable access pattern at high concurrency, a wide denormalized table wins - it removes the read-time join entirely. The cost I am trading is storage and update complexity: a single dimension attribute change means rewriting every wide row that carried it. So: star for reuse and flexibility, one-big-table when the join shuffle or concurrency dominates and the dimensions are slow to change.”
Key concepts to mention:
Join shuffle cost vs storage-and-rewrite cost as the real tradeoff
Broadcast joins make small dimensions cheap in a star
Conformed dimensions reused across marts favor the star
Denormalized wide tables kill read-time joins but inflate update cost
The decision is driven by concurrency and dimension volatility, not dogma
What Interviewers Are Testing: Can you hold two valid designs in your head and pick based on cost, or do you have one hammer? This is the single clearest tell between an engineer who read the book and one who has paid the compute bill.
The pattern in those two answers is the whole game: the junior reaches for the canonical shape, the senior reaches for the query pattern and the cost. Here are the remaining seven, at speed.
Question 3: “Is third normal form the goal for your Silver layer? When do you deliberately denormalize?”
The junior reflex: “3NF is clean, so it’s always the target.”
The senior answer: Third normal form minimizes redundancy for write-heavy transactional systems, where the same fact gets updated in one place. Analytics is read-heavy and append-mostly, so redundancy that removes a join is a feature, not a sin. I keep Silver lightly conformed, then denormalize aggressively into Gold wherever a read pattern and its cost justify collapsing a join. Normal form is a tool I reach for on the write side, not a virtue I chase on the read side.
Signal: you treat normalization as a cost lever, not a cleanliness score.
Question 4: “How do you declare the grain of a fact table, and why does it matter?”
The junior reflex: start listing the columns they want.
The senior answer: Declare the grain first - one row per what. Per order line, per shipment event, per daily account snapshot. Everything else follows from that decision: which dimensions attach, and whether every measure is additive at that grain. The classic failure is mixing grains in one table, like putting order-line rows next to order-header totals, which double-counts the moment someone sums a measure. Grain is the first thing I write down and the last thing I let anyone violate.
Signal: you design from the grain outward, not from the column list inward.
Question 5: “How do you implement SCD Type 2 in Delta, and when would you use Type 1 instead?”
The junior reflex: “Type 2 keeps history, so always use Type 2.”
The senior answer: Type 1 overwrites in place - no history, used when I only care about the current correct value, like fixing a misspelled city. Type 2 preserves history by closing the current row (stamp an end timestamp, flip the is-current flag) and inserting a new version with a fresh validity window. I implement it with a MERGE that does the close-and-insert in one atomic operation. I reach for Type 2 when point-in-time truth matters - price at time of sale, account status during an incident - and Type 1 when history is noise. The gotcha to name: any fact joining a Type 2 dimension needs point-in-time join logic, not just a key match.
Signal: you know history is a cost you take on purpose, and you know it complicates every downstream join.
Question 6: “Do you use surrogate keys in a lakehouse, and how do you generate them safely?”
The junior reflex: “I’ll use an auto-increment ID.”
The senior answer: Natural keys collide across source systems and mutate over time, so I decouple with surrogate keys. The catch is that generating gap-free sequential IDs in a distributed engine is genuinely hard. Delta’s identity columns give me unique, generally increasing values but no guarantee they are consecutive or gap-free, which is fine for a join key and a dealbreaker if someone expects a clean sequence. For idempotent pipelines I often prefer a deterministic hash of the natural key plus source system, because it reproduces identically on reprocessing. The trap I call out: never persist a value from a within-query row-number function as a stable key, because it is only unique inside a single write, not across runs.
Signal: you know identity columns exist, you know their gap caveat, and you reach for reproducibility when the pipeline reruns.
Question 7: “You have a 5TB fact table queried mostly by date and region. How do you choose the layout?”
The junior reflex: “Partition by date.”
The senior answer: On a modern Delta table I reach for Liquid Clustering and cluster on the columns queries actually filter and join on - here, date and region. It adapts as the table grows and avoids the small-file and over-partitioning problems you hit when you partition by anything high-cardinality. I do not stack partitioning and clustering; they are mutually exclusive, so it is one choice, not a combo. I pick the clustering keys from the real predicates in the query history, not a guess. And I frame it as a cost decision as much as a speed one - over-partitioning shatters a 5TB table into tiny files, inflates metadata and listing overhead, and quietly makes every query more expensive.
Signal: you choose layout from observed query predicates and treat it as a spend decision, not a reflex.
Question 8: “A fact row arrives before its dimension exists. How do you model for that?”
The junior reflex: drop the row or let the load fail.
The senior answer: Losing facts to a missing dimension is unacceptable, and so is breaking referential integrity. I insert an inferred dimension member - a placeholder row carrying the natural key with attributes marked unknown - and assign it a surrogate key so the fact joins cleanly right now. When the real dimension record shows up later, I update that placeholder in place with the true attributes. The fact never needed to change, nothing got dropped, and the model stayed consistent the entire time.
Signal: you protect both the facts and referential integrity instead of choosing one.
Question 9: “Source data changes all day. How do you keep the Gold model in sync?”
The junior reflex: “Full reload every night.”
The senior answer: Full rewrites of large facts are the expensive habit I design out. I drive incremental upserts with a MERGE, and I source the changed rows from Change Data Feed on the upstream Delta tables so I only process what actually moved. The SCD logic runs on that change set, not the whole table. For continuous pipelines I lean on structured streaming with a batch-level merge, or Lakeflow Declarative Pipelines’ built-in change-apply capability (AUTO CDC), so the model updates through the day instead of in one nightly cliff. The non-negotiable is idempotency: reprocessing the same changes has to produce the same result.
Signal: you process deltas, not whole tables, and your reruns are safe.
The One Question Behind All Nine
Read those answers back and the senior move never changes. Before modeling any table, the senior asks how it will be read and what each read costs, then shapes the schema to that answer. The junior asks what the textbook says the schema should look like.
That is the entire $135k-to-$200k gap in one habit. Mid-level engineers model for correctness and stop there. Senior engineers model for correctness and the compute bill and the query pattern and the day the dimension changes. Data modeling judgment is the defining senior signal in a Databricks interview precisely because it cannot be memorized - it only comes from having defended a layout against a workload that fought back.
Walk into the interview ready to defend, not recite. That is the offer.
Which of these nine trips up your team most - the 3NF instinct, or the partition-by-everything reflex? Tell me in the comments, and I’ll turn the most common one into a full deep dive.
Premium Further Reading
The deep-dives a reader who just worked through these nine questions would naturally pick up next: the modeling theory, the Delta patterns, and the layout decisions the answers only had room to name. Old posts are auto-archived for premium subscribers only.
Every answer here hinged on one move: model for the query pattern and the read cost, not the textbook. These picks extend that frame into 3NF, SCD Type 2 pipelines, and clustering layout.
Why 3NF Is Killing Your Databricks Dashboards: Stop normalizing your analytical tables. The textbook was written for a different database.
Data Modeling in Databricks: The Complete Guide: From stakeholder interviews to production deployment - the 20% of knowledge that delivers 80% of results
Databricks CDC Interview: The 200GB/Day Pipeline with SCD Type 2: Why custom MERGE logic is the trap, and how AUTO CDC + Liquid Clustering is the senior answer that wins FAANG offers
How Liquid Clustering Actually Beats Partitioning + Z-Order: The decision tree for every 2TB+ Delta Lake table
Stop Tuning Spark Configs. Fix Your Data Model: The 90% of slowness no executor setting can touch
Keep Practicing?
You just rehearsed the senior answers to grain, SCD Type 2, and star-vs-wide. Now go defend them out loud - drill the questions, close the concept gaps, and walk in ready to argue layout against a workload.
Senior Interview Cheat Sheet: Structure your production experience into the senior-level answers that get $175K-$210K+ offers. Built from 100+ posts with 1M+ views.
DataDojo (633 exercises): Duolingo-style daily practice for Databricks data engineers. Seven zones, XP, streaks, and certification prep.
Databricks Code Practice (104 exercises + 4 labs): One repo, three tracks: 104 LeetCode-style exercises, 4 end-to-end pipeline labs, and benchmark deep-dives. Runs on Databricks Free Edition.
Databricks 100 (100 concepts): The must-know concepts for every Databricks data engineer. Self-score, find gaps, commit to the 100-day challenge.
The distinction between knowing a modeling pattern and knowing when to apply it is what makes these good senior-level questions.
Production experience often comes down to understanding the costs and consequences of each choice.