You're building a feature that collects and stores users' personal data. What does GDPR require you to think about as the engineer, beyond just 'we have a privacy policy'?
technical-conceptual · Junior level · cloud-devops-security
What the interviewer is really asking
Assesses whether the candidate can translate GDPR principles into concrete engineering decisions — data minimization, purpose limitation, supporting data-subject rights, and privacy by design — rather than treating compliance as a legal-team document.
What to say
- Apply data minimization and purpose limitation: only collect the personal data you actually need for the stated purpose, and don't repurpose it later without a basis.
- Build for data-subject rights from the start: the design must let you find, export, and delete one person's data (access, portability, and right to erasure / 'right to be forgotten'), which is hard to bolt on later.
- Treat security and privacy by design as defaults: encrypt personal data, restrict access, set retention/deletion windows, and consider pseudonymization so the schema isn't a liability.
What to avoid
- Don't say compliance is purely the legal or privacy team's job — engineering choices about schema, logging, and retention directly determine whether the product can comply.
- Don't assume 'we'll just delete data if someone asks' works when erasure wasn't designed in — scattered copies in logs, backups, and caches make that nearly impossible after the fact.
- Don't collect personal data 'just in case it's useful later' — that violates minimization and purpose limitation and increases breach exposure.
Example answers
Strong: Beyond the privacy policy, GDPR pushes real engineering decisions. Data minimization means I only store the fields the feature needs — if we don't need a date of birth, we don't collect it. I'd design so we can honor data-subject rights: locate, export, and delete one user's data on request, including the right to erasure, which means thinking about where copies land in logs and backups. And I'd default to privacy by design: encrypt the personal fields, lock down access, and set a retention window so data doesn't live forever.
Weak: GDPR is mostly a legal thing, so the privacy team handles it. On the engineering side I'd just store whatever user data we collect normally and add a checkbox for the privacy policy. If someone wants their data deleted we can run a query and remove it when that comes up.