Frontend Developer Interview Questions

Core Overview

Prepare for frontend developer interviews covering browser fundamentals, accessible interfaces, JavaScript and TypeScript, frontend architecture, performance, testing, and delivery.

Reviewed using official technical documentation.

Ready to test your knowledge?

Launch a focused practice session to review questions without distraction.

Show Practiced Only

beginnerBrowser & Web Fundamentals

What happens in a browser after a user enters a URL and navigates to a web page?

Direct Answer

The browser resolves the address, establishes a connection, sends an HTTP request, receives resources, builds document and style models, and renders the page.

Detailed Explanation

A browser navigation typically passes through several stages:

1. The browser parses the URL and determines the scheme, host, port, path, and other components.

2. It resolves the hostname to a network address, normally through DNS.

3. It establishes the required network connection and negotiates security for HTTPS.

4. It sends an HTTP request to the server.

5. The server returns an HTTP response containing status, headers, and content.

6. The browser parses HTML and creates the Document Object Model, or DOM.

7. Stylesheets are parsed into the CSS Object Model, or CSSOM.

8. The browser combines visible DOM content with computed styles to construct a render tree.

9. Layout determines the size and position of rendered elements.

10. Painting converts visual instructions into pixels.

11. Compositing combines painted layers for display.

Additional resources such as stylesheets, scripts, images, and fonts may be discovered while HTML is being parsed. Their priority and loading behavior can affect when useful content appears.

JavaScript can modify the DOM and styles after the initial render, causing the browser to repeat some rendering work.

Code Example

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1"
    />
    <link rel="stylesheet" href="/styles.css" />
    <script src="/app.js" defer></script>
    <title>Job Applications</title>
  </head>
  <body>
    <main>
      <h1>Job Applications</h1>
      <div id="application-list"></div>
    </main>
  </body>
</html>

Common Interview Pitfalls

Describing rendering as one immediate operation after HTML downloads.
Assuming the DOM contains only elements that are visually rendered.
Ignoring the effect of stylesheets, scripts, images, and fonts on rendering.
Confusing layout, paint, and compositing as identical browser operations.
Assuming every DOM update requires the browser to repeat every rendering stage.

Rate your confidence:

beginnerBrowser & Web Fundamentals

How do event capturing, targeting, bubbling, and event delegation work in the DOM?

Direct Answer

DOM events can travel through capture, target, and bubble phases. Event delegation uses propagation to handle many child interactions through a shared ancestor listener.

Detailed Explanation

When a propagating DOM event occurs, it can move through several phases:

Capturing phase: The event travels from the document hierarchy toward the target.

Target phase: The event reaches the element where it originated.

Bubbling phase: The event travels from the target back through its ancestors when the event supports bubbling.

Listeners use the bubbling phase by default. A listener can participate in capture by passing { capture: true } to addEventListener.

Event delegation places one listener on a shared ancestor instead of attaching a separate listener to every child. The handler inspects event.target or uses closest to determine which child initiated the interaction.

Delegation is useful for large or dynamically changing collections because newly inserted descendants can be handled without registering additional listeners.

event.target identifies the original target, while event.currentTarget identifies the element whose listener is currently executing.

stopPropagation stops further capture or bubble propagation. It does not cancel the element’s default browser behavior. preventDefault is used to request cancellation of a cancelable default action.

Code Example

const applicationList =
  document.querySelector<HTMLUListElement>(
    '#application-list'
  );

applicationList?.addEventListener('click', (event) => {
  const target = event.target;

  if (!(target instanceof Element)) {
    return;
  }

  const button = target.closest<HTMLButtonElement>(
    '[data-application-id]'
  );

  if (!button || !applicationList.contains(button)) {
    return;
  }

  const applicationId =
    button.dataset.applicationId;

  if (applicationId) {
    openApplication(applicationId);
  }
});

Common Interview Pitfalls

Assuming event.target and event.currentTarget always reference the same element.
Attaching an individual listener to every item when delegation is simpler.
Using stopPropagation without understanding effects on ancestor handlers.
Expecting stopPropagation to cancel a link or form default action.
Delegating events without confirming that the matched element belongs to the intended container.

Rate your confidence:

intermediateBrowser & Web Fundamentals

How does the browser event loop coordinate JavaScript tasks, microtasks, and rendering?

Direct Answer

The event loop runs a task, drains queued microtasks after the stack clears, allows rendering when appropriate, and then continues with another task.

Detailed Explanation

JavaScript execution in a browser uses an event-loop model. Synchronous code runs on the current call stack until that work completes.

Browser work is scheduled through different queues:

Tasks: Examples include timer callbacks, user interactions, and many browser events.

Microtasks: Examples include promise reaction callbacks and callbacks queued with queueMicrotask.

A simplified event-loop iteration is:

1. Select and execute one task.

2. Continue until the JavaScript call stack is empty.

3. Drain the microtask queue.

4. Allow rendering work when the browser determines it is appropriate.

5. Begin another event-loop iteration.

Microtasks can enqueue additional microtasks. The browser continues draining them before moving to the next task. An unbounded microtask chain can therefore delay user input, timers, and rendering.

setTimeout(callback, 0) does not execute the callback immediately. It schedules a future task after the timer becomes eligible and after previously queued work.

Promises do not automatically move expensive synchronous work to another thread. Code inside a promise callback still runs on the JavaScript execution thread unless work is explicitly moved to a worker or another environment.

Code Example

console.log('start');

setTimeout(() => {
  console.log('timer task');
}, 0);

Promise.resolve().then(() => {
  console.log('promise microtask');
});

queueMicrotask(() => {
  console.log('queued microtask');
});

console.log('end');

// Typical order:
// start
// end
// promise microtask
// queued microtask
// timer task

Common Interview Pitfalls

Assuming a zero-delay timer executes immediately.
Assuming promises run their callback code on a background thread.
Ignoring that microtasks are drained before the next queued task.
Creating recursive microtasks that prevent rendering and input handling.
Using long synchronous loops on the browser main thread.
Assuming all asynchronous callbacks use one identical queue.

Rate your confidence:

intermediateBrowser & Web Fundamentals

What is the same-origin policy, and how does CORS allow controlled cross-origin access?

Direct Answer

The same-origin policy restricts browser scripts from reading cross-origin resources. CORS uses server response headers to grant selected origins controlled access.

Detailed Explanation

An origin is generally defined by the combination of:

Scheme

Host

Port

The same-origin policy restricts how scripts loaded from one origin interact with resources from another origin. It helps prevent a malicious website from reading sensitive data from another site where the user may already be authenticated.

Cross-Origin Resource Sharing, or CORS, allows a server to relax selected browser restrictions by returning HTTP headers describing which origins, methods, and headers are permitted.

For some requests, the browser first sends a preflight OPTIONS request. The server must approve the proposed origin, method, and request headers before the browser sends the actual request.

Important points include:

CORS is enforced by browsers, not as a general server-to-server access-control system.

The server still needs authentication and authorization.

A successful network request can still produce a browser CORS error if the response does not authorize frontend access.

Credentialed requests cannot use a wildcard origin response.

The permitted origin should be derived from a controlled allowlist rather than reflecting any supplied origin automatically.

CORS is not a defense against cross-site request forgery by itself and does not replace server-side permission checks.

Code Example

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 600
Vary: Origin

Common Interview Pitfalls

Treating CORS as authentication or authorization.
Allowing every supplied Origin value without an approved allowlist.
Using a wildcard origin with credentialed browser requests.
Assuming a CORS error means the server never received the request.
Adding CORS headers only to successful responses and not relevant error responses.
Trying to solve a server-to-server permission problem through browser CORS configuration.

Rate your confidence:

intermediateBrowser & Web Fundamentals

How do cookies, localStorage, and sessionStorage differ, and what should each store?

Direct Answer

Cookies can accompany HTTP requests and support server sessions, localStorage persists origin-scoped strings, and sessionStorage is scoped to an origin and browser tab session.

Detailed Explanation

These browser storage mechanisms have different behavior and security characteristics.

Cookies

Are set through HTTP headers or browser APIs.

Can be sent automatically with matching HTTP requests.

Support attributes such as Secure, HttpOnly, SameSite, Path, and expiration.

Are commonly used for server-managed session identifiers.

localStorage

Stores string key-value data for an origin.

Persists after the browser window closes until cleared or evicted.

Is available to JavaScript running in the origin.

Uses synchronous APIs that can block the main thread during access.

sessionStorage

Stores string key-value data for an origin and browsing-context session.

Is generally isolated between browser tabs.

Is removed when the associated tab or browsing context ends.

Sensitive authentication material should not be placed casually into JavaScript-accessible storage because injected scripts running in the origin can read it.

An HttpOnly cookie cannot be read through ordinary frontend JavaScript, reducing direct token theft through injected scripts. However, cookie-based authentication still requires appropriate cross-site request protections and secure cookie attributes.

Code Example

HTTP/1.1 200 OK
Set-Cookie: session=opaque-session-id;
  Path=/;
  Secure;
  HttpOnly;
  SameSite=Lax;
  Max-Age=3600

<script>
  localStorage.setItem(
    'preferred-job-view',
    'kanban'
  );

  sessionStorage.setItem(
    'application-form-step',
    '2'
  );
</script>

Common Interview Pitfalls

Storing long-lived authentication secrets in JavaScript-accessible storage without a threat assessment.
Assuming localStorage data is automatically encrypted or private.
Using cookies without Secure, HttpOnly, or an appropriate SameSite policy.
Assuming sessionStorage is shared across all tabs from the same origin.
Storing large application datasets in synchronous Web Storage APIs.
Confusing browser persistence with guaranteed permanent storage.

Rate your confidence:

advancedBrowser & Web Fundamentals

How should a frontend engineer diagnose layout, paint, compositing, and main-thread rendering problems?

Direct Answer

Record a representative performance trace, identify long tasks and rendering work, determine which changes trigger layout or paint, then measure a focused fix.

Detailed Explanation

Browser rendering performance involves several categories of work:

JavaScript: Runs application and framework logic.

Style calculation: Determines which CSS rules apply and computes styles.

Layout: Calculates element geometry and position.

Paint: Draws visual details into pixels.

Composite: Combines previously painted layers for the final frame.

A change to element geometry may require style calculation, layout, paint, and compositing. A visual change that does not affect geometry may avoid layout but still require painting. Some changes, commonly involving transform or opacity, may be handled largely through compositing when the browser has appropriate layers.

A useful investigation process is:

1. Reproduce the slow interaction with representative content and hardware.

2. Record a browser performance profile.

3. Locate long main-thread tasks, repeated style calculation, layout, paint, and excessive scripting.

4. Determine which code or DOM mutation triggered the work.

5. Check whether code repeatedly reads layout information after writing styles.

6. Reduce DOM work, batch reads and writes, or select less expensive visual properties.

7. Measure the same interaction again.

A forced synchronous layout can happen when code changes styles and immediately reads geometry such as offsetWidth, forcing pending layout work to complete before JavaScript continues.

Creating many compositor layers is not automatically an optimization. Layers consume memory and require management, so promotion should be based on measured benefit.

Code Example

// Problematic pattern: repeated write then read.
for (const item of items) {
  item.style.width = `${targetWidth}px`;
  console.log(item.offsetWidth);
}

// Better: collect reads before writes.
const currentWidths = items.map(
  (item) => item.offsetWidth
);

requestAnimationFrame(() => {
  items.forEach((item, index) => {
    const width = Math.max(
      currentWidths[index],
      targetWidth
    );

    item.style.width = `${width}px`;
  });
});

Common Interview Pitfalls

Optimizing rendering without recording a representative performance trace.
Assuming every animation should be promoted to a separate compositor layer.
Alternating layout reads and style writes inside a loop.
Focusing only on JavaScript duration while ignoring layout and paint.
Testing only on a high-performance development machine.
Using requestAnimationFrame while still performing excessive work within each frame.
Assuming a high frame rate guarantees good input responsiveness.
Applying will-change broadly without measuring memory and compositing effects.

Rate your confidence:

beginnerHTML, CSS & Accessibility

Why is semantic HTML important, and how should a page be structured?

Direct Answer

Semantic HTML communicates the purpose and structure of content to browsers, assistive technologies, search tools, and developers while providing built-in behavior.

Detailed Explanation

Semantic HTML uses elements according to the meaning of their content rather than only their visual appearance.

Examples include:

<header> for introductory page or section content

<nav> for major navigation

<main> for the page’s primary content

<article> for independently meaningful content

<section> for a thematic section, usually with a heading

<aside> for complementary content

<footer> for closing or contextual information

<button> for an action

<a> for navigation to another location

Semantic elements provide useful information to accessibility APIs and often include native keyboard and interaction behavior. For example, a real button can receive keyboard focus and responds to expected activation keys without recreating those behaviors manually.

A page should normally have a logical heading structure and one primary <main> region. Headings should describe content hierarchy rather than being selected only for visual size.

Semantic HTML does not eliminate the need for CSS. The visual design can be changed while retaining the correct underlying element.

ARIA should not be added when native HTML already provides the required semantics and behavior. Replacing a native button with a clickable <div> generally creates extra work for focus, keyboard handling, roles, states, and disabled behavior.

Code Example

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Job Applications</title>
  </head>
  <body>
    <header>
      <a href="/">ResumeLoopAI</a>

      <nav aria-label="Primary">
        <a href="/jobs">Jobs</a>
        <a href="/applications">Applications</a>
      </nav>
    </header>

    <main>
      <h1>Job Applications</h1>

      <section aria-labelledby="active-heading">
        <h2 id="active-heading">
          Active applications
        </h2>

        <article>
          <h3>Frontend Developer</h3>
          <p>Example Company</p>
          <button type="button">
            View application
          </button>
        </article>
      </section>
    </main>

    <footer>
      <p>ResumeLoopAI</p>
    </footer>
  </body>
</html>

Common Interview Pitfalls

Using div and span elements for controls that already have native HTML equivalents.
Selecting heading levels only to obtain a desired font size.
Adding redundant ARIA roles to elements that already have equivalent semantics.
Using a link for an action that does not navigate to another location.
Creating several unrelated main landmarks on one ordinary page.
Using section elements without a meaningful thematic purpose or heading.

Rate your confidence:

beginnerHTML, CSS & Accessibility

How do the CSS box model, display modes, and positioning affect layout?

Direct Answer

The box model consists of content, padding, border, and margin. Display controls layout participation, while positioning changes how an element is placed.

Detailed Explanation

Every rendered CSS element is represented as one or more boxes.

The standard box model contains:

Content box: The area containing text, images, or child content.

Padding: Space between content and border.

Border: The visible or transparent boundary around padding and content.

Margin: Space outside the border that separates the element from others.

With the default box-sizing: content-box, declared width and height apply to the content box. Padding and border increase the final rendered dimensions.

With box-sizing: border-box, declared width and height include content, padding, and border. Many applications apply this model globally because component sizing becomes easier to reason about.

The display property controls how an element participates in layout. Common values include block, inline, inline-block, flex, grid, and none.

Positioning modes include:

Static: Normal document flow.

Relative: Remains in flow but may be visually offset and can establish a containing block.

Absolute: Removed from normal flow and positioned relative to an applicable containing block.

Fixed: Positioned relative to the viewport in typical cases.

Sticky: Behaves in flow until reaching a defined scroll threshold.

Removing an element from normal flow can cause overlap because surrounding content no longer reserves space for it.

Code Example

*,
*::before,
*::after {
  box-sizing: border-box;
}

.application-card {
  width: 100%;
  padding: 1rem;
  border: 1px solid #d8dee9;
  margin-block: 1rem;
  position: relative;
}

.application-card__badge {
  position: absolute;
  inset-block-start: 0.75rem;
  inset-inline-end: 0.75rem;
}

.application-toolbar {
  position: sticky;
  inset-block-start: 0;
  display: flex;
  gap: 0.75rem;
}

Common Interview Pitfalls

