25 JavaScript interview questions
Structure the JavaScript interview loop to test evidence, not memory. Start with a recruiter or hiring manager screen to confirm scope, communication, remote work habits, and recent JavaScript experience. Follow with a technical screen focused on code reading, debugging, async behavior, and practical browser or Node.js trade-offs. Use one live coding or take-home exercise that resembles your product work and includes tests. Add a system design round for mid+ candidates covering APIs, rendering, state, observability, and failure modes in a JavaScript stack. Finish with a behavioral and collaboration interview that checks ownership, code review habits, mentoring, and how the candidate makes trade-offs with product, design, QA, and security.
Junior JavaScript questions
Fundamentals, learning speed and how they debug.
01You are given a React or vanilla JavaScript form where the submit button sometimes sends stale input values. How would you debug it?
Listen for: A strong answer starts by reproducing the issue, checking event handlers, state updates, controlled versus uncontrolled inputs, and whether async code closes over old values. They should use browser DevTools, console breakpoints, React DevTools when relevant, and small tests. Good juniors explain what they would inspect before rewriting code.
Red flag: They immediately blame React or the browser without proposing a way to reproduce and isolate the stale value.
02A page loads slowly because a large JavaScript bundle blocks interaction. What simple improvements would you consider first?
Listen for: Look for practical steps: run Lighthouse or WebPageTest, inspect bundle output from Vite, Next.js, webpack, or Rollup, remove unused dependencies, split routes, lazy-load noncritical UI, defer third-party scripts, and avoid shipping server-only code to the browser. They should understand that measurement comes before optimization.
Red flag: They suggest minification only, with no mention of measuring bundle size or execution cost.
03How would you explain promises, async/await, and error handling to another junior developer using a real example?
Listen for: A good answer uses a concrete example such as fetching data, parsing JSON, and handling network and application errors. They should mention try/catch with async/await, returning or awaiting promises, avoiding unhandled rejections, and distinguishing sequential from parallel work with Promise.all when appropriate.
Red flag: They treat async/await as making code synchronous and ignore rejection handling.
04You change a function and an unrelated test fails. What do you do next?
Listen for: Listen for calm debugging: read the failing test, run the narrow test file, inspect the diff, check shared mocks, time, random data, module state, or mutation of inputs. They should avoid blindly updating snapshots. Good candidates can explain when a failing test reveals a real hidden dependency.
Red flag: They say they would update or delete the failing test because it is unrelated.
05What do you look for when reviewing a small pull request in a JavaScript codebase?
Listen for: Strong juniors mention readability, clear names, simple control flow, tests for changed behavior, edge cases around null or undefined, async error paths, accessibility for UI changes, and consistency with existing patterns. They should ask questions rather than only nitpick formatting, especially when ESLint and Prettier already handle style.
Red flag: They focus only on semicolons, spacing, or personal style preferences.
06A bug only happens in production, not locally. What information would you gather before making a fix?
Listen for: They should ask for logs, error messages, browser or Node.js version, feature flags, environment variables, build mode differences, user steps, affected route or API, recent deploys, and whether source maps or error tracking are available. Good answers include creating a minimal reproduction or adding targeted instrumentation.
Red flag: They propose changing code immediately without understanding the production environment or observed failure.
Mid-level JavaScript questions
Independent delivery, trade-offs and code quality.
07A Node.js API endpoint sometimes times out under load. Walk through how you would investigate it.
Listen for: Strong answers cover request tracing, logs with correlation IDs, database and downstream latency, event loop delay, CPU profiling, memory pressure, connection pooling, and missing timeouts. They should know Node.js 22 has useful diagnostics, but not depend on version trivia. They should separate symptoms from root cause.
Red flag: They assume scaling instances is the first fix without checking blocking work, downstream calls, or resource limits.
08How do you decide whether state belongs in local component state, a URL, a server cache, or a client store?
Listen for: Listen for clear ownership: local UI state for ephemeral concerns, URL for shareable navigation state, TanStack Query or framework loaders for server data, and Zustand, Redux Toolkit, or similar for cross-cutting client state. They should discuss invalidation, persistence, hydration, testability, and avoiding duplicated sources of truth.
Red flag: They put all state in a global store by default.
09You need to migrate a JavaScript codebase toward TypeScript. What would your plan look like?
Listen for: A good mid-level answer is incremental: enable TypeScript or checkJs where useful, add strict settings gradually, prioritize high-change modules and API boundaries, introduce shared types from schemas such as Zod or OpenAPI, avoid broad any, and keep CI fast. They should plan for developer education and code review standards.
Red flag: They suggest a big-bang rewrite or adding any everywhere to make errors disappear.
10Describe how you would handle retries and cancellation for browser requests in a modern JavaScript app.
Listen for: They should mention AbortController, request timeouts, idempotency, exponential backoff with jitter, avoiding retries for validation or authentication errors, and canceling stale requests during navigation or input changes. Good answers include UX behavior, loading states, and integration with fetch, TanStack Query, or framework data APIs.
Red flag: They retry every failed request indefinitely and do not consider duplicate writes.
11A dependency update breaks your build. How do you approach fixing it while keeping the team moving?
Listen for: Look for reading changelogs, checking peer dependencies, lockfile changes, ESM/CommonJS compatibility, Node.js version constraints, bundler plugin changes, and failing CI logs. They should isolate the update, pin or revert if needed, create a small compatibility fix, and document follow-up rather than blocking unrelated work.
Red flag: They disable the failing check or upgrade more packages at random.
12How would you design error handling for a React, Next.js, or Remix application?
Listen for: Strong answers separate expected validation errors, authorization failures, network errors, render errors, and unknown exceptions. They mention route-level error boundaries, server action or loader responses, user-safe messages, structured logging, source maps, and preserving accessibility. They should avoid leaking stack traces or internal details to users.
Red flag: They use one global catch block and show raw error messages to users.
13Tell me about a time you reduced complexity in a JavaScript feature. What trade-offs did you make?
Listen for: A strong candidate gives a specific example: removing unnecessary abstraction, simplifying state flow, replacing custom code with platform APIs, deleting dead code, or narrowing requirements. They should describe how they validated behavior with tests or metrics and how they got agreement from product or other engineers.
Red flag: They cannot name any trade-off or only describe rewriting code because they disliked the style.
Senior JavaScript questions
Judgement, architecture and raising the team's bar.
14You inherit a large JavaScript monorepo with slow CI and inconsistent patterns. What do you do in the first month?
Listen for: Look for discovery before mandates: map packages, owners, build tools, dependency graph, test flakiness, release process, and pain points. Strong seniors prioritize high-leverage fixes such as caching, affected test selection with Nx or Turborepo, shared linting, dependency policy, and clear migration docs. They create alignment, not chaos.
Red flag: They start by replacing the entire toolchain without understanding constraints or team workflow.
15How do you evaluate whether to use Next.js, Remix, Astro, a SPA, or a custom Node.js service for a new product area?
Listen for: Strong answers compare rendering needs, SEO, personalization, data freshness, team expertise, deployment model, caching, edge constraints, API ownership, and operational complexity. They should discuss trade-offs among React Server Components, server actions, loaders, streaming, static generation, and plain APIs without treating any framework as universally best.
Red flag: They choose their favorite framework without tying it to product, performance, and operational requirements.
16A team is overusing useEffect and introducing race conditions. How would you address it?
Listen for: Listen for technical and coaching actions: identify effects that derive state unnecessarily, move data fetching to framework loaders or TanStack Query, use AbortController for cancellable work, stabilize dependencies carefully, and teach patterns through examples and reviews. Seniors should change defaults, not just fix isolated bugs.
Red flag: They suggest suppressing exhaustive-deps warnings or adding empty dependency arrays everywhere.
17How do you set standards for API contracts between a TypeScript frontend and Node.js backend?
Listen for: Strong answers cover schema-first or contract-first approaches with OpenAPI, GraphQL, tRPC, Zod, or JSON Schema, plus runtime validation, generated clients, backward compatibility, versioning, error shapes, pagination, and CI checks. They understand TypeScript types alone do not validate untrusted runtime data.
Red flag: They rely only on shared TypeScript interfaces and assume the network preserves type safety.
18Describe how you would handle a serious production incident in a JavaScript application you own.
Listen for: A senior answer includes triage, customer impact assessment, rollback or feature flag disablement, incident commander behavior, communication cadence, logs and traces, safe hotfixing, and post-incident review. They should discuss prevention: alerts, runbooks, canaries, better tests, and ownership of action items without blame.
Red flag: They focus only on coding a fix and do not mention communication, rollback, or follow-up.
19How do you balance performance, accessibility, and delivery speed for a complex frontend feature?
Listen for: Look for pragmatic sequencing: define nonnegotiables, use semantic HTML first, test keyboard and screen reader flows, budget JavaScript, defer noncritical work, and measure Core Web Vitals and interaction latency. Strong answers include negotiation with design and product while protecting baseline accessibility and user experience.
Red flag: They treat accessibility or performance as cleanup work after launch.
20What signals tell you a JavaScript abstraction should be introduced, changed, or removed?
Listen for: Strong seniors mention repeated behavior with stable requirements, clear ownership, reduced cognitive load, good naming, and tests around contracts. They also discuss removal when abstraction hides important differences, creates coupling, blocks debugging, or slows changes. They should prefer small, reversible abstractions over large framework-like inventions.
Red flag: They abstract after the second occurrence without considering volatility or maintenance cost.
System design JavaScript questions
Designing real systems end to end.
21Design a JavaScript-heavy dashboard that shows real-time operational data, supports filters in the URL, and must remain usable during partial backend outages.
Listen for: Strong answers cover WebSocket or Server-Sent Events trade-offs, polling fallback, normalized server data caching, URL state, stale data indicators, reconnect behavior, backpressure, authorization, and error boundaries. They should discuss rendering large lists or charts efficiently, plus observability for dropped updates and slow client performance.
Red flag: They assume a permanent WebSocket connection solves all real-time and reliability concerns.
22Design the frontend and Node.js backend for uploading large files with progress, pause/resume, and virus scanning status.
Listen for: Listen for chunked or multipart uploads, pre-signed object storage URLs, resumable upload IDs, client-side progress via XMLHttpRequest or fetch streams where appropriate, AbortController, checksum validation, size limits, scan status polling or events, and clear failure recovery. Good answers avoid routing large binary payloads through app servers unnecessarily.
Red flag: They send the whole file through a single JSON request to the Node.js API.
23Design an isomorphic JavaScript application with server rendering, authenticated pages, and personalized caching.
Listen for: Strong answers distinguish public static caching from private personalized responses, handle cookies and sessions securely, avoid leaking user data through shared caches, and discuss hydration, streaming, data loaders, route protection, CSRF where relevant, and cache invalidation. They should understand server and client code boundaries in frameworks like Next.js or Remix.
Red flag: They cache authenticated HTML the same way as public pages.
24Design a plugin architecture for a web app where third-party teams can add panels written in JavaScript.
Listen for: Look for extension contracts, versioned APIs, sandboxing with iframes or limited runtime capabilities, permission models, event communication, performance isolation, error isolation, and documentation. Strong answers consider supply-chain risk, bundle boundaries, compatibility testing, and how host and plugin teams debug issues without breaking each other.
Red flag: They run arbitrary plugin code directly in the main app context with full access to globals and tokens.
25Design a shared component and utility library for multiple JavaScript apps in a company monorepo.
Listen for: Strong answers cover package boundaries, semantic versioning or coordinated releases, build output for ESM, type declarations, Storybook or Ladle, visual regression tests, accessibility checks, design tokens, tree shaking, ownership, and migration strategy. They should avoid dumping unrelated utilities into one package that every app must import.
Red flag: They create one giant shared package and require every app to upgrade in lockstep for every change.
Build and Debug a Small JavaScript Data Explorer
Create a small JavaScript or TypeScript app that displays a list of records from a provided mock API, supports search and status filtering, shows a detail panel, and handles loading, empty, and error states. Use React with Vite, Next.js, Remix, or vanilla JavaScript if that better reflects your strengths. Include a deliberately slow endpoint and at least one failing response path. Add tests for the core behavior and document key trade-offs. The exercise should be scoped for 2–3 hours; polish is less important than clear structure, resilient async handling, and readable code.
How to evaluate it
- Correct handling of async data, cancellation or stale responses, loading states, and errors.
- Simple, maintainable component or module structure with clear naming and limited unnecessary abstraction.
- Useful tests for behavior and edge cases, not just snapshots or implementation details.
- Accessibility basics such as labels, keyboard interaction, focus handling, and readable status messages.
- Clear README explaining setup, trade-offs, known gaps, and what the candidate would improve next.
Rather skip the interview loop?
Every Octogle JavaScript engineer has already passed a technical assessment, system design and a live interview with an engineer who has shipped JavaScript. Send a brief and get 3–5 scored profiles in 48 hours.