Full-Stack Developer Interview Questions and Prep Guide 2026

Full stack developer interview questions in 2026 cover three layers: the browser (JavaScript, TypeScript, React, performance, accessibility), the server (API design, authentication, caching), and the database (SQL, schema design, indexing). Most loops add a system design round and a practical build-a-feature exercise that crosses all three. The candidates who do best read the job description first and split their prep time to match it, instead of studying both halves equally.

This guide covers what each round tests, the questions that come up most, and a weighted prep plan you can adapt in ten minutes.

Key Takeaways

• A full-stack interview is broad, not shallow. Questions that cross layers, like "why is this page slow?", are the ones that expose gaps.
• Your prep split should follow the job description, not a 50/50 default. A frontend-leaning role and an API-heavy role need very different study plans.
• Expect at least one practical round where you build a small feature end to end: data model, API endpoint, and UI.
• System design for full-stack roles is product-shaped. You will design a feature like a comment system or file upload flow, not a global database.
• SQL deserves real study time. Joins, indexes, and N+1 queries come up often in the backend portion of the loop.
• Practice one stack until it is boring. Speed in a timed exercise comes from familiarity, not from knowing many frameworks.

How Do Full-Stack Interview Loops Differ From Frontend and Backend Loops?

A full-stack loop tests breadth and the connections between layers. A frontend loop goes deep on rendering, browser APIs, and UI architecture. A backend loop goes deep on distributed systems, concurrency, and data. A full-stack loop asks for working knowledge of both, then checks whether you can reason about the seams where they meet.

Here is how the three loops typically compare at mid-size and large tech companies:

Two things follow from this table. First, you will rarely get the hardest frontend or hardest backend question, so going extremely deep on one niche topic has poor returns. Second, interviewers expect you to explain how a decision on one layer affects another. Choosing client-side pagination, for example, changes your API contract and your database query.

At startups, the loop often collapses into a recruiter call, a practical build exercise, and a conversation with the founders or the engineering lead. At larger companies, full-stack candidates often go through the standard software engineer loop, with one or two rounds swapped for web-specific content. Ask your recruiter which version you are in. That single question changes how you should spend your time.

For deeper coverage of the specialist versions, see our frontend engineer interview guide and backend engineer interview guide.

Frontend Fundamentals Tested in Full-Stack Interviews

Frontend questions in a full-stack loop focus on JavaScript fundamentals and practical React rather than browser engine internals. You need to explain how things work well enough to debug them under pressure.

The topics that come up most often:

• JavaScript core: closures, this binding, the event loop, promises and async/await, microtasks versus macrotasks, and equality rules.
• TypeScript: generics, union and discriminated union types, narrowing, and typing API responses.
• React: state versus props, when components re-render, useEffect dependencies and cleanup, keys in lists, controlled forms, and when memoization actually helps.
• Data fetching: loading and error states, race conditions when a user types fast, request cancellation, and caching.
• Performance: bundle size, code splitting, lazy loading images, and avoiding layout thrash.
• Accessibility: semantic HTML, labels, keyboard-only use, and focus management in modals.
• Security on the client: XSS and why rendering untrusted HTML is dangerous, plus where to store tokens.

A typical question looks simple and hides a trap. "Build a search input that calls an API as the user types" tests debouncing, cancelling stale requests, and showing the right result when responses return out of order.

import { useEffect, useState } from "react";

type Result = { id: string; name: string };

export function useSearch(query: string, delayMs = 300) {
  const [results, setResults] = useState<Result[]>([]);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    if (!query.trim()) {
      setResults([]);
      return;
    }
    const controller = new AbortController();
    const timer = setTimeout(async () => {
      try {
        const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
          signal: controller.signal,
        });
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        setResults(await res.json());
        setError(null);
      } catch (err) {
        if ((err as Error).name !== "AbortError") setError("Search failed");
      }
    }, delayMs);

    return () => {
      clearTimeout(timer);
      controller.abort();
    };
  }, [query, delayMs]);

  return { results, error };
}

