Practice answering Privacy Engineering interview questions in professional English. 5 exercises on GDPR, data minimisation, consent management, right to erasure, and Privacy by Design.
What separates good from great privacy engineering answers
Cite the article: "GDPR Article 17" beats "GDPR requires deletion"
Defence in depth: human vigilance fails at scale — give technical controls
Security vs privacy: security = right people; privacy = right people for right purpose
Name failure modes: exception logs, shadow tables, and PII creep are real offenders
0 / 5 completed
1 / 5
The interviewer asks: "What is data minimisation and how do you enforce it in a software system?" Which answer demonstrates the most practical depth?
Option B is the strongest: gives the exact legal reference (GDPR Article 5), names three concrete enforcement layers (schema, API boundary, collection point with a PII scrubber), adds the audit mechanism (column-level metadata tagging), calls out the common offenders (shadow tables, logs, exports), and ends with the most insightful point — PII creep during system evolution is harder to prevent than the initial design. Option A is legally aware but operationally vague. Option C is practical but focused only on deletion rather than prevention. Option D lists process activities (inventory, classification, PIAs) but none of the technical enforcement mechanisms.
2 / 5
The interviewer asks: "How do you design a consent management system that is both user-friendly and legally compliant?" Choose the strongest answer.
Option B is the strongest: names all four GDPR consent validity criteria with concrete interpretations (no consent walls, per purpose, plain language, opt-in not pre-ticked), explains the immutable audit log architecture with its specific fields and why overwriting a boolean is insufficient, describes the runtime consent API enforcement pattern, and addresses the UX challenge with a specific solution (progressive disclosure with sensible defaults). Option A is correct but shallow. Option C names a real tool (OneTrust) and records the right data but has no architecture or legal nuance. Option D is a checklist without depth on any dimension.
3 / 5
The interviewer asks: "What is the right to erasure under GDPR and what makes it technically difficult to implement?" Which answer shows the most engineering depth?
Option B is the strongest: cites the specific article (Article 17), explains the correct legal trigger (lawful basis no longer applies), enumerates four concrete technical difficulties (replication, relational integrity, immutable logs, third-party data), gives specific solutions for each (pseudonymisation in logs, per-store SLAs, documented erasure job, sub-processor requirement), and names the legal deadline for third parties (30 days). Option A correctly identifies the challenge but provides no solution. Option C describes the problem but has no technical depth. Option D mentions two techniques but misses relational integrity and third-party obligations.
4 / 5
The interviewer asks: "How do you prevent PII from leaking into application logs?" Choose the most robust technical answer.
Option B is the strongest: introduces defence in depth as the design principle, gives three layers (code, pipeline, audit), names specific mechanisms at each layer (@Redact annotation, PII scanner with regex and ML classifier, log data classification), and most importantly identifies the most dangerous failure mode — exception logging with raw request context — which is often the actual source of PII leaks in real systems. Option A relies on humans and fails at scale. Option C describes two of the three layers but has no detail on the exception logging risk. Option D lists activities (training, code review, CI scanning) but all at code level without the pipeline and audit layers.
5 / 5
The interviewer asks: "What is Privacy by Design and how do you embed it in a software development lifecycle?" Which answer is the most actionable?
Option B is the strongest: acknowledges the seven principles but immediately pivots to three practical SDLC controls — making it operational rather than theoretical. The DPIA-as-ticket-template insight shows process design maturity. The data flow diagram in the definition of done is concrete and auditable. The distinction between security and privacy (right people vs right purpose) is memorable and shows conceptual clarity. Option A is definitionally accurate but offers no action. Option C lists the correct activities but as a list without process integration insight. Option D mentions the seven principles but has no concrete SDLC integration mechanism.