Forgetting that padding and borders increase dimensions under content-box sizing.
Using absolute positioning for an entire page layout.
Assuming a positioned element is always relative to its direct parent.
Using fixed positioning without considering small screens and zoom.
Removing content with display none when it must remain available to assistive technology.
Using large margins to compensate for a misunderstood layout model.

Rate your confidence:

intermediateHTML, CSS & Accessibility

When should a frontend developer use Flexbox instead of CSS Grid?

Direct Answer

Use Flexbox for primarily one-dimensional alignment and distribution. Use Grid when rows and columns must be coordinated as a two-dimensional layout.

Detailed Explanation

Flexbox and Grid are complementary CSS layout systems.

Flexbox is primarily one-dimensional. It arranges items along a main axis and manages alignment along a cross axis.

It is commonly useful for:

Navigation bars

Button groups

Toolbars

Vertically or horizontally aligned controls

Components whose items should grow, shrink, or wrap

CSS Grid is two-dimensional. It defines rows and columns together and allows items to occupy explicit grid areas.

It is commonly useful for:

Page-level layouts

Dashboards

Card collections with aligned columns

Forms requiring coordinated label and field alignment

Components with intentional row and column relationships

Flexbox can wrap items onto multiple lines, but each flex line is laid out independently. Grid maintains a shared column structure across rows.

The correct choice depends on the relationship being modeled, not on which technology is newer. Grid can contain Flexbox components, and Flexbox can contain Grid-based components.

Source order remains important for accessibility. Visual reordering through properties such as order or explicit grid placement may not change keyboard or screen-reader reading order. The DOM should normally follow the logical content sequence.

Code Example

.page-layout {
  display: grid;
  grid-template-columns:
    minmax(14rem, 18rem)
    minmax(0, 1fr);
  gap: 1.5rem;
}

.application-actions {
  display: flex;
  align-items: center;
  justify-content: flex-end;
  flex-wrap: wrap;
  gap: 0.75rem;
}

.application-grid {
  display: grid;
  grid-template-columns:
    repeat(
      auto-fit,
      minmax(min(100%, 18rem), 1fr)
    );
  gap: 1rem;
}

Common Interview Pitfalls

Choosing Flexbox for a layout requiring consistent row and column alignment.
Using Grid for a simple one-dimensional button or navigation group.
Changing visual order without considering keyboard and reading order.
Assigning fixed column widths that overflow narrow containers.
Using layout properties without allowing content to wrap or shrink.
Assuming Grid and Flexbox cannot be combined in the same interface.

Rate your confidence:

intermediateHTML, CSS & Accessibility

How do media queries and container queries differ in responsive design?

Direct Answer

Media queries respond to viewport or device conditions, while container queries style a component according to the size or properties of its containing element.

Detailed Explanation

Responsive design allows an interface to adapt to different viewport sizes, containers, input methods, text sizes, and user preferences.

Media queries evaluate characteristics of the viewport or output environment. Examples include width, orientation, color scheme, contrast preferences, and reduced-motion preferences.

They are useful for page-level changes such as:

Changing navigation presentation

Rearranging the main page layout

Adjusting global spacing

Respecting user motion or color preferences

Container queries allow a component to adapt based on the size or style of an ancestor established as a query container.

They are useful when one component appears in different contexts. A card might be placed in a narrow sidebar, a medium grid column, or a wide detail region even when the viewport itself is unchanged.

Responsive design should begin with flexible sizing and intrinsic layout where possible. Grid, Flexbox, wrapping, relative units, and functions such as min, max, and clamp can reduce the number of explicit breakpoints required.

Breakpoints should be introduced where the content or interaction stops working well rather than matching a list of specific devices.

Interfaces should also remain usable when users zoom, increase text size, or use narrow windows.

Code Example

.application-list {
  container-type: inline-size;
}

.application-card {
  display: grid;
  gap: 0.75rem;
  padding: clamp(1rem, 2vw, 1.5rem);
}

@container (min-width: 34rem) {
  .application-card {
    grid-template-columns: 1fr auto;
    align-items: center;
  }
}

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    scroll-behavior: auto;
    animation-duration: 0.01ms;
    animation-iteration-count: 1;
    transition-duration: 0.01ms;
  }
}

Common Interview Pitfalls

Creating breakpoints for named devices instead of responding to content needs.
Using viewport queries for components that appear in several container widths.
Disabling zoom through viewport metadata.
Using fixed pixel dimensions that cannot accommodate enlarged text.
Ignoring reduced-motion and other user preference media features.
Adding many breakpoints when flexible layout could solve the problem.

Rate your confidence:

intermediateHTML, CSS & Accessibility

How should a frontend developer implement keyboard navigation, form labels, focus, and ARIA correctly?

Direct Answer

Use native controls, provide visible accessible labels, preserve logical focus order, maintain visible focus, and add ARIA only when native HTML cannot express the component.

Detailed Explanation

Every interactive feature should be operable with a keyboard. Native HTML controls already implement many expected keyboard behaviors and should be preferred over custom elements.

Important practices include:

Use <button>, <a>, <input>, <select>, and other native controls appropriately.

Associate form fields with visible <label> elements.

Keep DOM order consistent with the logical navigation order.

Preserve a visible focus indicator.

Avoid positive tabindex values that create a separate manual focus order.

Move focus intentionally when opening or closing dialogs and similar composite interfaces.

Return focus to a sensible element when temporary UI closes.

Every focusable interactive element needs an accessible name. Visible text is generally the best source because it benefits all users and reduces the risk that the visual and accessible labels diverge.

ARIA can add roles, states, relationships, and accessible names when native HTML is insufficient. It does not automatically add interaction behavior. A custom ARIA widget still needs the correct keyboard handling, focus management, and state updates.

aria-label should not replace a useful visible label merely to simplify the layout. aria-labelledby can reference existing visible text when that text appropriately identifies the control.

Code Example

<form>
  <div>
    <label for="target-role">
      Target role
    </label>

    <input
      id="target-role"
      name="targetRole"
      type="text"
      aria-describedby="target-role-help"
    />

    <p id="target-role-help">
      Enter the title you are currently targeting.
    </p>
  </div>

  <button type="submit">
    Save profile
  </button>
</form>

Common Interview Pitfalls

Using placeholder text as the only label for a form control.
Removing focus outlines without providing a visible replacement.
Adding role button to a div without implementing keyboard activation.
Using positive tabindex values to manually rearrange focus order.
Giving a control an accessible name that differs substantially from its visible text.
Adding ARIA attributes that conflict with native HTML semantics.
Moving focus without restoring it when a temporary interface closes.

Rate your confidence:

advancedHTML, CSS & Accessibility

How would you design and audit a responsive interface for accessibility before production release?

Direct Answer

Begin with semantic HTML, test keyboard and assistive-technology behavior, verify responsive reflow and zoom, run automated checks, and manually validate critical user journeys.

Detailed Explanation

Accessibility should be built into component and product design rather than treated only as a final compliance scan.

A practical production audit includes several layers.

Structure and semantics

Verify page title, language, landmarks, headings, lists, tables, and form structure.

Prefer native elements before adding ARIA.

Confirm interactive elements expose correct names, roles, states, and descriptions.

Keyboard operation

Complete critical flows using only the keyboard.

Verify logical focus order and visible focus.

Confirm dialogs, menus, tabs, and other composite widgets follow expected keyboard patterns.

Ensure focus is not trapped or lost unexpectedly.

Responsive and visual behavior

Test narrow viewports, landscape orientation, browser zoom, and enlarged text.

Confirm content reflows without clipping or requiring unnecessary two-dimensional scrolling.

Check contrast, focus indicators, error states, and disabled states.

Respect reduced-motion and relevant user preferences.

Forms and errors

Verify persistent labels and clear instructions.

Associate errors programmatically with affected fields.

Move or announce focus appropriately after failed submission.

Avoid relying on color alone to communicate status.

Assistive technology

Test critical workflows with representative browser and screen-reader combinations.

Confirm dynamic updates are communicated only when necessary and without excessive announcements.

Automation and regression protection

Automated tools can find missing labels, invalid ARIA, contrast issues, and structural errors, but they cannot determine whether the full interaction is understandable or keyboard-efficient. Combine automated checks with manual testing and include accessibility assertions in component and end-to-end tests.

Common Interview Pitfalls

Relying exclusively on an automated accessibility score.
Testing only the homepage instead of critical user journeys.
Checking keyboard focus without verifying the activation behavior of controls.
Testing only one desktop viewport and default text size.
Adding ARIA to compensate for incorrect native HTML structure.
Using color as the only indication of errors or application status.
Announcing every dynamic update through an intrusive live region.
Treating accessibility defects as cosmetic issues that can always wait until after release.

Rate your confidence:

beginnerJavaScript & TypeScript

How do var, let, and const differ in scope, hoisting, and reassignment?

Direct Answer

var is function-scoped and initialized to undefined during setup, while let and const are block-scoped and unavailable before declaration due to the temporal dead zone.

Detailed Explanation

JavaScript provides var, let, and const for declaring bindings.

`var`

Is scoped to the nearest function or global scope.

Does not create a new binding for an ordinary block such as if or for.

Is processed before execution and initialized to undefined.

Can be redeclared in the same scope.

Can be reassigned.

`let`

Is scoped to the nearest block.

Cannot be accessed before its declaration is evaluated.

Can be reassigned.

Cannot be redeclared in the same scope.

`const`

Has the same block-scoping and temporal-dead-zone behavior as let.

Must be initialized when declared.

Cannot be reassigned to another value.

A const object is not automatically immutable. Its binding cannot reference a different object, but the object’s own properties may still be changed unless the design prevents mutation.

Prefer const when the binding will not be reassigned and let when reassignment is required. Modern frontend code generally avoids var because its function scope and redeclaration behavior can make control flow harder to reason about.

Code Example

function demonstrateScope() {
  if (true) {
    var functionScoped = 'available outside block';
    let blockScoped = 'available only inside block';
    const configuration = {
      theme: 'light'
    };

    configuration.theme = 'dark';
  }

  console.log(functionScoped);

  // ReferenceError:
  // console.log(blockScoped);
}

for (let index = 0; index < 3; index += 1) {
  setTimeout(() => {
    console.log(index);
  }, 0);
}

// Logs 0, 1, 2 because each iteration
// receives a separate block-scoped binding.

Common Interview Pitfalls

Assuming var is scoped to an if statement or loop block.
Describing let and const declarations as completely unhoisted.
Assuming a const object cannot have mutable properties.
Using var inside asynchronous loops and unintentionally sharing one binding.
Using let for every value even when reassignment is not required.
Accessing a block-scoped binding before its declaration.

Rate your confidence:

beginnerJavaScript & TypeScript

What is a JavaScript closure, and when is it useful in frontend development?

Direct Answer

A closure is a function together with access to bindings from its surrounding lexical scope, even after the outer function has finished executing.

Detailed Explanation

JavaScript uses lexical scope, meaning a function’s accessible variables are determined by where that function is defined in the source code.

A closure is created when a function retains access to bindings from an enclosing scope.

Closures are useful for:

Creating configured callback functions

Maintaining private implementation state

Building factory functions

Preserving state between event-handler calls

Implementing memoization

Associating data with asynchronous operations

The closure captures bindings, not frozen copies of primitive values. If the binding changes, later executions observe the current value.

Closures can also retain objects in memory. If a long-lived event listener closes over a large object or detached DOM subtree, that data may remain reachable longer than intended.

Closures should not automatically replace explicit objects, component state, or modules. They are one language mechanism for managing scope and lifetime.

Code Example

function createSearchHandler(
  delayMilliseconds: number,
  search: (query: string) => void
) {
  let timeoutId: number | undefined;

  return (query: string) => {
    if (timeoutId !== undefined) {
      window.clearTimeout(timeoutId);
    }

    timeoutId = window.setTimeout(() => {
      search(query);
    }, delayMilliseconds);
  };
}

const handleSearch = createSearchHandler(
  300,
  (query) => {
    console.log('Searching for', query);
  }
);

handleSearch('frontend developer');

Common Interview Pitfalls

Describing a closure as a copied snapshot of every outer variable.
Creating long-lived closures that retain large objects unnecessarily.
Using closures for hidden state when explicit application state would be clearer.
Assuming only nested named functions can create closures.
Expecting a closure to protect mutable state from every caller automatically.

Rate your confidence:

intermediateJavaScript & TypeScript

How do strict equality, loose equality, coercion, truthiness, and object comparison work in JavaScript?

Direct Answer

Strict equality avoids most implicit coercion, loose equality converts operands under defined rules, objects compare by identity, and truthiness does not imply Boolean equality.

Detailed Explanation

JavaScript has several comparison and conversion behaviors that can produce unexpected results.

Strict equality using === compares values without converting operands to a shared type in most cases.

Loose equality using == follows an abstract comparison algorithm that may convert values before comparing them. For example, the string "1" can compare loosely equal to the number 1.

Most application code should prefer strict equality because it makes the accepted types explicit. A deliberate loose comparison such as value == null is sometimes used to match both null and undefined, but the convention should be intentional and understood by the team.

Objects and arrays are compared by reference identity rather than structural content:

{ id: 1 } === { id: 1 } is false.

Two variables referencing the same object compare strictly equal.

Falsy values include false, 0, -0, 0n, an empty string, null, undefined, and NaN.

Fallback logic must distinguish missing values from valid falsy values. The logical OR operator uses truthiness, while nullish coalescing falls back only for null or undefined.

NaN is not equal to itself through ordinary equality. Number.isNaN is generally clearer when checking specifically for the numeric NaN value.

Code Example

const pageSizeFromApi = 0;

const incorrectDefault =
  pageSizeFromApi || 20;

const correctDefault =
  pageSizeFromApi ?? 20;

console.log(incorrectDefault); // 20
console.log(correctDefault);   // 0

const first = { id: 1 };
const second = { id: 1 };
const sameReference = first;

console.log(first === second);        // false
console.log(first === sameReference); // true

console.log(Number.isNaN(Number('invalid'))); // true

Common Interview Pitfalls

Using loose equality without understanding the conversion rules.
Assuming objects with identical properties compare equal by value.
Using logical OR defaults when zero or an empty string is valid.
Checking for NaN with an ordinary equality comparison.
Treating truthiness as equivalent to explicit Boolean state.
Confusing nullish values with every falsy JavaScript value.

Rate your confidence:

intermediateJavaScript & TypeScript

How should frontend code use promises and async or await while handling failures correctly?

Direct Answer

Await promises inside an intentional error boundary, preserve useful failure context, clean up in finally, and run independent operations concurrently rather than awaiting them sequentially.

Detailed Explanation

A promise represents the eventual completion or failure of an asynchronous operation.

An async function always returns a promise. Returning a value fulfills that promise, while throwing an error rejects it.

await pauses only the continuation of the current async function. It does not block the browser’s entire JavaScript environment.

Reliable async code should:

Await or return every promise whose result matters.

Catch errors at a level that can recover, add context, or update user-visible state.

Avoid catching errors only to ignore them.

Use finally for cleanup that must occur after success or failure.

Preserve cancellation and stale-request behavior where relevant.

Distinguish HTTP failures from network-level promise rejection.

The Fetch API normally fulfills its promise when an HTTP response is received, even for status codes such as 404 or 500. Code should inspect response.ok or response.status.

Independent async operations should often start together and be awaited with Promise.all. Sequentially awaiting independent requests increases total latency.

Promise.all rejects when one input rejects. Other operations may continue because rejecting the combined promise does not automatically cancel the underlying work.

Code Example

type Application = {
  id: string;
  company: string;
};

