How are data modeling practice problems graded without a single correct answer?

The rubric scores the decision process, not a specific schema. Grain stated in one sentence (25 percent), dimension design with SCD justification (25 percent), trade-off articulation between star/snowflake/OBT (20 percent), fact additivity identification (15 percent), and edge case handling like late-arriving dims (15 percent). Multiple valid schemas score well if the data engineer can defend each choice.

What is the most common mistake in data modeling practice?

Starting to draw before stating the grain. The candidate jumps to dim_customer and dim_product before saying 'one row per order line item' and ends up with a mixed-grain fact table. The fix is to write the grain on the whiteboard first, then build outward.

Do these practice problems test specific warehouse vendors?

Most stay vendor-neutral and test pure Kimball-style design. Vendor-specific practice exists for Amazon (Redshift DISTKEY and SORTKEY decisions), Snowflake (clustering keys, micro-partition awareness), BigQuery (partitioning and clustering), Databricks (Delta MERGE INTO patterns). The vendor-specific variants are tagged on the problems where they apply.

How many data modeling practice problems should I solve before an interview?

Six well-designed schemas across six different domains beats twenty rushed schemas on similar domains. The signal interviewers test is whether you can transfer the pattern to a new domain. Aim for e-commerce, marketplace, rideshare, payments, ad tech, content platform. Each takes 30-45 minutes; finish all six over 2 weeks with rubric review after each.

What domains do data modeling rounds use in 2026?

Most often: marketplace (two-sided fact with buyer and seller dims), rideshare (trip-grain with location dim), payments (transaction-grain with merchant SCD2), ad tech (impression-conversion bridge), content platform (viewership-event grain). Less often: traditional e-commerce, supply chain, healthcare claims. The fundamental patterns transfer across domains; the practice value is in defending design choices in a new context.

Should I memorize specific schemas for the interview?

No. Memorized schemas fail under follow-up. Practice the decision-making process. State grain, choose SCD type per attribute with reason, build conformed dimensions, defend star vs snowflake. When the interviewer asks 'why Type 2 here', the memorizer has no answer; the practiced data engineer recalls the reason because they made the choice from first principles.

What is the bar for senior data engineer vs entry-level on modeling problems?

L4 (entry-mid): produce a working schema with correct grain and reasonable dimensions. L5 (senior): defend two alternatives, name conformed-dimension benefits, handle the mid-round pivot when the interviewer changes a requirement. L6 (staff): add platform-level concerns like multi-region replication, audit trail, schema evolution without downtime, and the data contract with upstream and downstream teams.

Data Modeling Practice Problems, Rubric-Scored

Data Modeling Practice Problems

Hands-on schema design practice for data engineer interview prep.

Data modeling practice problems for data engineer interview prep. Whiteboard schema design with rubric-scored verdicts covering grain selection, dimension type, SCD choice, and trade-off articulation across e-commerce, marketplace, rideshare, payments, ad tech, and content platform domains.

Data modeling practice for data engineer interviews looks different from SQL or Python practice. There is no auto-grader for "is this schema correct" because multiple valid designs exist for any domain. What the rubric scores instead is the decision-making process: did the data engineer state the grain in one sentence, choose appropriate SCD types per attribute with justification, build conformed dimensions across facts, defend star versus snowflake versus OBT in the specific domain, and articulate the trade-offs the interviewer would ask about next.

Six domains anchor the practice catalog. E-commerce: order-line-item grain fact with dim_customer (Type 2), dim_product (Type 2), dim_store (Type 1 for typos, Type 2 for re-branding), dim_date. Marketplace: a two-sided fact joining buyer and seller with dim_user (Type 2 with role attribute), dim_listing (Type 2 for price changes and active status), dim_geo. Rideshare: trip-grain fact with dim_rider (Type 2 for rating history), dim_driver (Type 2 for car and rating), dim_pickup_location and dim_dropoff_location (both FK to the same dim_location, usually an H3 cell), dim_date_time. Payments ledger: transaction-grain fact with dim_merchant (Type 2 for payout schedule and MCC), dim_customer (Type 2 for risk profile), dim_payment_method (Type 1 because PMs are immutable once issued). Ad tech: impression-conversion bridge table with dim_advertiser (Type 2 for billing relationship), dim_campaign (Type 2 for budget and targeting), dim_creative, dim_publisher. Content platform: viewership-event grain fact with dim_content (Type 2 for title and category), dim_user (Type 2 for subscription tier), dim_device (Type 1 because device attributes do not change), dim_date_time.

Rubric weights for each practice problem. Grain correctness (one row per X stated explicitly and consistent across measures): 25 percent. Dimension design (SCD types correct, conformed dimensions used appropriately): 25 percent. Trade-off articulation (star vs snowflake vs OBT defended in the specific domain): 20 percent. Fact additivity (additive vs semi-additive vs non-additive measures identified): 15 percent. Edge case handling (late-arriving dimensions, bridge tables for many-to-many, slowly-changing facts): 15 percent. The L4 candidate hits 60-70 percent; the L5 candidate hits 80-90 percent; the L6 candidate adds platform-level concerns (multi-region replication, audit trail, schema evolution without downtime).

Common failure modes the rubric explicitly fails. Drawing before stating the grain. Mixed-grain fact table (some rows at order-level, some at line-item-level). Missing conformed dimension (separate dim_customer schema in orders versus returns facts). Forgotten bridge table on a many-to-many (impression-conversion joined directly producing duplication). Choosing snowflake on a small dim that should be star. Choosing star on a high-cardinality dim that needs snowflake or a separate bridge. Picking Type 1 for an attribute where downstream queries need point-in-time correctness (the customer address case, where ship-to history matters for a year-old order). The catalog catches each of these in practice scenarios.

Data modeling interview questions catalog - Full catalog with rubric-scored verdicts.
Data modeling interview prep guide - Round-by-round prep covering grain selection and dimension design.
Star schema interview questions - Conformed dimensions, additive facts, defending star over snowflake.
Dimensional modeling interview questions - Kimball-style design across multiple domains.
SCD merge logic practice problems - Type 2 merge in SQL and pandas with composite tiebreakers.
Fact table interview problems - Grain selection, additivity, snapshot vs transaction.
Data warehouse interview problems - Warehouse design, fact granularity, conformed dimensions.
Full data engineer coding practice - Pair modeling with SQL, Python, and PySpark.

How are data modeling practice problems graded without a single correct answer?: The rubric scores the decision process, not a specific schema. Grain stated in one sentence (25 percent), dimension design with SCD justification (25 percent), trade-off articulation between star/snowflake/OBT (20 percent), fact additivity identification (15 percent), and edge case handling like late-arriving dims (15 percent). Multiple valid schemas score well if the data engineer can defend each choice.
What is the most common mistake in data modeling practice?: Starting to draw before stating the grain. The candidate jumps to dim_customer and dim_product before saying 'one row per order line item' and ends up with a mixed-grain fact table. The fix is to write the grain on the whiteboard first, then build outward.
Do these practice problems test specific warehouse vendors?: Most stay vendor-neutral and test pure Kimball-style design. Vendor-specific practice exists for Amazon (Redshift DISTKEY and SORTKEY decisions), Snowflake (clustering keys, micro-partition awareness), BigQuery (partitioning and clustering), Databricks (Delta MERGE INTO patterns). The vendor-specific variants are tagged on the problems where they apply.
How many data modeling practice problems should I solve before an interview?: Six well-designed schemas across six different domains beats twenty rushed schemas on similar domains. The signal interviewers test is whether you can transfer the pattern to a new domain. Aim for e-commerce, marketplace, rideshare, payments, ad tech, content platform. Each takes 30-45 minutes; finish all six over 2 weeks with rubric review after each.
What domains do data modeling rounds use in 2026?: Most often: marketplace (two-sided fact with buyer and seller dims), rideshare (trip-grain with location dim), payments (transaction-grain with merchant SCD2), ad tech (impression-conversion bridge), content platform (viewership-event grain). Less often: traditional e-commerce, supply chain, healthcare claims. The fundamental patterns transfer across domains; the practice value is in defending design choices in a new context.
Should I memorize specific schemas for the interview?: No. Memorized schemas fail under follow-up. Practice the decision-making process. State grain, choose SCD type per attribute with reason, build conformed dimensions, defend star vs snowflake. When the interviewer asks 'why Type 2 here', the memorizer has no answer; the practiced data engineer recalls the reason because they made the choice from first principles.
What is the bar for senior data engineer vs entry-level on modeling problems?: L4 (entry-mid): produce a working schema with correct grain and reasonable dimensions. L5 (senior): defend two alternatives, name conformed-dimension benefits, handle the mid-round pivot when the interviewer changes a requirement. L6 (staff): add platform-level concerns like multi-region replication, audit trail, schema evolution without downtime, and the data contract with upstream and downstream teams.

66 practice problems matching this filter. Difficulty: medium (36), easy (9), hard (21).

Data Modeling (66)

