5 exercises — choose the best-structured answer to common Privacy Engineer interview questions. Focus on GDPR compliance, technical privacy mechanisms, and privacy-by-design.
Structure for privacy engineering interview answers
Name the legal basis: Article number and regulation (GDPR Art. 17, CCPA, HIPAA)
Identify the technical mechanism: anonymisation, pseudonymisation, tokenisation, differential privacy
Cover distributed complexity: data spans multiple services and regions; deletion must be complete
Include the audit trail: privacy actions must be logged for regulatory proof
0 / 5 completed
1 / 5
The interviewer asks: "Implement GDPR right to erasure in a distributed microservices system with an immutable event log. What are the challenges and how do you design around them?" Choose the most complete technical answer.
Option C is strongest: it enumerates all realistic data stores (not just the primary DB), provides two solutions for the immutable event log (crypto-shredding and tombstone events), addresses the GDPR backup archive carve-out, specifies the deletion receipt audit requirement, covers the 30-day SLA, and distinguishes erasure from consent withdrawal. Option B only addresses the event log and misses inventory, caches, ML datasets, backup, and audit requirements. Right to erasure design: data inventory → per-service deletion API → event log strategy (crypto-shredding) → backup carve-out → deletion receipt → SLA tracking.
2 / 5
The interviewer asks: "Design a consent management system for a B2C product that must comply with GDPR, CCPA, and PECR." Which answer covers the key design requirements?
Option A is strongest: it covers seven design dimensions with specifics — immutable audit log (critical for regulatory proof, often missed), purpose-level granularity (bundled consent is explicitly invalid under GDPR), jurisdiction detection at the edge, real-time enforcement via event bus, withdrawal parity per GDPR Art. 7, notice versioning, and proof-of-consent retention. Option C is mostly correct conceptually but lacks immutability, versioning, and downstream enforcement detail. Option D correctly names CMPs as practical tools but a design question expects architecture knowledge, not vendor naming. Consent system design: immutable store → purpose-level granularity → jurisdiction detection → real-time enforcement propagation → withdrawal parity → notice versioning → proof-of-consent retention.
3 / 5
The interviewer asks: "What is differential privacy and when would you use it in a production system?" Choose the most accurate and practically grounded answer.
Option D is strongest: it gives the formal privacy guarantee (probability bound, not just the e^ε formula in isolation), explains ε as a utility/privacy trade-off, names both noise mechanisms with use cases, provides three real production deployments (Apple, Google, US Census), details DP-SGD for ML training including its accuracy cost, and explicitly states when DP is NOT appropriate — a sign of senior judgment. Differential privacy: formal guarantee → ε trade-off → noise mechanism per query type → production use cases → DP-SGD for ML → when not to use.
4 / 5
The interviewer asks: "Walk me through conducting a DPIA for a new facial recognition feature in a physical access control system." Which answer demonstrates correct GDPR process and judgment?
Option B is strongest: it identifies why a DPIA is mandatory (three Art. 35 triggers), includes the necessity test (facial recognition must be necessary, not just convenient — a real regulatory trap), enumerates specific risks for this use case including demographic bias, provides concrete mitigations, and correctly identifies mandatory supervisory authority consultation under Art. 36. Option D covers the right topics but misses the necessity/proportionality test and doesn't enumerate the specific risks. DPIA structure: mandatory threshold check → processing description → necessity/proportionality test → risk enumeration by type → mitigations per risk → DPO consultation → supervisory authority consultation if residual risk high.
5 / 5
The interviewer asks: "What does 'privacy by design' mean in practice when building a new feature?" Which answer best operationalises the principle for an engineering team?
Option A is strongest: it operationalises the principle into seven concrete engineering-facing practices — LINDDUN threat modelling (a specific, testable framework), data minimisation as a design constraint (not just a principle), privacy-preserving defaults with the opt-in framing, purpose annotation at the schema level, pseudonymisation as a standard pipeline pattern, privacy in the definition of done (a process control), and data subject rights as a first-class design requirement. Options B and D are conceptually correct but lack the implementation specificity that senior interviewers expect. Privacy by design in practice: LINDDUN threat model → data minimisation-first design → privacy-preserving defaults → purpose annotation → pseudonymisation in pipelines → privacy in DoD → data subject rights from day one.