Full-Stack Interview Preparation: The Complete Guide

Full-stack interviews are wide rather than deep. In one loop you can be asked how the browser event loop works, how you would design a REST endpoint, why a query is slow and how your app gets deployed. Nobody expects you to be an expert in all of it. They expect you to understand how a request travels from a button click to the database and back, and to explain each step clearly.

This guide covers what full-stack developer interviews actually test, layer by layer, with sample questions and short answers, and ends with a four-week preparation plan.

What the interview rounds look like

The exact loop varies by company, but most full-stack processes combine some of these rounds:

• Screening – a recruiter call, sometimes an online test with one or two coding problems.
• Coding (DSA) – one or two problems on arrays, strings, hash maps or trees, solved in a shared editor.
• Front-end round – JavaScript fundamentals, often a small UI to build: a search box with debounce, a todo list, a paginated table.
• Back-end round – API design, authentication, databases, sometimes a small service to write.
• System design – usually from about three years of experience: design a URL shortener, a chat feature, a rate limiter.
• Project discussion – a deep dive into something you built. This round decides more offers than people think.
• Behavioural – how you handle conflict, deadlines and mistakes.

Front end: fundamentals first

Front-end rounds test the language and the browser more than any framework. If your JavaScript is solid, React questions become easy.

HTML and CSS

• Semantic HTML: why <button> beats a clickable <div> (keyboard access and screen readers for free).
• The box model, box-sizing: border-box, and how margins collapse.
• Flexbox for one-dimensional layouts, Grid for two-dimensional ones.
• Specificity: why your style "doesn't apply", and why !important is a smell.
• Responsive design with media queries and relative units.

JavaScript

• var, let and const; hoisting and the temporal dead zone.
• Closures, and the classic loop-with-setTimeout question.
• this in regular functions versus arrow functions.
• == versus ===, and truthy/falsy values.
• Promises, async/await, and error handling with try/catch.
• Event delegation, bubbling and preventDefault.
• Debounce and throttle: be ready to write both from scratch.

The event loop

This question appears in almost every front-end round. Know the order: synchronous code runs first on the call stack; then all microtasks (promise callbacks, queueMicrotask); then one macrotask (a setTimeout callback, an I/O event), then microtasks again, and so on.

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");
// Output: A, D, C, B

React

• State versus props, and why state updates are not applied immediately.
• useEffect: the dependency array, cleanup functions, and why an effect runs twice in development with Strict Mode.
• Keys in lists: why using the array index as a key breaks reordering.
• Lifting state up versus context versus a state library.
• Memoisation with useMemo, useCallback and React.memo, and when it is not worth it.
• Controlled versus uncontrolled form inputs.

Back end: APIs, auth and services

Whether your stack is Node.js or Spring Boot, the questions are about the same ideas.

REST API design

• Resources as nouns (/orders/42), actions as HTTP methods.
• Status codes that mean something: 201 for created, 400 for bad input, 401 versus 403, 404, 409 for conflicts, 429 for rate limits.
• Idempotency: GET, PUT and DELETE should be safe to retry; POST is not, unless you add an idempotency key.
• Pagination (offset versus cursor), filtering and versioning.
• Validation at the edge and a consistent error format.

Authentication and sessions

• Session cookies – the server stores the session and the browser sends an opaque id. Easy to revoke; needs shared storage when you run several servers.
• JWT – a signed token the server can verify without a lookup. Scales easily, but cannot be revoked before it expires, so keep access tokens short-lived and use refresh tokens.
• Where to keep tokens in the browser: an HttpOnly cookie protects against XSS reading them, but then you must handle CSRF.
• Hash passwords with bcrypt or Argon2, never with a plain fast hash.
• CORS: what a preflight request is, and why the server, not the browser, decides what is allowed.

Node.js or Spring Boot

For Node.js, expect questions on the single-threaded event loop, why CPU-heavy work blocks every request, middleware in Express, and streams. For Spring Boot, expect dependency injection, bean scopes, @Transactional, and how a controller, service and repository fit together. The Spring Boot annotations cheat sheet covers the annotations you will be asked about, and the Spring Boot production checklist covers what changes when the service goes live.

Databases

• SQL versus NoSQL – relational databases give you joins, transactions and a schema; document stores give you flexible shape and easy horizontal scaling. Most applications are fine with PostgreSQL or MySQL; pick NoSQL for a specific reason, not by default.
• Indexes – a B-tree index turns a full table scan into a lookup, at the cost of slower writes and extra storage. Know what a composite index is and why column order matters.
• Joins – inner, left and the "find rows with no match" anti-join.
• Transactions – ACID, and what can go wrong at lower isolation levels.
• The N+1 problem – loading a list and then running one query per item. Fix it with a join or batched fetch.