The interviewer is checking whether you clean up the timer, abort the in-flight request, encode the query, and handle errors without showing a stale result. Our JavaScript interview questions and React interview questions guides go deeper on each of these topics.

Backend and Database Questions You Should Expect

Backend questions in a full-stack interview center on API design, authentication, and data modeling. The goal is to show you can build a service that is correct, secure, and does not fall over when traffic doubles.

API design and HTTP

Expect questions like "Design the REST endpoints for a todo app with shared lists" or "How would you paginate this endpoint?" Strong answers cover:

• Resource naming, correct HTTP methods, and status codes (201 for create, 404 versus 403, 409 for conflicts, 422 or 400 for validation).
• Cursor pagination versus offset pagination, and why offset gets slow and inconsistent on large, changing tables.
• Idempotency for retries on POST requests.
• REST versus GraphQL trade-offs: flexible queries and fewer round trips versus caching complexity and query cost control.
• CORS: what it protects against and why it is enforced by the browser, not the server.

Authentication and security

Session cookies versus JWTs is close to a guaranteed question. Know that HttpOnly cookies keep tokens out of reach of injected scripts, that cookies need CSRF protection (often via SameSite plus tokens), and that JWTs are hard to revoke before expiry. Also prepare password hashing (bcrypt or Argon2, never plain SHA), SQL injection and parameterized queries, and rate limiting on login endpoints.

Node.js specifics

For JavaScript-backend roles, be ready to explain why blocking the event loop hurts every request, how to handle errors in async middleware, and when to move CPU-heavy work to worker threads or a queue. The Node.js interview questions guide covers these in detail.

SQL and data modeling

This is a common weak spot for developers who mostly work in the UI layer. You should be able to design a schema for a small product, write joins and aggregations without help, and explain indexes.

SELECT p.id, p.title, COUNT(c.id) AS comment_count
FROM posts p
LEFT JOIN comments c ON c.post_id = p.id
WHERE p.author_id = $1
GROUP BY p.id, p.title
ORDER BY p.created_at DESC
LIMIT 20;

Follow-up questions usually include: which index makes this fast (one on posts(author_id, created_at) and one on comments(post_id)), why LEFT JOIN instead of INNER JOIN (posts with zero comments), and how an ORM loop that loads comments per post creates the N+1 problem. For MERN-stack roles, expect the MongoDB version of the same ideas: embedding versus referencing documents, compound indexes, and the aggregation pipeline. Practice with our SQL interview questions guide.

Full-Stack System Design: What It Looks Like

Full-stack system design is product-feature design. Instead of "design Twitter at global scale," you are more likely to hear "design a comment system with replies and live updates" or "design a file upload feature for a document app." The interviewer wants a design that works across the client, the API, and storage.

A reliable structure for these rounds:

1. Clarify the feature: who uses it, read versus write volume, real-time needs, and what "done" looks like.
2. Define the data model: tables or collections, keys, and the indexes your main queries need.
3. Define the API contract: endpoints or GraphQL operations, request and response shapes, pagination, and errors.
4. Design the client: component structure, where state lives, optimistic updates, and loading states.
5. Handle scale and failure: caching (CDN, Redis, HTTP cache headers), background jobs, rate limits, and what happens when a request fails halfway.

Here is how the file upload prompt plays out. A good answer uses presigned URLs so the browser uploads directly to object storage instead of streaming large files through your API servers. The API creates a pending record and returns the presigned URL. The client uploads with progress tracking. A storage event or a confirm call marks the record complete and triggers a background job for virus scanning or thumbnails. That one answer touches the client, the API, storage, and async processing, which is exactly the signal a full-stack interviewer wants.

Common prompts to practice: a URL shortener, a notification feed, a real-time chat panel, a typeahead search, and a collaborative todo list. Our system design interview guide covers the general framework, and the URL shortener walkthrough is a good first full design to practice end to end.

Build-a-Feature Exercises: A Worked Example

A build-a-feature round asks you to ship a thin, working slice of a product in 60 to 120 minutes. It can run live on a shared screen or as a take-home. The grading is consistent: does it work, is the data model sensible, are errors handled, and can you explain your trade-offs?

