← Back to System Internals

Reviewing for Privacy & Compliance

In ads infrastructure, the data is the product — and the privacy mistakes are the ones that make the news.

Privacy is the one review dimension where a single missed line can become a regulatory incident, a breach of user trust, or a headline. For an ads-events engineer this is not a specialist's concern — you handle user identifiers, ad interactions, and behavioral signals every day, so privacy review is core to the job. This question tests whether you review a diff for what data it touches, whether it's allowed to touch it, where that data flows, and how long it lives. The senior instinct is to treat every field as classified until proven otherwise, and to know the concrete controls — classification, purpose limitation, retention, access, encryption, and the cardinal rule of never logging PII or secrets.

What this question is really testing

Whether privacy is a reflex for you, not a checkbox you delegate to a review bot. The signal is that you notice when a diff introduces or moves personal data, ask the right questions about legal basis and lifecycle, and know the specific failure modes — PII in logs, an over-broad access grant, a missing retention TTL, plaintext at rest, using data for a purpose it wasn't collected for. It also tests that you understand privacy as a system property (lineage, deletion, audit), not just field-level hygiene.

How to answer

• Classify the data first. Before anything, ask: does this diff touch PII or sensitive data — user IDs, contact info, location, behavioral/interaction data? Data classification drives every other control. Anything unclassified that looks personal gets treated as sensitive until confirmed otherwise.
• Purpose limitation. Data collected for one purpose can't be silently repurposed. Check that the diff uses personal data only for the use it was collected and consented for — a new join or export that widens the purpose is a red flag.
• Retention. Personal data needs a defined lifetime and a deletion path. Look for a TTL, an expiry job, or a documented retention policy — data that lives forever by default is a violation waiting to happen, and it must honor deletion requests.
• Access control — least privilege. Who and what can read this data? Check for over-broad grants, a service reading more than it needs, or a new surface that exposes data to a wider audience than before. Default to least privilege.
• Encryption in transit and at rest. Personal data should move over TLS and sit encrypted at rest. Flag plaintext storage, an internal call that dropped to unencrypted, or secrets/keys handled without the proper store.
• Never log secrets or PII. The single most common catch: a debug log, an error message, an exception dump, or a metric label that emits a user identifier, token, or raw payload. Logs are broadly readable and long-lived — redact, hash, or omit. Same for crash reports and traces.
• Consent and legal basis (GDPR/CCPA). Confirm there's a lawful basis and, where required, consent for the processing — and that the code honors opt-outs and “do not sell/share” signals. A feature that ignores a consent flag is a compliance defect regardless of correctness.
• Data lineage and audit. Know where the data came from and where it flows, so deletion and access reviews are possible downstream. Sensitive operations should leave an audit trail — who accessed or exported what, when.

What the interviewer is looking for

• Privacy as a reflex — you spot personal data entering or moving in a diff without being prompted.
• The concrete controls named: classification, purpose limitation, retention, least privilege, encryption.
• The “never log PII/secrets” rule stated flatly, including logs, metrics labels, traces, and crash dumps.
• Awareness of consent/legal basis and honoring opt-outs, not just field hygiene.
• System-level thinking: lineage, deletion, and audit, so the whole lifecycle is compliant.

The most common privacy catch in review — PII leaking into a log line:

# WRONG: user email + raw token land in a broadly-readable, long-lived log
logger.info("processing user=%s token=%s payload=%s",
            user.email, auth_token, request.body)   # PII + secret in logs

# RIGHT: log a stable non-PII id, redact the secret, drop the raw payload
logger.info("processing user_hash=%s auth=redacted",
            hash_id(user.id))                         # queryable, no PII/secret

Common follow-ups

Where to get your data (Meta)

• Data classification / privacy framework — the tooling and policies that label fields and enforce purpose/retention, and the privacy-review process a diff must pass.
• Phabricator — a review where you caught PII in a log, an over-broad access grant, or a missing retention TTL.
• SEV / privacy incidents — an incident from a data-handling miss and the guardrail (lint rule, checklist) it produced.
• Data lineage tooling — to trace where personal data flows and confirm deletion/audit coverage.
• Internal wiki — the privacy/compliance review guidelines (GDPR/CCPA, consent, encryption) your org holds.

---