Describe the technical steps for displaying and enforcing a cookie consent banner.

Tests privacy-first frontend architecture. Outline: check consent record, render banner if absent, classify scripts as essential or non-essential, persist choice, and inject tracking only after explicit opt-in.
WHAT THIS TESTS: This question tests whether you understand that GDPR and the ePrivacy Directive require active consent before non-essential cookies or tracking scripts execute. It is not enough to inform the user; the technical implementation must prevent data collection until consent is obtained. Interviewers want to see that you think in terms of gating execution rather than gating visibility.
A GOOD ANSWER COVERS: A good answer hits four things in order. First, on initial page load, the application checks for an existing consent record in a first-party cookie or localStorage. Second, if no record exists, the application renders a banner that blocks interaction or at least blocks script execution until the user makes a choice. Third, the answer must distinguish strictly necessary cookies, which can load immediately, from marketing or analytics cookies, which must wait. Fourth, after the user selects reject, the application persists that choice and ensures that third-party scripts are never injected into the DOM or executed by the browser.
COMMON WRONG ANSWERS: The most common wrong answer is suggesting that all scripts load on page startup and the banner merely hides or removes them afterward. This is a red flag because once a tracking script executes, the user has already been profiled, which violates GDPR. Another weak answer is storing consent in a way that is itself a third-party cookie or suggesting that session cookies are exempt from all rules. Some candidates also forget that the banner itself must not fire tracking pixels while it is asking for permission.
LIKELY FOLLOW-UPS: An interviewer might push on how you handle third-party iframes or social media embeds that set cookies. They may ask how you would implement this on a server-rendered site versus a single-page application. Another common follow-up is how to respect a do-not-track header or how to handle users who reject the banner without interacting. You might also be asked about consent revocation and how you would purge already-set cookies if a user changes their mind.
ONE CONCRETE EXAMPLE: Imagine a React application using Google Analytics and a Facebook pixel. On mount, the app reads a consent cookie. If the cookie is missing, it shows a modal and does not call ReactGA.initialize or inject the pixel script. If the user clicks Accept, the app writes a first-party consent cookie and then lazily initializes both trackers. If the user clicks Reject, the app writes a reject flag and those scripts remain absent from the page forever. The site still loads authentication or session cookies because those are strictly necessary, but no marketing or analytics network requests ever fire.
Source: GDPR.eu
Read the original → gdpr.eu
- #gdpr
- #cookie-consent
- #frontend
- #privacy
- #compliance
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.