jQuery Interview Questions
Commonly asked jQuery interview questions with clear, practical answers.
A curated set of jQuery interview questions — common in screens for teams maintaining legacy codebases, and useful for understanding what jQuery actually solved.
Fundamentals
Q: What does $(document).ready() do, and why is it needed?
It delays running the code inside it until the browser has finished parsing the entire DOM, so scripts can safely select and manipulate elements that appear later in the HTML. Without it, a <script> placed in <head> (or anywhere before the elements it targets) would run before those elements exist, and any selector would simply return an empty result.
Q: What does $() actually return?
A jQuery object — an array-like wrapper around zero or more matched DOM elements — which is what exposes jQuery's methods (.text(), .on(), .css(), etc.) on the selection. It behaves like an array (.length, bracket indexing to get the raw DOM element) but isn't a true Array instance.
Q: What is method chaining in jQuery, and why does it work?
Chaining is calling multiple jQuery methods back-to-back in a single statement ($('#el').addClass('x').css('color', 'red')). It works because most jQuery methods return the same jQuery object they were called on (or a new one representing a transformed selection, like .find()), so the next method in the chain has something to operate on.
Events
Q: What is event delegation, and when is it necessary? Event delegation attaches a single handler to a stable ancestor element and lets events from matching descendants bubble up to it, rather than binding a handler to every individual descendant directly. It's necessary whenever elements are added to the page dynamically (after initial page load, e.g. via AJAX or user interaction) — a handler bound directly to an element that doesn't exist yet will never fire for it, while a delegated handler on an already-existing ancestor works for any matching descendant added later.
Q: What's the difference between .on('click', handler) and .on('click', '.selector', handler)?
The first attaches the handler directly to the matched element(s) at the moment it's called — it only affects elements that already exist. The second is delegated: the handler is attached to the outer element, but only actually runs when the event's target matches .selector, which correctly includes descendants added to the DOM afterward.
jQuery vs. modern JavaScript
Q: Is jQuery still worth learning or using today?
Its original purpose — papering over inconsistent, buggy cross-browser DOM and AJAX APIs — has largely been solved by modern browsers converging on standard APIs like querySelector, addEventListener, and fetch(). For a new project, native JavaScript (or a framework) is usually the better default. That said, an enormous amount of production code, especially legacy enterprise apps and WordPress sites, still runs on jQuery, so understanding it remains a practical, widely useful skill for maintaining existing systems.
Q: How does $.ajax() differ from the native fetch() API in error handling?
$.ajax()'s .fail() callback fires automatically for HTTP error responses (404, 500, etc.), treating them as failures. fetch() only rejects its promise on an actual network failure — a 404 or 500 response is still considered a "successful" fetch as far as the promise is concerned, and the code must explicitly check response.ok and throw an error itself to treat it as a failure.
Plugins & migration
Q: What two things does a jQuery plugin need to get right to behave like a real, built-in jQuery method?
It needs to return this (or return this.each(...)) so chaining still works after calling it, and it needs to handle a selection matching multiple elements correctly by wrapping its logic in .each() rather than assuming exactly one matched element. Missing either one still looks fine in casual testing against a single element, then breaks — chaining or the multi-element case — the moment real usage doesn't match that narrow assumption.
Q: Why wrap a jQuery plugin definition in an IIFE like (function ($) { ... }(jQuery));?
It guarantees $ refers to jQuery inside the plugin regardless of what the global $ has been reassigned to elsewhere on the page — a real risk on any page loading multiple older libraries that each expect to own the $ symbol. Passing jQuery in explicitly and naming the parameter $ scopes that assumption safely to just the plugin's own function body.
Q: When migrating jQuery's .on(event, selector, handler) delegation pattern to vanilla JavaScript, what has to be written manually that jQuery did for you?
Vanilla addEventListener has no concept of a delegated selector built in — the handler has to be attached once to the stable ancestor, and then check inside itself, using event.target.closest(selector), whether the actual element the event fired on matches the intended selector before acting. jQuery's delegated .on() performs exactly this check internally; migrating it means writing that closest() check out explicitly.