Event delegation means attaching one listener to a shared ancestor and using event.target to work out which descendant was interacted with. It works because most events bubble up from the target through its ancestors. Use it for lists that change often or are large, since you avoid attaching and cleaning up hundreds of listeners. Skip it for events that do not bubble, such as focus, blur and most media events.
Why interviewers ask this
It is a fast check on whether you understand capture and bubble phases rather than just calling addEventListener from memory. The interviewer is also probing memory hygiene: candidates who have debugged leaking listeners in a single page app know why delegation matters. The follow ups usually go toward events that do not bubble, stopPropagation misuse, and how frameworks implement their own synthetic delegation on top of this.
How to structure your answer
- Define it in one sentence using bubbling and event.target.
- Name the concrete win: fewer listeners, works for elements added later.
- Flag the exceptions, including events that do not bubble.
- Warn about stopPropagation breaking delegation upstream.
Example answer
Instead of putting a click listener on every row, I put one on the container and read event.target, then walk up with closest to find the row I care about. It works because the click bubbles from whatever was actually clicked up through its ancestors, so the container sees everything underneath it. The two wins are that I am not creating and tearing down hundreds of listeners, and rows added later just work with no rebinding. The catches are worth stating: focus and blur do not bubble, so I use focusin and focusout for those, and if any code between the target and my container calls stopPropagation my handler silently stops firing, which is a genuinely annoying bug to track down. I mostly hit this in a table where an inner component stopped propagation to close its own menu and quietly killed row selection. These days I usually get delegation for free from the framework, but I still use it directly for large virtualized lists and anything rendered outside the framework tree.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- Which common events do not bubble, and what do you use instead?
- How would you handle a click on a nested element inside the row?
- When is stopPropagation the right call rather than a smell?
Related frontend developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions