Data Modeling Practice for Data Engineering Interviews

Drag in tables, attach columns, draw foreign keys. The validator checks your table set, relationships, normalization level, and key choices against the reference solution. Multiple correct solutions are accepted because real modeling rarely has one right answer.

Almost every wrong fact table starts with a misstated grain. The validator surfaces the grain it inferred from your design and tells you whether it matches the requirement. If it does not, the rest of the feedback is held back so you fix the foundation first.

Early problems are a single fact and three dimensions. Later problems add bridge tables, junk dimensions, multiple grains, SCD2 with effective-dating bugs, and conformed dimensions across two facts. Difficulty is not about adding more columns.

A modeling round at Amazon for L5 has a different shape than the same round at a 200-person Series C. The filters scope the bank to the patterns and depths those loops actually hit.

When you submit, the validator names what is off: missing dimension, wrong cardinality on a join, an SCD column that should have been on the dim, a fact with mixed grain. Useful for actually learning rather than retrying blind.

Star, snowflake, SCD types, junk dimensions, bridges, data vault, conformed dimensions. Each tracks separately so you can see which patterns you have actually internalized versus which ones you can recognize but not draw.

Clear requirements, no timer. Build the schema on the canvas and submit when you are satisfied. The validator returns structural feedback in seconds. Best when you are learning a new pattern, like the first time you build an SCD2 dim or a junk dimension.

A deliberately under-specified scenario, a timer, and an AI interviewer that pushes on trade-offs as you draw. Mid-design they may add a requirement that breaks your grain, the way a real interviewer would. Verdict at the end with the specific design choices that decided it.