async function loadDashboard(
  signal: AbortSignal
): Promise<{
  applications: Application[];
  profileCompletion: number;
}> {
  const applicationsRequest = fetch(
    '/api/applications',
    { signal }
  );

  const profileRequest = fetch(
    '/api/profile/completion',
    { signal }
  );

  const [
    applicationsResponse,
    profileResponse
  ] = await Promise.all([
    applicationsRequest,
    profileRequest
  ]);

  if (!applicationsResponse.ok) {
    throw new Error(
      `Applications request failed: ${applicationsResponse.status}`
    );
  }

  if (!profileResponse.ok) {
    throw new Error(
      `Profile request failed: ${profileResponse.status}`
    );
  }

  const applications =
    await applicationsResponse.json() as Application[];

  const profile =
    await profileResponse.json() as {
      completion: number;
    };

  return {
    applications,
    profileCompletion: profile.completion
  };
}

Common Interview Pitfalls

Starting a promise without awaiting, returning, or intentionally handling it.
Assuming fetch rejects its promise for every non-success HTTP status.
Catching an error and silently discarding the failure.
Awaiting independent requests sequentially and increasing latency.
Assuming Promise.all cancels remaining operations after one rejects.
Updating component state after an obsolete request completes.
Wrapping every async function in try and catch without a recovery strategy.

Rate your confidence:

intermediateJavaScript & TypeScript

How do TypeScript unions, narrowing, generics, and unknown improve type safety?

Direct Answer

Unions describe alternatives, narrowing proves which alternative is present, generics preserve relationships between types, and unknown requires validation before use.

Detailed Explanation

TypeScript’s type system can describe uncertainty without immediately discarding safety.

A union type represents a value that may be one of several types. Code must narrow the union before using members that are not shared by every alternative.

Narrowing can use:

typeof

instanceof

Equality checks

The in operator

Discriminant properties

User-defined type predicates

Control-flow analysis

A discriminated union gives each alternative a stable literal field such as status or kind. An exhaustive switch can then ensure all cases are handled.

A generic expresses a relationship between input and output types. For example, a function that returns the first item from an array should preserve the array element type rather than returning any.

unknown is appropriate for values whose type has not yet been established, such as parsed JSON, caught errors, or external messages. Unlike any, it cannot be used freely until the code narrows or validates it.

Types disappear at runtime. A TypeScript interface does not validate network data by itself. Data crossing a runtime boundary still needs parsing and validation.

Code Example

type RequestState<T> =
  | {
      status: 'idle';
    }
  | {
      status: 'loading';
    }
  | {
      status: 'success';
      data: T;
    }
  | {
      status: 'error';
      message: string;
    };

function renderState<T>(
  state: RequestState<T>
): string {
  switch (state.status) {
    case 'idle':
      return 'Ready';
    case 'loading':
      return 'Loading';
    case 'success':
      return JSON.stringify(state.data);
    case 'error':
      return state.message;
    default: {
      const unreachable: never = state;
      return unreachable;
    }
  }
}

function isErrorWithMessage(
  value: unknown
): value is { message: string } {
  return (
    typeof value === 'object' &&
    value !== null &&
    'message' in value &&
    typeof value.message === 'string'
  );
}

Common Interview Pitfalls

Using any for unvalidated external data and bypassing type safety.
Using a generic parameter that does not relate two meaningful types.
Asserting a type instead of proving or validating it.
Creating unions without a reliable discriminant property.
Assuming TypeScript interfaces validate JSON at runtime.
Handling caught errors as Error without checking their actual type.
Adding a default switch branch that hides an unhandled union member.

Rate your confidence:

advancedJavaScript & TypeScript

How would you design a safe TypeScript data flow for asynchronous API requests and changing UI state?

Direct Answer

Validate unknown responses, model request states explicitly, cancel or ignore stale work, separate transport and domain types, and make every failure and empty state intentional.

Detailed Explanation

A safe frontend data flow should account for runtime uncertainty, concurrency, cancellation, stale responses, and user-visible states.

A robust design includes several boundaries.

Transport boundary

Treat API response data as unknown until runtime validation succeeds. HTTP success does not guarantee that the body matches the expected schema.

Type separation

Transport data may use nullable fields, wire-format dates, or provider-specific names. Convert it into an internal domain or view model after validation.

Explicit request states

Represent idle, loading, success, empty, and failure states deliberately. Avoid combinations such as isLoading, data, and error that can accidentally describe contradictory states.

Concurrency control

When inputs change quickly, an older request may finish after a newer request. Cancel obsolete work with AbortController, associate requests with identifiers, or ignore responses that no longer match the active request.

Error boundaries

Keep low-level diagnostic information for logging while translating failures into safe and actionable UI messages.

State ownership

Place server-derived state, temporary form state, URL state, and long-lived client state in appropriate layers rather than one global store.

Testing

Test success, malformed responses, empty results, cancellation, retry behavior, slow responses, and out-of-order completion.

Static types reduce development mistakes, but runtime validation and concurrency rules are still required because the browser receives untyped data from external systems.

Code Example

type Job = {
  id: string;
  title: string;
  company: string;
};

type LoadState =
  | { status: 'idle' }
  | { status: 'loading'; requestId: number }
  | {
      status: 'success';
      requestId: number;
      jobs: Job[];
    }
  | {
      status: 'error';
      requestId: number;
      message: string;
    };

function parseJobs(value: unknown): Job[] {
  if (!Array.isArray(value)) {
    throw new Error('Expected an array');
  }

  return value.map((item) => {
    if (
      typeof item !== 'object' ||
      item === null ||
      !('id' in item) ||
      !('title' in item) ||
      !('company' in item) ||
      typeof item.id !== 'string' ||
      typeof item.title !== 'string' ||
      typeof item.company !== 'string'
    ) {
      throw new Error('Invalid job response');
    }

    return {
      id: item.id,
      title: item.title,
      company: item.company
    };
  });
}

async function loadJobs(
  query: string,
  requestId: number,
  signal: AbortSignal
): Promise<LoadState> {
  try {
    const response = await fetch(
      `/api/jobs?query=${encodeURIComponent(query)}`,
      { signal }
    );

    if (!response.ok) {
      throw new Error(
        `Request failed: ${response.status}`
      );
    }

    const body: unknown = await response.json();
    const jobs = parseJobs(body);

    return {
      status: 'success',
      requestId,
      jobs
    };
  } catch (error: unknown) {
    if (
      error instanceof DOMException &&
      error.name === 'AbortError'
    ) {
      throw error;
    }

    return {
      status: 'error',
      requestId,
      message: 'Unable to load jobs.'
    };
  }
}

Common Interview Pitfalls

Casting network JSON directly to the desired interface without validation.
Allowing older requests to overwrite results from newer requests.
Representing loading, data, and error through contradictory Boolean combinations.
Displaying raw server or exception messages directly to users.
Treating cancellation as an ordinary user-visible request failure.
Using one global state store for every temporary and server-derived value.
Ignoring empty results as a distinct user-interface state.
Assuming compile-time types protect data received at runtime.

Rate your confidence:

beginnerFrontend Architecture & State

What is the difference between local state and derived state in a frontend component?

Direct Answer

Local state stores information that changes through interaction, while derived values should usually be calculated from existing props or state instead of stored separately.

Detailed Explanation

Component state should contain the smallest set of information required to represent the user interface over time.

Local state belongs to one component or a small component subtree. Examples include:

Whether a menu is open

The current value of an unsaved input

Which tab is selected

Whether a temporary dialog is visible

Derived state can be calculated from existing props, state, or other already available values. Examples include:

A filtered list calculated from items and a search term

A total calculated from line items

Whether a form is complete based on its fields

A display label calculated from a status value

Storing a derived value separately creates multiple sources of truth. If the original data changes but the copied value does not, the interface becomes inconsistent.

Derivation does not mean every calculation must be repeated without consideration. Expensive calculations may be memoized when measurement shows a benefit, but memoization is an optimization rather than a second authoritative state source.

State should also avoid contradictory combinations. Instead of separate Boolean values such as isLoading, hasError, and isComplete, a discriminated state model can represent only valid states.

Code Example

type Application = {
  id: string;
  company: string;
  status: 'saved' | 'applied' | 'interview';
};

