Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Identify priority journeys—analytics, operational sharing, ML, and regulatory reporting—and classify data risk. Define domain ownership, quality expectations, freshness, and what self-service must never permit.
Establish scale assumptions
- Inventory datasets, consumers, duplication, query cost, sensitive fields, and ownership gaps. Design for metadata and policy scale as well as storage and compute.
Functional and non-functional requirements
- Domains publish versioned data products with owners and SLOs; consumers discover, request, and use data through automated policy. Lineage, deletion, retention, and cost attribution are default capabilities.
High-level architecture
- Provide a catalog, contract registry, lineage graph, policy engine, access workflow, quality checks, standardized ingestion, isolated compute, and cost metering. Domains own meaning; platform owns safe mechanisms and shared metadata.
Data model and flow
- A data product declares schema, semantics, classification, owner, freshness, quality, retention, and allowed purposes. Pipelines propagate tags and lineage; policy grants time-bound access and records derived copies.
Consistency and transaction boundaries
- Contracts distinguish provisional streams from certified reporting snapshots. Breaking semantic changes create new versions, and consumers receive impact analysis through lineage before migration.
Failure modes and recovery
- Quality failures quarantine publication or mark data degraded rather than silently serving stale results. Shared control services have last-known-good policy, while compute failures are isolated by tenant and workload.
Security and privacy
- Use purpose-aware access, row and column controls, masking, encryption, and automated deletion propagation. Raw production access is an exception with owner, expiry, and audit.
Observability and SLOs
- Measure product freshness, quality, lineage completeness, access policy, orphaned data, deletion completion, cost by domain, and user task success. Adoption without trust is not success.
Capacity and cost
- Separate storage and compute, enforce quotas and workload classes, show unit cost to producers and consumers, and deduplicate high-cost copies. Chargeback is informative before it becomes punitive.
Alternatives and trade-offs
- Central ownership improves uniformity but cannot scale domain meaning; pure decentralization multiplies risk. Federate semantic ownership under centrally automated security, metadata, and lifecycle controls.
Evolution and migration
- Start with two high-value domains, establish contracts and ownership, migrate common access and policy, then block creation of unregistered sensitive stores. Retire legacy copies only after lineage and consumer cutover proof.
What Staff and Principal candidates should emphasize
- Distinguished candidates design a socio-technical marketplace of trusted data products. They align domain incentives, platform ergonomics, risk, cost, and enforceable lifecycle rather than building another warehouse.
Decision trade-offs
Ownership
Option A
Central data team owns every dataset
Option B
Domains own products under common platform policy
Recommendation:Federate semantic and quality ownership to domains while centralizing enforceable security, metadata, and lifecycle capabilities.
Access model
Option A
Broad warehouse access and social governance
Option B
Purpose-aware automated grants and protected views
Recommendation:Use automated least-privilege access so compliant self-service is faster than copying data outside the platform.
Follow-up interview questions
- 01Who owns a metric used by five business domains?
- 02How does deletion propagate through derived features?
- 03What happens when a certified dataset misses its freshness SLO?
- 04How do you stop teams from bypassing the platform?
Common weak answers and mistakes
- 01Equating self-service with broad read access to a warehouse.
- 02Centralizing semantic ownership in a team that lacks domain context.
- 03Building a catalog without enforceable policy, lineage, or quality.
- 04Using chargeback before costs and ownership are understandable.
Interviewer evaluation rubric
Proposes a warehouse and catalog but cannot establish ownership, policy, lineage, quality, or lifecycle.
Defines data products, domain owners, contracts, catalog, access workflow, quality checks, and cost visibility.
Adds purpose policy, deletion lineage, isolated workloads, certified states, impact analysis, and adoption incentives.
Creates a federated operating model where trustworthy sharing becomes the easiest path and platform economics remain accountable.