Product design question

How would you design a data model to accommodate an Account Hierarchy?

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

Start a mock interview on this question · Mock interview from a job description

What this question tests

Technical product design for enterprise B2B software, checking whether you can reason about data modeling trade-offs like hierarchy depth, permissions, and real-world account relationships.

How to approach it

  1. Clarify the use case: parent-child account relationships common in life sciences and enterprise CRM, such as a global pharma company with regional subsidiaries.
  2. Identify the core requirement: users need to roll up data, like sales or activity, from child accounts to parent accounts while still managing them independently.
  3. Choose a data model approach: a self-referencing account table with a parent_account_id field, supporting arbitrary depth rather than a fixed number of hierarchy levels.
  4. Address permissions: users at a parent level may need visibility into child account data, but not vice versa, requiring role-based access tied to hierarchy position.
  5. Handle edge cases: accounts that move between parents over time, requiring a hierarchy history log rather than overwriting the relationship silently.
  6. Define success as accurate roll-up reporting performance at scale and correct permission enforcement across reorganizations.

What a strong answer includes

Common mistakes

Likely follow-up questions

More product design questions

More questions from Veeva

Learn the skill behind it

Chapters of the AI PM course that teach what this question tests.

Preparing for a specific role?

Book summaries for this kind of question

Browse all 4,000+ questions in the bank