Browser and DOM

When you click a child element, the event can move up to parents. Event delegation uses one parent listener to handle many children.

When you click a child element, the event can move up to parents. Event delegation uses one parent listener to handle many children. Easy picture: Instead of giving every student a separate bell, the class monitor listens once and checks which student raised a hand.

Instead of giving every student a separate bell, the class monitor listens once and checks which student raised a hand.

Interviewers often begin with a basic question to see whether you truly understand the concept instead of repeating memorized jargon.

target is origin. currentTarget is where the listener sits. Delegation reduces listener count. Check semantics and keyboard access too.

target is origin. currentTarget is where the listener sits. Delegation reduces listener count. Check semantics and keyboard access too.

Instead of giving every student a separate bell, the class monitor listens once and checks which student raised a hand.

This checks whether you can give a short, calm answer before the interviewer adds depth or follow-ups.

Events flow through capture, target, and bubble. Delegation means one parent listener handles many children. Use closest() to find the intended element. Pair click behavior with keyboard behavior.

Events flow through capture, target, and bubble. Delegation means one parent listener handles many children. Use closest() to find the intended element. Pair click behavior with keyboard behavior.

Instead of giving every student a separate bell, the class monitor listens once and checks which student raised a hand.

This checks whether you can give a clean interview answer without getting lost in too much detail.

Event delegation puts one listener on a parent and handles child interactions by checking the event target.

It uses bubbling so a stable parent can manage many dynamic child elements. It reduces listener count, works well for changing lists, and is common in practical DOM interactions like menus, tables, and autocomplete results.

