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
- Define identity resolution, deletion scope, legal holds, irreversible versus anonymized data, completion deadline, and what ‘deleted from backup’ means under policy. Separate user account closure from data erasure.
Establish scale assumptions
- Estimate requests, fan-out destinations, retained copies, restore frequency, and longest downstream SLA. The hard problem is coverage and proof, not request throughput.
Functional and non-functional requirements
- Resolve all subject identifiers, durably orchestrate deletion, prevent resurrection, honor exceptions, retry idempotently, and produce tenant-safe completion evidence without retaining deleted values.
High-level architecture
- Use a privacy control plane with a data-lineage registry, versioned deletion request, per-system adapters, tombstone registry, and evidence ledger. New datasets cannot onboard without deletion and retention contracts.
Data model and flow
- A request resolves subject keys, emits scoped commands, records adapter status, and verifies postconditions. Tombstones propagate to streams and restore workflows; derived systems recompute or remove affected artifacts.
Consistency and transaction boundaries
- Deletion is a long-running convergent workflow with monotonic states and idempotent commands. A global tombstone or key revocation prevents restored or delayed data from becoming visible before re-deletion.
Failure modes and recovery
- Retry failed adapters, escalate overdue owners, and keep partial completion visible. Backup restore must apply deletion tombstones or exclude revoked per-subject encryption keys before serving.
Security and privacy
- Strongly authenticate deletion requests, separate requester and approver for risky scopes, minimize evidence payload, and prevent enumeration through status APIs. Legal holds are explicit, scoped, and audited.
Observability and SLOs
- Track coverage, completion age, failed destinations, resurrected-record detections, restore compliance, and unregistered sensitive stores. Periodic synthetic subjects test deletion end to end.
Capacity and cost
- Per-subject encryption can enable cryptographic erasure but adds key and metadata cost. For immutable backups, combine retention expiry, access controls, and restore-time tombstone application.
Alternatives and trade-offs
- Immediate physical deletion everywhere may conflict with immutable backup design; cryptographic erasure and restore filtering can satisfy effective deletion when policy and auditors accept the evidence.
Evolution and migration
- Inventory systems, require new sink registration, centralize requests, and migrate high-risk stores first. Run shadow discovery to find copies before enforcing completion promises.
What Staff and Principal candidates should emphasize
- Staff candidates follow data lineage beyond databases and make restore-time behavior explicit. They distinguish legal exception, logical suppression, cryptographic erasure, and physical cleanup.
Decision trade-offs
Backup deletion
Option A
Rewrite immutable backups for each request
Option B
Expire backups and enforce tombstones or key erasure on restore
Recommendation:Use bounded retention plus restore-time suppression or cryptographic erasure when it meets policy; rewriting every backup is often riskier.
Evidence
Option A
Store deleted record values as proof
Option B
Store scoped identifiers, hashes, status, and policy basis
Recommendation:Retain minimal nonreconstructive evidence so proving deletion does not create a new prohibited copy.
Follow-up interview questions
- 01How do you prevent a delayed event from recreating the user?
- 02What happens when a backup is restored six months later?
- 03How do legal holds interact with deletion?
- 04How do you delete a user from a trained model?
Common weak answers and mistakes
- 01Deleting only primary rows and ignoring derived and operational copies.
- 02Claiming immutable backups make deletion impossible without a restore policy.
- 03Keeping personal payloads in the deletion audit as proof.
- 04Marking the request complete before every registered destination supplies evidence.
Interviewer evaluation rubric
Runs deletes against known databases but lacks lineage, idempotency, restore safety, and completion evidence.
Uses a durable workflow, adapters, tombstones, retries, legal-hold states, and minimal evidence.
Adds restore-time enforcement, derived-data handling, synthetic verification, sink onboarding policy, and resurrection detection.
Builds privacy lifecycle into platform architecture and reconciles legal, cryptographic, operational, and product semantics transparently.