function ApplicationList({
  applications
}: {
  applications: Application[];
}) {
  const [query, setQuery] = useState('');

  const visibleApplications =
    applications.filter((application) =>
      application.company
        .toLowerCase()
        .includes(query.toLowerCase())
    );

  return (
    <>
      <label>
        Search companies
        <input
          value={query}
          onChange={(event) =>
            setQuery(event.target.value)
          }
        />
      </label>

      <p>
        {visibleApplications.length} matches
      </p>
    </>
  );
}

Common Interview Pitfalls

Copying props into state without a clear synchronization requirement.
Storing totals, filtered lists, or labels that can be calculated during rendering.
Using several Boolean fields that can describe contradictory states.
Moving temporary component state into a global store unnecessarily.
Using memoization as a substitute for choosing a correct state model.

Rate your confidence:

beginnerFrontend Architecture & State

How do props, composition, and component boundaries help structure a frontend application?

Direct Answer

Props define explicit component inputs, composition assembles behavior without inheritance, and effective boundaries group cohesive UI responsibilities behind stable interfaces.

Detailed Explanation

A frontend component should expose a clear and understandable interface through its props.

Good component boundaries often have:

One coherent responsibility

A name that describes a user-interface concept

Explicit inputs and callbacks

Limited knowledge of surrounding page structure

A testable observable contract

Composition means assembling larger interfaces from smaller components. A component can receive child content, render callbacks, or specialized subcomponents without inheriting from another component.

For example, a reusable dialog can own focus and dismissal behavior while receiving its title, body, and actions from the parent.

A component should not be extracted merely because a file has reached an arbitrary line count. Extraction is valuable when it creates a meaningful concept, isolates changing behavior, improves reuse, or reduces the context required to understand the parent.

Prop drilling is not automatically a defect. Passing a small number of explicit props through a limited hierarchy can make dependencies easier to understand than hiding them inside global context.

Components should avoid depending on oversized configuration objects when a smaller, purpose-specific interface would communicate their contract more clearly.

Code Example

type ConfirmationDialogProps = {
  title: string;
  children: React.ReactNode;
  confirmLabel: string;
  onConfirm: () => void;
  onCancel: () => void;
};

function ConfirmationDialog({
  title,
  children,
  confirmLabel,
  onConfirm,
  onCancel
}: ConfirmationDialogProps) {
  return (
    <Dialog title={title} onDismiss={onCancel}>
      <div>{children}</div>

      <DialogActions>
        <button type="button" onClick={onCancel}>
          Cancel
        </button>

        <button type="button" onClick={onConfirm}>
          {confirmLabel}
        </button>
      </DialogActions>
    </Dialog>
  );
}

Common Interview Pitfalls

Creating components that expose many unrelated configuration flags.
Extracting tiny components that do not represent a meaningful concept.
Passing an entire page model when a component needs only two fields.
Using global context to avoid every instance of prop passing.
Combining data fetching, page orchestration, and low-level presentation in every component.
Creating boolean props that produce numerous unclear component modes.

Rate your confidence:

intermediateFrontend Architecture & State

What is the difference between client state and server state in a frontend application?

Direct Answer

Client state is owned by the browser interface, while server state is remotely owned data that must be fetched, cached, synchronized, invalidated, and updated.

Detailed Explanation

Client state originates in and is primarily controlled by the frontend application. Examples include:

Whether a drawer is open

The selected table view

Unsaved form input

A temporary wizard step

A local theme preference

Server state is authoritative outside the browser. Examples include:

User records

Job applications

Subscription status

Search results

Notification counts

Server state has additional concerns:

It may become stale.

Several users or systems may modify it.

Fetching can fail or be delayed.

Cached data needs invalidation rules.

Mutations may require optimistic updates or rollback.

Multiple components may request the same resource.

Copying server data into a general client store without a synchronization strategy can create competing caches and inconsistent values.

Outer libraries can manage query keys, loading and error status, caching, deduplication, background refresh, invalidation, retries, and mutation lifecycle. This does not mean every API request needs a specialized library, but the application should avoid repeatedly rebuilding those behaviors inconsistently.

URL state forms another useful category. Search terms, filters, selected tabs, and pagination may belong in the URL when they should be shareable, bookmarkable, or preserved through navigation.

Code Example

function ApplicationsPage() {
  const [view, setView] =
    useState<'list' | 'kanban'>('list');

  const applicationsQuery = useQuery({
    queryKey: ['applications'],
    queryFn: fetchApplications
  });

  if (applicationsQuery.isPending) {
    return <LoadingState />;
  }

  if (applicationsQuery.isError) {
    return <ErrorState />;
  }

  return (
    <ApplicationView
      applications={applicationsQuery.data}
      view={view}
      onViewChange={setView}
    />
  );
}

Common Interview Pitfalls

Treating fetched server data exactly like permanent local component state.
Creating several independent caches for the same server resource.
Refetching data in every component without stable query identity.
Keeping shareable filters only in memory instead of considering URL state.
Using a global client store for temporary state owned by one component.
Applying optimistic updates without rollback or reconciliation behavior.

Rate your confidence:

intermediateFrontend Architecture & State

Why should relational frontend state sometimes be normalized, and how does normalization reduce duplication?

Direct Answer

Normalized state stores each entity once by identifier and represents relationships with IDs, simplifying updates and preventing inconsistent duplicated copies.

Detailed Explanation

Frontend data is sometimes returned as deeply nested structures. If the same entity appears in several branches, updating it consistently can become difficult.

A normalized representation treats part of frontend state like database tables:

Each entity type has its own collection.

Entities are indexed by stable identifier.

Relationships store identifiers rather than full duplicate objects.

Separate arrays can preserve ordering.

For example, if the same company appears in several job applications, storing one company record and referencing its ID avoids updating several copies when the company name changes.

Normalization can provide:

One authoritative copy of each entity

Simpler lookup and updates

Shallower immutable changes

Reduced accidental rerendering from deep object replacement

Clearer relationships between records

Normalization is not necessary for every state object. Small, local, non-relational state is often clearer in its natural nested shape.

Normalized state also requires selectors or view-model functions to assemble entities for rendering. These functions should centralize knowledge of the state shape so components do not repeatedly reconstruct relationships manually.

Code Example

type ApplicationState = {
  applications: {
    byId: Record<string, {
      id: string;
      companyId: string;
      role: string;
    }>;
    allIds: string[];
  };
  companies: {
    byId: Record<string, {
      id: string;
      name: string;
    }>;
  };
};

function selectApplicationCard(
  state: ApplicationState,
  applicationId: string
) {
  const application =
    state.applications.byId[applicationId];

  const company =
    state.companies.byId[application.companyId];

  return {
    id: application.id,
    role: application.role,
    companyName: company.name
  };
}

Common Interview Pitfalls

Storing several complete copies of the same entity in different state branches.
Normalizing small local state that has no meaningful relationships.
Updating nested entities by mutating existing objects directly.
Allowing components to depend on every detail of the normalized state shape.
Using unstable array positions instead of persistent entity identifiers.
Normalizing data without defining selectors that reconstruct useful view models.

Rate your confidence:

intermediateFrontend Architecture & State

When should state use component state, context, a reducer, or a global store?

Direct Answer

Keep state near its consumers, use context for broadly needed stable dependencies, reducers for coordinated transitions, and global stores for genuinely application-wide state.

Detailed Explanation

State placement should begin with ownership rather than a preferred library.

A useful progression is:

1. Keep state in the component that owns the interaction.

2. Lift it to the nearest common parent when siblings must coordinate.

3. Use composition or explicit props when dependencies remain understandable.

4. Use context when information is needed deeply across one subtree.

5. Use a reducer when several related transitions require centralized logic.

6. Use a global store when state is truly shared across distant application areas and has a clear lifecycle.

Context is well suited to values such as theme, locale, authenticated-user information, feature configuration, or a screen-specific state controller.

Context is not automatically a complete state-management architecture. When a provider value changes, consumers reading that context may rerender. Large frequently changing objects in one context can therefore create broad coupling and performance problems.

Reducers make state transitions explicit through actions and consolidate update logic. They are useful when several events modify related state or when direct setters make valid transitions difficult to understand.

A global store should be organized around domain or feature ownership rather than becoming one container for every temporary input, API response, and modal state.

