You need to know where personal data lives before you can delete it, so start with classification and lineage. Prefer a design that avoids the problem: pseudonymize at ingestion and keep the identifier mapping in one restricted store, so deleting that mapping renders the rest non identifying. Where raw data must be deleted, use a table format supporting row level deletes and track the request to completion, including backups.
Why interviewers ask this
Deletion requests expose whether an architecture was designed with governance in mind or retrofitted. Interviewers want the crypto shredding or tokenization idea, because rewriting immutable Parquet across a lake is genuinely expensive. They also want honesty about the hard parts: backups, snapshots, downstream extracts, and third party tools that hold copies.
How to structure your answer
- Start with classification and lineage: you cannot delete what you cannot find.
- Prefer pseudonymization at ingestion so deletion is a single point operation.
- Explain row level deletes in modern table formats where raw deletion is required.
- Address backups, snapshots, and downstream copies explicitly.
- Track the request with evidence of completion.
Example answer
The honest first answer is that you cannot delete what you have not catalogued, so this depends entirely on classification and lineage being in place beforehand. The design I push for is pseudonymization at ingestion: the raw identifier is replaced with a surrogate token at the boundary and the mapping lives in one restricted store. Then a deletion request is mostly deleting one row in that store, after which everything downstream is no longer linked to a person. That is far cheaper than rewriting years of Parquet. Where actual deletion is required, a table format like Iceberg or Delta gives you row level deletes without rewriting entire partitions manually. The parts people forget are the awkward ones: snapshots and time travel history, backups with their own retention, CSV extracts someone emailed, and any third party analytics tool holding a copy. I would define the retention window for snapshots so deletions become permanent within it, document that, and keep an auditable record of each request and its completion.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What is crypto shredding and when is it a valid deletion strategy?
- How do time travel snapshots complicate deletion guarantees?
- How would you find personal data in an existing undocumented lake?
Related data engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions