How would you track clicks on headlines and calls-to-action?
This tests DOM event handling and basic telemetry design. A strong answer covers event delegation with addEventListener, data attributes for element IDs, and a payload with timestamp and page context.
What's really being asked
This question probes whether you can apply basic DOM event patterns to a real product task. The interviewer wants to see that you understand event delegation, the event object, and how to design a minimal, privacy-conscious telemetry payload without resorting to anti-patterns that MDN and modern frameworks discourage.
The full answer
First, event delegation: place a single click listener on a common ancestor such as the main container or document body, rather than registering separate listeners on every headline and CTA. Second, the addEventListener API and the event object: inside the handler you read event.target or use element.closest to find the clicked component, then extract a stable identifier from a data attribute like data-track-id instead of fragile inner text. Third, payload design: capture timestamp, the element identifier, current page URL, a session or anonymous user token, and the event type; avoid collecting personally identifiable information. Fourth, transport: mention navigator.sendBeacon for reliable unload-time delivery, or a standard fetch to an analytics endpoint, and note that batching reduces network overhead.
The mistakes people make
Suggesting inline onclick attributes is a major red flag because MDN explicitly recommends against them in favor of addEventListener. Attaching unique listeners to dozens of elements shows poor performance intuition. Using element text or CSS class names as primary identifiers is brittle because copy and styling change frequently. Forgetting to mention the event object or failing to handle clicks on child elements nested inside a button are also gaps that signal shallow experience.
What usually comes next
An interviewer might ask how you would track dynamically injected content, which is where event delegation shines since new nodes do not need their own listeners. They might ask how you distinguish two buttons with identical labels, pushing you toward data attributes. They could also ask about Single Page Application navigation, privacy implications under GDPR, or how to prevent click spam by debouncing rapid repeated interactions.
A concrete example
Imagine a landing page with a hero headline and three signup buttons. You add one click listener to the article wrapper with addEventListener. When a user clicks any nested CTA, the handler calls event.target.closest with a selector for data-analytics-id, reads the value hero-cta-primary, and constructs a JSON payload containing ISO timestamp, id, page path, and a session UUID from a cookie. The data is sent via navigator.sendBeacon to an internal analytics API so the click is recorded even if the user immediately navigates away.
Interview question
Which approach best implements click tracking for dozens of headlines and CTAs while remaining performant and maintainable?
- a.Attach a unique addEventListener to each element and use its innerText as the analytics identifier
- b.Use a single delegated listener on a parent container, read data attributes to identify elements, and send via navigator.sendBeaconCorrect
- c.Re-attach individual listeners to all elements whenever new content is injected into the page
- d.Add inline onclick handlers to every element that submit CSS class names to the analytics endpoint
Why? this is the answer
Event delegation on a common ancestor avoids the performance cost of dozens of individual listeners and naturally handles dynamic content, while data attributes provide stable identifiers unlike brittle innerText or class names. The most tempting distractor, attaching unique listeners to every element, scales poorly and misses the efficiency and dynamic-content benefits that delegation provides.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles