Prompt and use cases
Would you offer tenant-level data portability export for a B2B SaaS? What would you export, how would you protect it, and how would you price it? This prompt fits product strategy, enterprise platforms, and privacy product interviews. Separate data portability, backup recovery, vendor migration, and internal export needs.
What interviewers assess
- Whether you distinguish end-user rights, tenant-admin needs, and a complete vendor migration.
- Whether you define structured formats, relationships, snapshots, incremental export, and exclusions.
- Whether authorization, sensitive fields, download links, rate limits, audit, and large-tenant cost are handled.
- Whether pilots and metrics show export is retention, compliance, or an expensive support service.
Questions to clarify before answering
Confirm whether the requester is a tenant administrator or an individual, and whether the purpose is migration, audit, backup, or a data-subject request. Clarify what the customer supplied, what the system inferred, and what includes other users or third-party rights. Ask about tenant size, peak export volume, format compatibility, incremental frequency, regions, encryption, and link lifetime. Finally, ask whether another system must import the result and who owns mapping and verification.
30-second answer framework
“I would validate migration and audit as high-value workflows and offer tiered export rather than a database mirror. The base tier provides stable machine-readable resources, relationships, and metadata, filtering sensitive or other-person data by authorization; large tenants use asynchronous sharding and short-lived encrypted links. I would measure completion, support time, post-export retention, and security incidents before pricing incremental APIs, managed migration, or long retention.”
Step-by-step deep answer
- Users and jobs: Separate personal portability, admin migration, audit evidence, and disaster recovery, with a success result for each.
- Scope and format: Publish a resource catalog, versions, relationship IDs, timestamps, and checksums with explicit format and compatibility commitments.
- Authorization and privacy: Verify tenant scope and admin rights before export, excluding other subjects, credentials, internal scores, and vendor secrets.
- Large-scale delivery: Queue jobs, shard output, support resumption, clean up expired data, and audit progress while limiting concurrency.
- Business and metrics: Make base export a trust capability; price incremental APIs, managed migration, and long retention by cost and value while monitoring completion and leakage risk.
High-quality sample answer
I would offer it, but define portability as structured, machine-readable, and explicitly scoped resources rather than a promise to copy the internal database. Data-protection guidance ties portability scope to data source, legal basis, and other people’s rights, so the product needs a clear scope statement. The first version would target tenant administrators and export a resource catalog, stable IDs, relationships, time range, versions, and checksums. Customer-supplied source data would be labeled separately from system-generated inferences. Before export, I would verify tenant scope and high-risk confirmation, excluding other users’ records, credentials, internal risk fields, and vendor secrets. Large tenants would use asynchronous jobs, shards, resumable downloads, and short-lived encrypted links; temporary files would be cleaned automatically and access audited. I would pilot with three customers that need migration or audits, comparing completion, support hours, post-export retention, and security incidents. If incremental APIs reduce repeated full exports, I would price them as an advanced capability; otherwise I would keep a stable offline format rather than market an expensive, unverifiable platform migration as portability.
Common mistakes
- Treating portability as every internal record or a complete database mirror.
- Ignoring the rights of other users, third parties, and vendor secrets.
- Offering one huge JSON download without versions, checksums, incremental semantics, or recovery.
- Creating links that never expire or letting export jobs starve online tenants.
- Pricing only by storage size without measuring migration success, support cost, and retention impact.
Follow-up questions and responses
What should not be exported?
Explicitly exclude credentials, internal risk scores, platform secrets, and other subjects’ data without authorization. For boundary fields, provide field-level explanations, redaction, or an admin-confirmed alternative.
What if permission is revoked during export?
Recheck the authorization version during shard generation and download. After revocation, pause unfinished shards, invalidate links, record the event, and handle already downloaded parts under the audit policy.
Should you offer an incremental API?
Only when customers need ongoing synchronization and accept version, deletion, and replay semantics. Pilot a stable snapshot and change cursor first, measuring duplicate-export reduction and maintenance cost.
How do you prevent export leakage?
Use least-privilege scope, short-lived encrypted links, tenant keys, download auditing, rate limits, and anomaly detection. Require dual approval or step-up verification for high-risk exports and provide revocation and cleanup.