list.addEventListener('click', (event) => { const target = event.target as HTMLElement; const item = target.closest('[data-item-id]');

This checks whether you can apply the concept in code and explain the reasoning, not only define it.

When you click a child element, the event can move up to parents. Event delegation uses one parent listener to handle many children.

The DOM supports capture, target, and bubbling phases. Most handlers run during bubbling. Event delegation attaches a single listener to a stable ancestor and checks event.target or closest() to handle child interactions efficiently. It reduces listener count and works well for dynamic lists or machine-coding rounds.

list.addEventListener('click', (event) => { const target = event.target as HTMLElement; const item = target.closest('[data-item-id]');

Mid-level rounds expect more than definitions. They want structured explanation, correct terminology, and practical judgment.

When you click a child element, the event can move up to parents. Event delegation uses one parent listener to handle many children. The main thing to avoid is: Confusing target with currentTarget.

The DOM supports capture, target, and bubbling phases. Most handlers run during bubbling. Event delegation attaches a single listener to a stable ancestor and checks event.target or closest() to handle child interactions efficiently. It reduces listener count and works well for dynamic lists or machine-coding rounds. Common pitfalls: Confusing target with currentTarget. Forgetting some events behave differently for bubbling. Ignoring keyboard support while handling clicks. Related areas to connect in follow-ups: HTML, CSS, and Accessibility Foundations, Machine Coding Round Approach.

list.addEventListener('click', (event) => { const target = event.target as HTMLElement; const item = target.closest('[data-item-id]');

Senior-leaning interviewers test whether you can move from definitions into tradeoffs, debugging, scale, and connected system thinking.

The browser reads HTML and CSS, calculates sizes and positions, paints pixels, and finally shows the page. If we force too much work on the main thread, the page feels slow or jumpy.

The browser reads HTML and CSS, calculates sizes and positions, paints pixels, and finally shows the page. If we force too much work on the main thread, the page feels slow or jumpy. Easy picture: It is like setting up a classroom: first read the seating plan, then place desks, then paint the labels, and only then let students enter. If you keep moving desks while painting, everything becomes messy and slow.

It is like setting up a classroom: first read the seating plan, then place desks, then paint the labels, and only then let students enter. If you keep moving desks while painting, everything becomes messy and slow.

Interviewers often begin with a basic question to see whether you truly understand the concept instead of repeating memorized jargon.

Parse, style, layout, paint, composite. Avoid layout thrashing. Measure first when animations feel janky. Main-thread time is UX time.

Parse, style, layout, paint, composite. Avoid layout thrashing. Measure first when animations feel janky. Main-thread time is UX time.

It is like setting up a classroom: first read the seating plan, then place desks, then paint the labels, and only then let students enter. If you keep moving desks while painting, everything becomes messy and slow.

This checks whether you can give a short, calm answer before the interviewer adds depth or follow-ups.

The browser parses markup and styles first. Layout decides sizes and positions. Paint and compositing draw the final result. Extra main-thread work directly hurts smoothness.

The browser parses markup and styles first. Layout decides sizes and positions. Paint and compositing draw the final result. Extra main-thread work directly hurts smoothness.

It is like setting up a classroom: first read the seating plan, then place desks, then paint the labels, and only then let students enter. If you keep moving desks while painting, everything becomes messy and slow.

This checks whether you can give a clean interview answer without getting lost in too much detail.

The browser parses HTML and CSS, builds structures for them, calculates layout, paints pixels, and composites layers to show the final screen.

A strong answer covers parsing, style calculation, layout, paint, and compositing. I also connect those stages to real frontend behavior: layout-sensitive reads can trigger extra work, frequent style changes can create jank, and heavy main-thread JavaScript delays rendering and interaction. Interviewers care more about whether you can connect the pipeline to actual performance decisions than whether you only recite the stage names.

const width = card.offsetWidth; card.style.width = width + 24 + 'px'; // Repeated layout reads and writes inside a loop can create layout thrashing.

This is a common interview question used to test clarity, correctness, and how calmly you explain fundamentals.

The browser reads HTML and CSS, calculates sizes and positions, paints pixels, and finally shows the page. If we force too much work on the main thread, the page feels slow or jumpy.

I explain browser work as parse, style calculation, layout, paint, and compositing. Performance problems often happen when JavaScript repeatedly reads layout-sensitive values and writes styles in a loop, causing extra reflow work. I connect that to main-thread availability, animation smoothness, and user-perceived responsiveness rather than only saying the pipeline names.

const width = card.offsetWidth; card.style.width = width + 24 + 'px'; // Repeated layout reads and writes inside a loop can create layout thrashing.

Mid-level rounds expect more than definitions. They want structured explanation, correct terminology, and practical judgment.

Layout thrashing happens when code repeatedly reads layout values and writes styles in a pattern that forces extra recalculation work.

This usually happens when JavaScript mixes layout reads like offsetWidth with style writes inside loops or repeated update cycles. The browser has to stop and recalculate layout more often than necessary. I avoid it by batching reads before writes, reducing DOM churn, using transform or opacity for animation when possible, and keeping expensive updates away from tight interaction loops.

const width = card.offsetWidth; card.style.width = width + 24 + 'px'; // Repeated layout reads and writes inside a loop can create layout thrashing.

This checks whether you can apply the concept in code and explain the reasoning, not only define it.

The browser reads HTML and CSS, calculates sizes and positions, paints pixels, and finally shows the page. If we force too much work on the main thread, the page feels slow or jumpy. The main thing to avoid is: Memorizing pipeline words without connecting them to user-visible lag.

I explain browser work as parse, style calculation, layout, paint, and compositing. Performance problems often happen when JavaScript repeatedly reads layout-sensitive values and writes styles in a loop, causing extra reflow work. I connect that to main-thread availability, animation smoothness, and user-perceived responsiveness rather than only saying the pipeline names. Common pitfalls: Memorizing pipeline words without connecting them to user-visible lag. Reading layout and writing styles repeatedly in tight loops. Assuming every animation should be JavaScript-driven. Related areas to connect in follow-ups: DOM Events and Event Delegation, Loading Strategy, Caching, and Core Web Vitals, React Performance Toolkit.

const width = card.offsetWidth; card.style.width = width + 24 + 'px'; // Repeated layout reads and writes inside a loop can create layout thrashing.

Senior-leaning interviewers test whether you can move from definitions into tradeoffs, debugging, scale, and connected system thinking.

Browsers can remember data in different places. Each option has a purpose, a size limit, and a security or lifetime tradeoff.

Browsers can remember data in different places. Each option has a purpose, a size limit, and a security or lifetime tradeoff. Easy picture: Think of browser storage like school storage spaces: a desk drawer for this class, a locker for your own items, and an office register for things that must travel with every form.

Think of browser storage like school storage spaces: a desk drawer for this class, a locker for your own items, and an office register for things that must travel with every form.

Interviewers often begin with a basic question to see whether you truly understand the concept instead of repeating memorized jargon.

localStorage is persistent but synchronous. sessionStorage is per-tab. Cookies travel with requests. Cache rules shape perceived speed.

localStorage is persistent but synchronous. sessionStorage is per-tab. Cookies travel with requests. Cache rules shape perceived speed.

Think of browser storage like school storage spaces: a desk drawer for this class, a locker for your own items, and an office register for things that must travel with every form.

This checks whether you can give a short, calm answer before the interviewer adds depth or follow-ups.

Choose storage by scope, lifetime, and security need. Cookies are request-aware, localStorage is not. Cache strategy matters for freshness and speed. Persistence and auth should not be mixed blindly.

Choose storage by scope, lifetime, and security need. Cookies are request-aware, localStorage is not. Cache strategy matters for freshness and speed. Persistence and auth should not be mixed blindly.

Think of browser storage like school storage spaces: a desk drawer for this class, a locker for your own items, and an office register for things that must travel with every form.

This checks whether you can give a clean interview answer without getting lost in too much detail.

localStorage is persistent and browser-side, sessionStorage is tab-scoped, and cookies are small values sent with matching HTTP requests.

I compare them by lifetime, scope, and request behavior. localStorage survives reloads and browser restarts but is synchronous and unsuitable for secrets. sessionStorage is scoped to one tab session. Cookies are smaller, can be sent automatically with requests, and matter when server communication or auth behavior is involved. A good answer also mentions that these tools solve different problems and should not be chosen only because they are familiar.

localStorage.setItem('theme', 'dark'); sessionStorage.setItem('draft-tab', 'billing'); document.cookie = 'locale=en; Path=/; Secure; SameSite=Lax';

This is a common interview question used to test clarity, correctness, and how calmly you explain fundamentals.

Browsers can remember data in different places. Each option has a purpose, a size limit, and a security or lifetime tradeoff.

I compare browser storage by scope, lifetime, and sensitivity. localStorage is easy but synchronous and inappropriate for sensitive secrets. sessionStorage is tab-scoped. Cookies are small, automatically sent with matching requests, and useful when server communication matters. I then connect this to caching headers, stale data, retry logic, and how frontend apps should avoid mixing persistence, cache, and auth concerns carelessly.

localStorage.setItem('theme', 'dark'); sessionStorage.setItem('draft-tab', 'billing'); document.cookie = 'locale=en; Path=/; Secure; SameSite=Lax';

Mid-level rounds expect more than definitions. They want structured explanation, correct terminology, and practical judgment.

Caching can make apps feel fast, but the UI must still handle old data, refresh timing, and clear signals about what is fresh or stale.

I separate static asset caching from API data freshness. Long-lived caching is great for hashed assets because the content changes with the filename. API data is different because the same endpoint can return updated information. Frontend design has to decide whether to revalidate in the background, show stale content while refreshing, or block until fresh data arrives. Interviewers want to hear that speed and correctness are both product decisions.

localStorage.setItem('theme', 'dark'); sessionStorage.setItem('draft-tab', 'billing'); document.cookie = 'locale=en; Path=/; Secure; SameSite=Lax';

This checks your decision-making, tradeoffs, and ability to discuss the bigger picture.

Browsers can remember data in different places. Each option has a purpose, a size limit, and a security or lifetime tradeoff. The main thing to avoid is: Using localStorage for sensitive auth data without understanding risk.

I compare browser storage by scope, lifetime, and sensitivity. localStorage is easy but synchronous and inappropriate for sensitive secrets. sessionStorage is tab-scoped. Cookies are small, automatically sent with matching requests, and useful when server communication matters. I then connect this to caching headers, stale data, retry logic, and how frontend apps should avoid mixing persistence, cache, and auth concerns carelessly. Common pitfalls: Using localStorage for sensitive auth data without understanding risk. Treating cookies and browser storage as interchangeable. Ignoring cache invalidation and stale data behavior. Related areas to connect in follow-ups: Frontend Security, Auth, and Trust Boundaries, Realtime Dashboards and Resilient Data Flow, Loading Strategy, Caching, and Core Web Vitals.

localStorage.setItem('theme', 'dark'); sessionStorage.setItem('draft-tab', 'billing'); document.cookie = 'locale=en; Path=/; Secure; SameSite=Lax';

Senior-leaning interviewers test whether you can move from definitions into tradeoffs, debugging, scale, and connected system thinking.