The Silence After 'Walk Me Through Your Model' Explains Everything

Interview Insights · Data Analytics

The Silence After 'Walk Me Through Your Model' Explains Everything

SECTION 01What the pause tells me about how the report was built

There are two kinds of model a data analytics candidate might mean: a predictive model or a data model. On this page I mean the second one, the structure of tables and relationships behind a Power BI or Tableau dashboard. When I say 'walk me through your model', I want to hear how the data is organised before any chart appears.

The pause that follows is very informative. A short pause while the candidate pictures the diagram is normal. A long pause followed by 'I have sales data and I made charts' tells me the report probably sits on one wide imported table. That is not a crime for a first project, but it means the candidate has not met the problems that a proper model solves, such as double counting, slow visuals or measures that break when a filter changes.

Interviewer: Walk me through your model.

Candidate: (8 seconds) ... So, the model is ... I have
the sales data, and I made these charts. This one is
sales by region, this one is profit by month ...

Interviewer: How many tables are in the model?

Candidate: I think ... one? Maybe two.

Interviewer: Walk me through your model.

Candidate: It is a small star schema. The centre is a
Sales fact table with one row per order line: order ID,
date key, product key, store key, quantity and amount.

Around it there are four dimensions: Date, Product,
Store and Customer. Each joins to Sales one-to-many,
with filters flowing from the dimension to the fact.

All my numbers are DAX measures on the fact table,
so every chart uses the same logic.

The clear answer takes about twenty seconds and leaves nothing vague. It names the grain, the key columns, the dimension tables, the relationship type and where the logic lives. Any follow-up I ask now has a foundation to build on.

SECTION 02Grain, keys and relationships: the words that fill the gap

Most silences come from not having vocabulary ready. You may have built a decent model, but if you have never described it aloud, the words do not come under pressure. Three ideas cover most of what an interviewer needs.

Grain is what one row of a table represents. Keys are the columns that link tables, such as ProductKey. Relationships describe how filters travel: in a typical star schema, one product appears many times in sales, so the relationship is one-to-many from Product to Sales, and selecting a product category filters the sales rows. If you can explain those three for your own report, you can handle the core of any data model question. The SQL below is how I would build and check such a model before loading it into Power BI.

-- Dimension: one row per product
CREATE TABLE dim_product AS
SELECT DISTINCT
    product_id  AS product_key,
    product_name,
    category,
    sub_category
FROM raw_sales;

-- Fact: one row per order line
CREATE TABLE fact_sales AS
SELECT
    order_id,
    order_line,
    CAST(order_date AS DATE) AS date_key,
    product_id  AS product_key,
    store_id    AS store_key,
    quantity,
    quantity * unit_price AS sales_amount
FROM raw_sales;

-- 1. Dimension key must be unique (otherwise many-to-many)
SELECT product_key, COUNT(*) AS n
FROM dim_product
GROUP BY product_key
HAVING COUNT(*) > 1;

-- 2. Every fact row should find its product
SELECT COUNT(*) AS orphan_rows
FROM fact_sales f
LEFT JOIN dim_product p ON p.product_key = f.product_key
WHERE p.product_key IS NULL;

-- 3. Grain check: no duplicate order lines
SELECT order_id, order_line, COUNT(*)
FROM fact_sales
GROUP BY order_id, order_line
HAVING COUNT(*) > 1;

A detail worth noticing: if a product's name changed over time, SELECT DISTINCT on name and ID would return two rows for the same key. That is exactly the kind of problem the first check catches. Mentioning it in an interview shows you have actually fought with real data.

SECTION 03Explain one measure and the model stops sounding borrowed

After tables and relationships, the next follow-up is nearly always about a calculation. 'How did you calculate year-over-year growth?' or 'Why is this a measure and not a calculated column?' A candidate who designed the model answers these easily, because the measures are where the model earns its keep.

Pick one measure in your report that is slightly tricky, ideally one that uses CALCULATE or a time intelligence function, and learn to explain it line by line. Also learn the difference between a measure, which is calculated at query time in the filter context, and a calculated column, which is stored per row at refresh. Interviewers ask that question very often because it reveals whether you understand how filters flow through your model.

Total Sales = SUM ( fact_sales[sales_amount] )

Sales LY =
CALCULATE (
    [Total Sales],
    SAMEPERIODLASTYEAR ( dim_date[Date] )
)

Sales YoY % =
DIVIDE ( [Total Sales] - [Sales LY], [Sales LY] )

-- Requires dim_date to be a continuous date table,
-- marked as the date table, related to fact_sales[date_key].

"Total Sales is a simple SUM over the fact table.

Sales LY reuses Total Sales but CALCULATE changes the
date filter to the same period one year earlier, using
my Date dimension. That is why I needed a proper Date
table instead of the raw order date.

YoY % uses DIVIDE so it returns blank instead of an
error when there was no sale last year."

Notice that the explanation links the measure back to the model: the Date dimension exists because the time intelligence measure needs it. When your explanation of a measure mentions a table design choice, the interviewer hears a single connected system instead of separate tricks.

SECTION 04Prepare your data model answer before the interview

These three tabs turn your existing dashboard into a ready answer. Do them once for each report on your resume.

REPORT: ______________________

Fact table name: __________
One row per: ______________
Key columns: ______________
Numeric columns: __________

Dimensions (name -> key):
  1. ________ -> ________
  2. ________ -> ________
  3. ________ -> ________

Relationship types and direction: ________
One tricky measure: ________
One data problem I fixed: ________

WHITEBOARD DRILL (10 minutes)

1. Close the laptop.
2. On paper, draw the fact table in the middle.
3. Draw each dimension around it with its key.
4. Mark 1 and * on each relationship line.
5. Write two measures under the diagram.
6. Explain the drawing aloud in 60 seconds.

If you get stuck on any box, open the model view,
check it, and repeat the drill tomorrow.

Practise a 30-second answer for each:

- Why did you split the flat file into tables?
- What would break if Product had duplicate keys?
- When would you use a bidirectional filter?
- Measure or calculated column for profit margin?
- How would you add a Budget table at month level?
- How did you validate the report totals?
- What makes your model slow, and how would you fix it?

SECTION 05Habits that keep your data model answer flowing

These habits keep you speaking clearly when the model question arrives.

• Lead with the fact table — Always start with the central table and its grain. Everything else in the model hangs off that one sentence.
• Use real table names — Say 'fact_sales' and 'dim_product', not 'the main table'. Specific names sound like memory, not imagination.
• Mention one validation check — Say how you confirmed keys were unique or that totals matched the source. It shows care beyond building visuals.
• Separate model from visuals — Describe tables and measures first, and charts only after. Mixing them is the most common reason answers wander.
• Know when you broke the rules — If you used a bidirectional filter or a flat table on purpose, say why. A deliberate exception sounds like design.

SECTION 06Interview Q&A — Data model silence

SECTION 07Test yourself — Data model silence quiz

SECTION 08Frequently asked questions

SECTION 09Related reads