Here is a realistic prompt and a time plan that holds up under pressure.

Prompt: Build a "favorites" feature. Logged-in users can star products, see a list of their starred products, and remove a star. The star state should survive a page refresh.

A few choices in this plan are what interviewers look for. Using PUT and DELETE keyed by product ID makes the toggle idempotent, so a double click or a retry never creates duplicates. The unique constraint enforces that at the database level, not only in application code. The optimistic update makes the UI feel instant, and the rollback shows you thought about failure.

async function toggleFavorite(productId: string, isFavorite: boolean) {
  setFavorite(productId, !isFavorite);
  try {
    const res = await fetch(`/api/favorites/${productId}`, {
      method: isFavorite ? "DELETE" : "PUT",
    });
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
  } catch {
    setFavorite(productId, isFavorite);
    showToast("Could not update favorites");
  }
}

Practice two or three prompts like this with a timer before your loop: a comments thread, a paginated admin table with filters, and a simple booking form with server-side validation. Narrate as you build. Interviewers grade reasoning, and silence makes even good code look uncertain. Our guide on how to think out loud in a coding interview has scripts for this, and the take-home assignment guide covers the untimed version.

How to Split Prep Time Based on the Job Description

The most useful thing you can do before studying is classify the role. Full-stack job descriptions are rarely balanced. Some are frontend roles with a backend bonus, and some are backend roles that touch a React admin panel. Your prep should match.

Step 1: Score the job description

Go through the responsibilities and requirements and tally signals:

• Frontend signals: React, Vue, Angular, Next.js, design systems, accessibility, UI performance, "pixel-perfect," collaboration with designers.
• Backend signals: APIs, microservices, PostgreSQL, MongoDB, queues, caching, cloud services, data pipelines, reliability, on-call.

If one side has roughly twice as many signals as the other, the role is leaning. Otherwise, treat it as balanced.

Step 2: Apply the weighted allocation

Adjust the algorithms column based on what the recruiter tells you. If the loop includes two LeetCode-style coding rounds, that column should grow no matter how the job description reads. The startup row weights behavioral higher because founders often hire for ownership and communication as much as raw skill.

Step 3: Convert percentages into a calendar

For a three-week plan at about 10 hours a week, you have 30 hours. A backend-leaning role becomes roughly 12 hours on APIs, auth, and SQL, 6 hours on system design, 4.5 hours each on frontend and algorithms, and 3 hours on behavioral stories. Put one full build-a-feature rehearsal at the end of each week so you practice combining the layers, not only studying them separately.

The table works because it forces you to stop studying what feels comfortable. Most developers over-prepare their strongest side. Interviewers probe the weaker one.

Common Mistakes in Full-Stack Interviews

The mistakes that sink full-stack candidates are rarely about missing knowledge. They are about scope and communication.

• Building the UI first in a practical round. Start with the data model and API, because a pretty UI with no working persistence fails the core requirement.
• Ignoring failure paths. No loading state, no error state, no handling for a 500 response. Interviewers notice immediately.
• Treating the database as a black box. Saying "the ORM handles it" when asked about indexes or N+1 queries is a red flag.
• Listing technologies instead of trade-offs. "I would use Redis" is weak. "I would cache the product list in Redis for 60 seconds because it is read-heavy and slight staleness is fine" is strong.
• Switching stacks to impress. Use what you know. A working Express app beats a half-finished app in a framework you learned last week.
• Under-preparing behavioral stories. Full-stack roles often own features end to end, so expect "tell me about a feature you shipped from start to finish."

Final Week Checklist

In the last week, consolidate instead of adding new topics.

• Run one timed build-a-feature rehearsal with a fresh prompt.
• Write three SQL queries from memory: a join with aggregation, a query that needs a composite index, and a pagination query.
• Explain session cookies versus JWTs out loud in under two minutes.
• Sketch one full-stack system design (file upload or comments) on paper, covering all five steps.
• Prepare four behavioral stories: a shipped feature, a production bug, a disagreement, and a trade-off you would make differently now.
• Test your setup: editor, terminal, local database, and screen sharing on the platform the company uses.