Code Example

type FilterState = {
  status: 'all' | 'saved' | 'applied';
  query: string;
};

type FilterAction =
  | {
      type: 'statusChanged';
      status: FilterState['status'];
    }
  | {
      type: 'queryChanged';
      query: string;
    }
  | {
      type: 'cleared';
    };

function filterReducer(
  state: FilterState,
  action: FilterAction
): FilterState {
  switch (action.type) {
    case 'statusChanged':
      return {
        ...state,
        status: action.status
      };
    case 'queryChanged':
      return {
        ...state,
        query: action.query
      };
    case 'cleared':
      return {
        status: 'all',
        query: ''
      };
  }
}

Common Interview Pitfalls

Moving every component value into a global store.
Using context only to avoid passing one or two straightforward props.
Putting unrelated frequently changing values into one large context.
Using a reducer for trivial state that one setter expresses clearly.
Creating global state without defining which feature owns its updates.
Duplicating server-state caches inside a general global store.

Rate your confidence:

advancedFrontend Architecture & State

How would you design a scalable frontend architecture for a growing product and engineering team?

Direct Answer

Organize around product features, enforce dependency boundaries, separate server and client state, centralize shared contracts, and keep architecture proportional to demonstrated needs.

Detailed Explanation

A scalable frontend architecture should make common product changes understandable, testable, and independently maintainable.

A practical architecture often includes:

Feature ownership

Group components, state logic, tests, API adapters, and types by product feature rather than separating every file only by technical category.

Dependency direction

Shared foundations should not depend on product-specific features. Features should interact through explicit public interfaces rather than importing internal files from one another.

State boundaries

Keep local interaction state near the component.

Use URL state for shareable navigation state.

Use a server-state mechanism for remote cached data.

Use application-wide stores only for genuinely shared client state.

Data boundaries

Validate external data and translate transport models into stable internal models. Prevent backend response details from spreading through every component.

Design system

Maintain accessible reusable primitives, tokens, and interaction patterns without forcing unrelated product behavior into generic components.

Performance and delivery

Split code by meaningful routes or features, monitor bundle growth, and avoid loading every feature at startup.

Testing

Test pure state logic, component behavior, feature integration, and critical user journeys at appropriate levels.

Architecture should remain proportional to current pressure. Introducing micro-frontends, plugin systems, or complex global event buses before there is a demonstrated ownership or deployment need can increase coordination cost rather than reduce it.

Common Interview Pitfalls

Organizing a large application only by technical file type.
Allowing features to import one another’s private implementation files.
Building one global store containing local, server, URL, and form state.
Creating generic components that contain product-specific business behavior.
Sharing backend transport types directly across the entire interface.
Introducing micro-frontends without independent deployment or ownership requirements.
Creating a shared folder that becomes an unowned collection of unrelated code.
Optimizing architecture for hypothetical scale instead of observed change pressure.

Rate your confidence:

beginnerPerformance, Testing & Delivery

What are Core Web Vitals, and what aspect of user experience does each metric represent?

Direct Answer

LCP measures loading performance, INP measures interaction responsiveness, and CLS measures unexpected visual movement throughout the page lifecycle.

Detailed Explanation

Core Web Vitals are user-focused performance metrics designed to represent important parts of the web experience.

The current metrics are:

Largest Contentful Paint, or LCP: Measures how quickly the largest visible content element is rendered. It is intended to represent perceived loading performance.

Interaction to Next Paint, or INP: Measures responsiveness across user interactions by observing how quickly the page presents visual feedback after an interaction.

Cumulative Layout Shift, or CLS: Measures unexpected movement of visible content during the page lifecycle.

A page can load quickly but still feel slow if interactions are delayed by long JavaScript tasks. It can also render content quickly but remain frustrating if buttons, text, or form fields move unexpectedly.

Performance should be evaluated using both:

Lab data: Controlled measurements from development tools, automated tests, or synthetic environments.

Field data: Measurements collected from real users, devices, networks, and page sessions.

Lab data is useful for debugging and repeatability. Field data reveals how the product behaves across actual user conditions.

Teams should examine performance by route, device class, release version, geography, and user journey rather than relying only on one global average.

Code Example

import {
  onCLS,
  onINP,
  onLCP,
  type Metric
} from 'web-vitals';

function reportMetric(metric: Metric) {
  navigator.sendBeacon(
    '/api/web-vitals',
    JSON.stringify({
      name: metric.name,
      value: metric.value,
      rating: metric.rating,
      navigationType: metric.navigationType
    })
  );
}

onLCP(reportMetric);
onINP(reportMetric);
onCLS(reportMetric);

Common Interview Pitfalls

Treating a single performance score as a complete description of user experience.
Measuring performance only on a fast development computer and network.
Using average values that hide poor experiences at higher percentiles.
Optimizing LCP while ignoring interaction responsiveness and layout stability.
Relying only on lab measurements without collecting representative field data.
Sending performance telemetry without route, release, or device context.

Rate your confidence:

beginnerPerformance, Testing & Delivery

How do unit, integration, and end-to-end frontend tests differ?

Direct Answer

Unit tests isolate small logic, integration tests verify collaborating UI parts, and end-to-end tests validate complete user journeys through the deployed application stack.

Detailed Explanation

Frontend tests provide different levels of confidence and cost.

Unit tests verify small pieces of logic in isolation, such as:

Formatting functions

Reducers

Validation rules

Selectors

Data transformations

They are normally fast and precise when they fail, but they do not prove that several application parts work together.

Integration or component tests render a component or feature with realistic dependencies and verify observable behavior. They may cover:

User input

Validation messages

Loading and error states

Component collaboration

Network responses through controlled test handlers

End-to-end tests exercise complete workflows in a real browser against a running application. Examples include signing in, completing a form, importing a job, or changing an application status.

End-to-end tests provide strong confidence across routing, browser behavior, APIs, persistence, and deployment configuration, but they are slower and more expensive to maintain.

A healthy suite uses each level where it provides the best return. Pure calculation logic does not need a browser test, while a critical multi-page workflow should not be protected only by isolated unit tests.

Tests should focus on observable contracts rather than private component methods or implementation details.

Code Example

import { describe, expect, it } from 'vitest';

function calculateCompletion(
  completed: number,
  total: number
): number {
  if (total <= 0) {
    return 0;
  }

  return Math.round(
    (completed / total) * 100
  );
}

describe('calculateCompletion', () => {
  it('returns a rounded completion percentage', () => {
    expect(
      calculateCompletion(2, 3)
    ).toBe(67);
  });

  it('returns zero when total is not positive', () => {
    expect(
      calculateCompletion(0, 0)
    ).toBe(0);
  });
});

Common Interview Pitfalls

Testing private component methods instead of observable user behavior.
Using end-to-end tests for every small calculation and edge case.
Mocking so many dependencies that an integration test no longer represents reality.
Protecting a critical user journey only with isolated unit tests.
Sharing mutable test state that makes test order affect results.
Treating code-coverage percentage as proof that meaningful behavior is tested.

Rate your confidence:

intermediatePerformance, Testing & Delivery

How should a frontend engineer use code splitting, lazy loading, and bundle analysis?

Direct Answer

Split code at meaningful route or feature boundaries, defer noncritical modules, inspect bundle composition, and verify that loading changes improve real user experience.

Detailed Explanation

JavaScript must be downloaded, parsed, compiled, and executed. Large initial bundles can therefore delay rendering and interaction, especially on slower devices.

Code splitting divides application code into separately loadable chunks. Useful boundaries include:

Routes

Large feature areas

Administrative tools

Rich editors

Charts or visualization libraries

Modals or workflows that most users never open

Lazy loading defers a component or library until it is needed. The user should receive an intentional loading state while the deferred code is retrieved.

Bundle analysis reveals which modules contribute to output size. It can identify:

Large dependencies

Duplicate package versions

Unexpected client imports

Broad imports that prevent tree shaking

Features included in the initial route unnecessarily

Splitting every small component can create excessive network requests and loading boundaries. The objective is not the largest possible number of chunks, but an initial payload appropriate for the user’s immediate task.

