yoklainterview sim
ProgressHistory

Frontend Dom Browser Apis Interview Questions

75 verified Frontend Dom Browser Apis interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Dom Browser ApisDifficulty 1
What does document.getElementById('menu') return, compared with document.querySelector('#menu')?
  • agetElementById returns a NodeList containing every element whose id matches, while querySelector returns just the first element it happens to find in the document
  • bgetElementById searches by CSS selector, while querySelector can only search by an element's id
  • cBoth return the first matching element or null, but getElementById takes an id while querySelector takes any CSS selector✓
  • dgetElementById is deprecated in favour of querySelector, so new code should never use it any more
Explanation:getElementById looks up a single element by its id and returns that element or null; querySelector returns the first element matching any CSS selector (so '#menu' works too) or null. Neither returns a NodeList (a) — that is querySelectorAll. getElementById is not deprecated (d); it is perfectly idiomatic and slightly faster for plain id lookups.
Dom Browser ApisDifficulty 1
You need every element with class card on the page. Which call gives you all of them?
  • adocument.querySelectorAll('.card'), which returns a NodeList of all matching elements✓
  • bdocument.querySelector('.card'), which returns every element that has that class
  • cdocument.getElementById('.card'), which can select elements by their class name
  • ddocument.querySelectorAll('card'), dropping the dot so it matches the class attribute
Explanation:querySelectorAll returns a (static) NodeList of every element matching the selector; querySelector (b) stops at the first match only. The leading dot is required for a class (d) — without it 'card' matches <card> tags instead; and getElementById (c) accepts an id, not a class selector.
Dom Browser ApisDifficulty 2
Why is element.addEventListener('click', handler) generally preferred over setting an inline onclick attribute in the HTML?
  • aBecause an inline onclick cannot call handler functions that take any arguments
  • bBecause addEventListener can attach several independent handlers for the same event without overwriting each other✓
  • cBecause addEventListener runs its handler before the page loads, whereas onclick waits until afterwards
  • dBecause an inline onclick fires only in the capturing phase and never during bubbling
Explanation:addEventListener lets multiple listeners coexist for one event on one element, and it keeps behaviour out of the markup (separation of concerns). An inline onclick (or the .onclick property) holds a single handler, so assigning a new one replaces the old. Inline handlers can pass arguments (a), and both mechanisms fire in the bubbling phase by default (d).
Dom Browser ApisDifficulty 2
What is a practical difference between reading element.textContent and element.innerText?
  • atextContent returns the surrounding HTML tags as part of the string, while innerText conveniently strips every one of those tags out for you first
  • binnerText is always faster because reading it never triggers any layout work in the browser
  • cThey are exact synonyms — the browser computes and returns an identical string for both
  • dinnerText gives the rendered, visible text and skips hidden elements, while textContent returns every node's raw text✓
Explanation:innerText is layout-aware: it approximates what the user actually sees, so it ignores display:none text and reading it can force the browser to compute layout. textContent returns the concatenated text of every node, hidden or not, and is cheaper. Neither returns HTML tags (a) — getting the tag string is what innerHTML does.
Dom Browser ApisDifficulty 1
In the DOM event model, what does 'bubbling' mean when you click a button that is nested inside a <div>?
  • aThe click is handled on the outer <div> first, and only after that does it reach and fire on the button nested inside it
  • bAfter firing on the button, the same event travels up to its ancestors (the <div>, then further up)✓
  • cThe event fires only on the button itself and never reaches any ancestor element
  • dThe browser keeps firing the event on the button until some handler returns false
Explanation:Bubbling means the event is first handled on the actual target (the button) and then propagates upward through each ancestor, so a listener on the <div> runs too. Firing on the ancestor first (a) describes the earlier capturing phase, not bubbling. By default the event does reach ancestors, so (c) is wrong.
Dom Browser ApisDifficulty 3
<div id="outer">
  <button id="inner">Click</button>
</div>

outer.addEventListener('click', () => log('outer'), true);  // capture
inner.addEventListener('click', () => log('inner'));        // bubble

When the button is clicked, in what order do the handlers log?
  • ainner then outer, because the element that was actually clicked always runs its own handler before any of its ancestors do
  • bouter, then inner, then outer again, because it is registered in both phases
  • couter then inner, because the capturing listener on the ancestor runs before the target's bubbling listener✓
  • dOnly inner, because a capturing listener does not fire on an ordinary click
Explanation:The third argument true registers outer's listener for the capturing phase, which travels top-down before reaching the target — so outer logs first, then the event reaches inner. If outer had used the default (bubbling), the order would flip to inner then outer (a). outer is registered once, in one phase, so it fires once (b).

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview