How do you approach designing a data model that several teams will share, when each team defines a key metric like active customer differently?

What the interviewer is looking for

• This question tests sql & data modelling. Explains grain, keys and fact versus dimension tables clearly, and backs design choices with how the data will actually be queried.
• Strong answers: Documented shared definitions, a semantic or metrics layer, named owners, data contracts and a way to support legitimate variants.
• Likely follow-up: Who should have the final say on a disputed definition?

Another way it may be asked: Marketing and finance each count active customers their own way and both want it in the warehouse. How would you design for that?

A structure to follow: Answer, explain, example, limits

1. Step 1

   Answer

   Give your direct answer in the first sentence so the interviewer knows where you are going.

2. Step 2

   Explain

   Say how it works or why you would do it that way, in plain words before jargon.

3. Step 3

   Example

   Anchor it in something you have actually done or seen, with the detail that shows hands-on experience.

4. Step 4

   Limits

   Say when your approach would not be the right one. It shows judgement.

This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.

Common slips

• Reciting a definition without showing you have applied it.
• Using terms you cannot explain if asked a level deeper.
• Claiming experience beyond what you can discuss in detail.

How to practise it

Say the answer in 90 seconds, then answer the follow-up as if it were a new question.

Related questions

• Can you explain the difference between a fact table and a dimension table, and when you would use each?
• If you had to load a daily file from a partner into a warehouse, how would you make sure running the job twice doesn't create duplicate rows?
• What checks would you put on a new data source before analysts start relying on it?
• Tell me about a time a Spark or similar distributed job was slow or failing. How did you find the cause and what did you change?
• How do you structure dependencies and retries in an orchestration tool like Airflow or Dagster so that one failure doesn't cascade into a mess?

Browse all questions