Split Decision - medium - One user, one experiment, one variant. No exceptions.
Where They Used to Live - medium - They moved. The data stayed behind.
The Double Count - medium - One flight carries hundreds of seats; one ticket spans many flights. Model them so neither gets counted twice.
A Number for the Seller - easy - They want a total. Give them the right schema first.
Ghosts in the Ledger - easy - Invoices go out, partial payments trickle in, and some customers are three months overdue.
The Anonymous Majority - medium - Millions of clicks, mostly anonymous.
Cloud File Storage Metadata Schema - hard - A file is also a folder. A folder is also a file.
Content Engagement Data Model - hard - Post published. Now measure everything that happens next.
Content Search and Discovery Schema - hard - Searchable from every angle. Design it so nothing gets lost.
Crossing Over - medium
Where Everyone Was - easy - People move. Sometimes twice in a month. How do you remember where everyone was, and when?
E-Commerce Supply Chain Tracking - hard - A package splits, reroutes, and (maybe) arrives.
Signal and Silence - medium - They opened the assignment. Did they actually read it?
Employee Application Time Tracking - medium - Every minute tracked. Every app accounted for.
Employee Transfer Tracking System - medium - People switch teams. HR loses track.
The Vanishing State - easy - A status column forgets the moment it changes. Model the schema that remembers.
Financial Trading Warehouse - hard - Every trade, every tick, every fraction of a share. The regulators want receipts.
Personal Best - easy - Reps, sets, streaks, and personal bests. Gym rats love their stats.
The No-Show - easy - Every reserved seat ends one of five ways. Build the model that can tell them apart.
Food Truck Operations Data Model - medium - Mobile vendor, fixed menu, unpredictable locations.
Deal Flow - medium - Sellers want buyers. Buyers want deals.
Insurance Claims Lifecycle - hard - A claim gets filed. Then it gets complicated. Then it gets reassigned. Then it loops back.
Livestream Analytics Schema - medium - Someone goes live, thousands tune in, chat explodes, and virtual gifts start flying.
Approval and After - medium - Approved, declined, or pending. Design the tables that say so.
The Balance Always Reconciles - easy - Money out, payments back. The balance has to be exact.
The Vital Few - medium - Two terabytes a day, and the lines that matter are a rounding error in the noise.
The Shape of a Run - medium - Two log lines bracket every process. Pair them and the fleet's rhythm appears.
Marketplace Sales Warehouse - hard - No schema given. The interviewer is watching.
Metric Definition Reverse Engineering - hard - Five numbers on a dashboard. Your job: figure out where they come from.
Movie Streaming Analytics Schema - medium - They pressed play. What happened next is the whole question.
Multiplayer Game Match History - medium - Millions of matches. The leaderboard refreshes in fifteen minutes.
Online Marketplace - Seller Payouts - hard - The buyer paid one number. The seller got a different one.
The Retail Blueprint - medium - One business. A thousand transactions. Only one layout survives the analytics layer.
The Last Mile - medium - Order placed. Now track it to the door.
POS Sales Data Warehouse - medium - Every beep at the register. Coupons, returns, all of it.
Property Booking Platform - hard - Five-star listing. Three-star reality.
Retailer Data Warehouse Design - medium - Queries are crawling. The analysts are not happy.
Ride-Sharing Platform Schema - medium - Riders, drivers, and fares. Everyone takes a cut.
The Sales Architecture - medium - Numbers are easy. Making them queryable at scale is the real job.
The Customer Who Changed - hard - She moved. She upgraded. She became someone new. The record has to keep up.
The Endless Thread - medium - Follows, likes, replies to replies. It never stops.
Two Wallets - medium - Two user types. Multiple payment methods. One messy billing table.
When the Music Stops - medium - Subscribers are leaving. The data knows why.
The Heat of the Map - hard
Telecom Network Connectivity Warehouse - hard - One device goes down. The ripple keeps going.
The Celebrity Problem - medium - One post. A million notifications. Something has to give.
The Churner Who Came Back - hard - They cancelled. They came back. The report has to tell both stories correctly.
The Float - medium
The Gaps Between Clicks - hard
The JSON Files That Became a Data Mart - medium - Three semi-structured inputs. One queryable warehouse.
The League With Too Many Loyalties - hard - A player can belong to many teams. The schema must agree.
The Other Seat - hard
The Person They Were Then - easy
The Plan That Changed Twice This Month - medium - Subscribers come, go, downgrade, and share. The schema has to keep up.
The Retail Tables That Need a New Home - medium - A working system. Now redesign it so the analysts can actually use it.
The Schema That Could Not Answer Back - hard - Forty columns in. Zero useful answers out.
The Slow Yes - hard
The Table That Lies - medium - Every query comes out wrong. The data is all there.
The Talent Funnel - medium - Thousands applied. One accepted. Where did the rest go?
The Territory That Keeps Moving - hard - Reps get reassigned. The receipts have to survive.
The Transfer Request - medium - Apply, wait, get approved or denied. Track all of it.
Three-Sided Marketplace Delivery Schema - hard - One order. Two deliveries. Revenue counted twice. Where is the bug in your schema?
Time in Force - medium
Toll Road Sensor Analytics - easy - Cars enter, cars exit. Except when they don't.
Trending Dishes Dashboard - medium - What's everyone eating? The answer changes hourly.
Who Comes Back - medium