Our post on SQL interview questions walks through the queries interviewers ask, with answers.

System design basics

For junior roles this may be a light discussion; for mid-level and senior roles it is a full round. You need a small vocabulary and a method:

1. Clarify requirements and rough scale (users, requests per second, data size).
2. Define the API.
3. Draw the high-level design: clients, load balancer, stateless app servers, database, cache.
4. Pick the data model and storage.
5. Find the bottleneck and address it: caching, read replicas, queues, sharding.
6. Talk about failure: what happens when a component goes down.

A good practice problem is a rate limiter, because it touches algorithms, shared state and HTTP behaviour. Work through designing a rate limiter before your interview.

DevOps basics

Full-stack developers are increasingly expected to ship what they build. Be ready to explain:

• What a Docker image is versus a container, and what a Dockerfile does line by line.
• A CI/CD pipeline: on every push, install, test and build; on a release, deploy.
• Environment variables for configuration and secrets, never committed to Git.
• Logs, metrics and health checks, and how you would find out your app is down.
• A reverse proxy (Nginx or Apache) in front of the app, handling TLS.

DSA: don't skip it

Many full-stack candidates prepare everything except the coding round, then fail it. You do not need competitive-programming depth. You need fluency with arrays, strings, hash maps, two pointers, sliding window, stacks, queues, binary search, trees and basic recursion. An hour a day for four weeks is enough for most product-company coding rounds.

Projects and portfolio

Have one project you can discuss for 20 minutes. It does not need to be big. It needs to be real: authentication, a database, a deployed URL, and at least one problem you solved and can explain. Interviewers ask:

• Why did you choose this stack?
• What was the hardest bug, and how did you find it?
• What would break first with 100 times the users?
• What would you do differently now?

Prepare honest answers. "I would add caching here because this query runs on every page load" beats a list of buzzwords.

A four-week preparation plan

At two to three hours a day, plus one hour of DSA every day:

• Week 1 – JavaScript and the browser. Closures, this, promises, the event loop, DOM events. Write debounce, throttle and a small promise-based fetch wrapper from scratch.
• Week 2 – React and CSS. Hooks, effects, rendering, keys, forms. Build a small app with search, pagination and a form with validation. Revise Flexbox and Grid.
• Week 3 – Back end and databases. Build a REST API with authentication, validation and error handling on your stack. Write the SQL by hand: joins, grouping, indexes. Explain JWT versus sessions out loud.
• Week 4 – System design, DevOps and mocks. Two design problems, Dockerise your project, set up a CI pipeline, then two full mock interviews with a friend or a timer.

If your back end is Java, the 30-day Java interview roadmap gives a day-by-day plan for that half.

Sample full-stack interview questions

What happens when you type a URL and press Enter?

The browser resolves the domain through DNS, opens a TCP connection and a TLS handshake, sends an HTTP request, and the server (often through a load balancer and reverse proxy) returns HTML. The browser parses the HTML, builds the DOM and CSSOM, fetches CSS, JavaScript and images, runs scripts, then lays out and paints the page. Mention caching at each step for extra credit.

What is the difference between authentication and authorisation?

Authentication proves who you are (a login). Authorisation decides what you may do (can this user delete this order?). In HTTP terms, a failed authentication is a 401; an authenticated user without permission gets a 403.

Why might a React component re-render too often?

Its parent re-renders, its state or context changes, or it receives new object or function props on every render, which defeats React.memo. Fix the cause first (move state down, split context); add useMemo or useCallback only where profiling shows a real cost.

How would you speed up a slow API endpoint?

Measure first: find whether the time goes to the database, a downstream call or the code itself. Typical fixes are an index for the slow query, removing an N+1 pattern, caching a read-heavy result, paginating a large response, or moving slow work to a background job.

What is the difference between a process and a thread?

A process has its own memory space; threads inside a process share memory. Threads are cheaper to create and communicate faster, but shared memory brings race conditions that need synchronisation.

Resources

For a structured set of material across the front end, the Complete Web Development Bundle includes JavaScript and Node.js video courses, front-end e-books and 3000+ interview questions. For a Java back end, see Spring Boot interview questions and Java Learning Resources; for the coding round, DSA handwritten notes; and for deployment, Mastering DevOps with AWS, Azure and GCP.

Whatever you use, the method is the same: understand the request path end to end, build one real project, practise explaining it out loud, and keep an hour a day for DSA.