Frontend Engineering

Frontend Interview Questions and Frameworks Guide: React, TypeScript, Performance, and Architecture

CodeSwiftr Team
frontendreactjavascripttypescriptinterview preparation

Frontend Interview Questions and Frameworks Guide

Frontend interviews are often underestimated by backend-heavy candidates and oversimplified by hiring loops. In reality, good frontend interview performance requires three different skills at once: solid JavaScript and browser fundamentals, framework fluency, and product-quality thinking about performance, accessibility, and user experience.

The mistake many candidates make is preparing only for framework trivia. That leads to answers like "React re-renders when state changes" without being able to explain why a component is slow, why a hydration mismatch happens, or how to structure state for a complex screen.

This guide focuses on the parts that actually matter in modern frontend interview questions: JavaScript execution, React and TypeScript patterns, framework tradeoffs, performance, accessibility, and frontend architecture. If you are interviewing for senior frontend or full-stack roles, these are the areas most likely to separate you from the field.

For deeper React-specific prep, review Advanced React Interview Guide. For full-stack coordination topics, keep Backend Interview Topics: Databases, APIs, Caching, and Microservices nearby.

What Frontend Interviews Usually Cover

A well-designed frontend loop tests across four layers:

  1. language fundamentals
  2. browser and rendering model
  3. framework-level implementation
  4. product and architecture judgment

That means you should expect questions like:

  • What is the difference between == and ===?
  • How does the event loop interact with promises and rendering?
  • When would you lift state versus colocate it?
  • How do you prevent expensive rerenders?
  • When would you choose server rendering versus client rendering?
  • How do you make an interview project accessible?

Candidates who can only answer one category usually plateau quickly.

JavaScript and TypeScript Fundamentals

Before React, there is JavaScript. Interviewers care because framework abstractions eventually leak.

Topics you should be comfortable with:

  • closures
  • lexical scope
  • event loop and microtasks
  • async/await versus raw promises
  • array/object immutability
  • this behavior and arrow functions
  • modules
  • common TypeScript utility types

Example: Closures in Practice

function createCounter() {
  let count = 0;

  return {
    increment() {
      count += 1;
      return count;
    },
    current() {
      return count;
    },
  };
}

const counter = createCounter();
counter.increment(); // 1
counter.increment(); // 2
counter.current();   // 2

The important interview explanation is not "this uses a closure." It is: the returned functions retain access to count because they were created in the lexical environment where count exists.

TypeScript Question To Expect

If a team uses TypeScript heavily, be ready to explain the difference between interface and type, the value of discriminated unions, and how stricter typing reduces invalid UI states.

type RequestState =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: string[] }
  | { status: 'error'; message: string };

This pattern matters because it turns impossible states into unrepresentable states. That is an architectural answer, not just a typing trick.

React Questions That Matter

React interview questions usually cluster around rendering, state, effects, and composition.

State Colocation vs Global State

One of the best signals of frontend maturity is where you put state.

Use local state when:

  • only one component needs it
  • the state is temporary UI state
  • passing it down one or two levels is fine

Use shared or global state when:

  • multiple distant components need access
  • the state survives route changes
  • the state coordinates a larger workflow

Bad frontend systems often fail because everything becomes global too early.

Example: Derived State Instead of Duplicate State

import { useState } from 'react';

type User = { id: string; name: string; active: boolean };

export function UserList({ users }: { users: User[] }) {
  const [showActiveOnly, setShowActiveOnly] = useState(false);

  const visibleUsers = showActiveOnly
    ? users.filter((user) => user.active)
    : users;

  return (
    <div>
      <label>
        <input
          type="checkbox"
          checked={showActiveOnly}
          onChange={(e) => setShowActiveOnly(e.target.checked)}
        />
        Active only
      </label>

      <ul>
        {visibleUsers.map((user) => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  );
}

This is a small example, but the principle matters: derive visibleUsers from source state instead of storing a second mutable copy that can drift.

Effects: The Most Common Failure Area

A large share of React bugs come from misused effects. Candidates should be able to explain:

  • effects synchronize with external systems
  • effects are not the default place for all logic
  • unstable dependencies can cause loops
  • stale closures create subtle bugs

If you can explain when to avoid an effect entirely, that is a good sign.

Framework Questions: React, Next.js, Vue, and the Why Behind Them

Many companies say "frontend framework questions" but really mean architectural tradeoffs.

React

Know:

  • component composition
  • hooks model
  • client rendering patterns
  • context tradeoffs
  • suspense and concurrent rendering at a high level

Next.js

Know:

  • SSR, SSG, ISR, and when to use each
  • route-based code splitting
  • server components versus client components
  • API routes and deployment implications

Vue

Know:

  • reactivity model
  • composition API versus options API
  • template syntax and computed properties

The key is not to master every framework equally. It is to explain why a team might pick one based on rendering model, DX, performance, and hiring familiarity.

Frontend Performance Questions

Performance is where average candidates start giving generic answers. Strong candidates speak in concrete bottlenecks:

  • too many rerenders
  • large bundles
  • expensive list rendering
  • unnecessary network waterfalls
  • layout thrash
  • unoptimized assets

Example: Memoization Is Not The First Fix

Many candidates say "use useMemo and useCallback everywhere." That is usually weak reasoning. Start with:

  • remove unnecessary work
  • colocate state to reduce rerender blast radius
  • split large components
  • virtualize long lists
  • defer non-critical work

Then memoize only if profiling shows it helps.

Example: Rendering a Large List Safely

type Row = { id: string; label: string };

export function SearchResults({ rows }: { rows: Row[] }) {
  return (
    <ul>
      {rows.slice(0, 50).map((row) => (
        <li key={row.id}>{row.label}</li>
      ))}
    </ul>
  );
}

This is not full virtualization, but it demonstrates the habit of constraining work. In a real app, you might use windowing for thousands of rows.

Accessibility Questions

Frontend interview questions increasingly include accessibility, especially for senior roles. You should be able to talk about:

  • semantic HTML
  • focus management
  • keyboard navigation
  • color contrast
  • screen reader labels
  • form error handling

This is one of the cleanest places to stand out because many candidates still treat accessibility as optional.

For example, a button should be a