A lazy-loaded feature should also handle loading failure. Deployments can create situations where an older page session requests a chunk that no longer exists, so applications may need recovery behavior such as prompting for a refresh.

Optimization should be confirmed through bundle output, browser traces, and field performance data rather than assumed from source-code changes.

Code Example

import dynamic from 'next/dynamic';

const AnalyticsDashboard = dynamic(
  () =>
    import('./AnalyticsDashboard').then(
      (module) => module.AnalyticsDashboard
    ),
  {
    loading: () => (
      <p role="status">
        Loading analytics…
      </p>
    ),
    ssr: false
  }
);

export function AnalyticsSection({
  enabled
}: {
  enabled: boolean;
}) {
  if (!enabled) {
    return null;
  }

  return <AnalyticsDashboard />;
}

Common Interview Pitfalls

Lazy loading small components that are required immediately on every page view.
Splitting code without providing an accessible loading state.
Adding a large dependency without inspecting its bundle contribution.
Assuming tree shaking removes every unused import automatically.
Optimizing bundle size without measuring execution cost or user impact.
Ignoring failures caused by stale clients requesting removed chunks.
Disabling server rendering without understanding content and loading consequences.

Rate your confidence:

intermediatePerformance, Testing & Delivery

How should frontend tests verify accessible user behavior rather than implementation details?

Direct Answer

Query elements by accessible roles and names, perform realistic keyboard and pointer interactions, and assert visible states, focus movement, and announced feedback.

Detailed Explanation

Accessible frontend tests should interact with the interface in ways that resemble real user behavior.

Preferred queries usually reflect how users and assistive technologies identify controls:

Role and accessible name

Associated label text

Visible text

Place-holder only when no stronger semantic query applies

Test IDs as a last resort for elements without a user-facing identity

For example, a test should locate a button by its role and visible name rather than by a CSS class or internal component identifier.

Useful behavior to test includes:

Keyboard activation

Logical tab order

Focus placement after opening or closing a dialog

Form labels and validation messages

Disabled and expanded states

Loading and live feedback

Error recovery

Escape-key dismissal where appropriate

Automated tests can detect many semantic and interaction regressions, but they cannot fully determine whether an interface is understandable, efficient with a keyboard, or useful with a screen reader. Manual accessibility testing remains necessary for critical workflows.

Tests should avoid asserting internal state values when the same result can be verified through visible output, accessible state, or user interaction.

Code Example

import {
  render,
  screen
} from '@testing-library/react';
import userEvent from '@testing-library/user-event';

it('returns focus after closing the dialog', async () => {
  const user = userEvent.setup();

  render(<DeleteApplication />);

  const openButton = screen.getByRole(
    'button',
    {
      name: 'Delete application'
    }
  );

  await user.click(openButton);

  const dialog = screen.getByRole(
    'dialog',
    {
      name: 'Delete application'
    }
  );

  expect(dialog).toBeInTheDocument();

  await user.keyboard('{Escape}');

  expect(dialog).not.toBeInTheDocument();
  expect(openButton).toHaveFocus();
});

Common Interview Pitfalls

Selecting controls by CSS class when an accessible role and name are available.
Testing click behavior without testing keyboard interaction.
Asserting internal component state instead of visible user outcomes.
Using test IDs as the default query for every interactive element.
Checking that a dialog appears without verifying focus behavior.
Assuming automated accessibility checks replace manual assistive-technology testing.
Using low-level event dispatch when a realistic user interaction helper is available.

Rate your confidence:

intermediatePerformance, Testing & Delivery

How do CI checks, feature flags, gradual rollouts, and monitoring support safe frontend releases?

Direct Answer

CI verifies each change before merging, flags separate deployment from exposure, gradual rollout limits impact, and monitoring determines whether exposure should continue.

Detailed Explanation

A safe release process detects defects before deployment and limits the impact of defects that escape preproduction testing.

Useful continuous-integration checks include:

Formatting and linting

Type checking

Unit and component tests

End-to-end smoke tests

Accessibility checks

Security scanning

Production builds

Bundle-size or performance budgets

Required status checks can prevent changes from merging when critical verification fails.

A feature flag separates code deployment from feature exposure. Code can be deployed while the feature remains disabled, then enabled for selected users, environments, or percentages.

A gradual rollout may proceed through:

1. Internal users

2. A small production percentage

3. A larger controlled audience

4. General availability

Each stage should have success and rollback criteria based on errors, performance, conversion, support signals, and user behavior.

Feature flags are not substitutes for testing. Both enabled and disabled paths need verification. Flags also create temporary branches in application behavior and should have ownership, purpose, creation date, and removal criteria.

Client-side flags must not be treated as security controls because users can inspect or modify browser behavior. Sensitive authorization must remain enforced by the backend.

Code Example

type ReleaseDecision = {
  enabled: boolean;
  variant: 'control' | 'new-tracker';
};

function JobTrackerPage({
  release
}: {
  release: ReleaseDecision;
}) {
  if (
    !release.enabled ||
    release.variant === 'control'
  ) {
    return <ExistingJobTracker />;
  }

  return <NewJobTracker />;
}

// The backend must still enforce permissions.
// The browser flag only controls presentation
// and rollout exposure.

Common Interview Pitfalls

Merging changes even when required CI checks are failing.
Using a client-side feature flag as an authorization control.
Rolling a feature out globally without intermediate monitoring stages.
Leaving temporary flags in the codebase indefinitely.
Testing only the enabled path and ignoring the disabled fallback.
Creating flags without an owner or removal condition.
Continuing rollout despite release-specific error or performance regressions.

Rate your confidence:

advancedPerformance, Testing & Delivery

How would you design a high-performance, accessible, testable, and safely delivered production frontend?

Direct Answer

Set measurable budgets, use semantic components and clear state boundaries, optimize critical delivery, test user journeys, monitor field behavior, and release progressively.

Detailed Explanation

A production-ready frontend is designed across architecture, performance, accessibility, testing, observability, and delivery rather than optimized only at the end.

Architecture

Organize code by product features and ownership.

Keep local state close to its consumers.

Separate server state, URL state, and temporary client state.

Validate external data at runtime.

Maintain stable component and API boundaries.

Accessibility

Use semantic HTML and native controls.

Support keyboard operation and visible focus.

Provide accessible names, labels, errors, and status communication.

Test zoom, reflow, reduced motion, and representative assistive technologies.

Performance

Deliver useful HTML and critical content early.

Minimize initial client JavaScript.

Split large noncritical features.

Reserve media dimensions to prevent layout movement.

Optimize the LCP resource.

Break up long main-thread tasks.

Measure Core Web Vitals in the field.

Testing

Unit-test pure logic and state transitions.

Test components through user-visible behavior.

Protect critical journeys with end-to-end tests.

Include accessibility, loading, failure, cancellation, and empty states.

Delivery

Require lint, type, test, build, and security checks.

Use preview environments and production-like configuration.

Apply backward-compatible API and data changes.

Release high-risk features gradually.

Maintain rollback and feature-disable mechanisms.

Observability

Track JavaScript failures, failed resources, API latency, Core Web Vitals, release versions, and important user journeys.

Avoid collecting sensitive user data unnecessarily.

The architecture should define measurable performance and reliability budgets before release. A feature that passes functional tests but causes severe interaction latency, inaccessible controls, or a large failure rate is not production-ready.

Common Interview Pitfalls

Treating performance and accessibility as final pre-release cleanup work.
Shipping every route and third-party dependency in the initial JavaScript bundle.
Testing only successful desktop workflows on fast development machines.
Monitoring server errors without capturing frontend failures and user experience metrics.
Using client-side flags or hidden controls as security boundaries.
Collecting telemetry without release versions or route context.
Defining performance budgets without enforcing them during delivery.
Rolling out a high-risk change to every user without staged exposure.

Rate your confidence:

Want to tailer your resume for Frontend Developer roles?

Import your resume, scan it for critical Frontend Developer keywords, and compare it against ATS standards instantly.

View Frontend Developer Resume Example Analyze Your Resume Free