Here’s a thing I’ve noticed about full stack interview question lists: they tend to be long, organized by technology, and not particularly useful for preparing. They cover what, not why. An interviewer asking “what is REST?” cares less about whether you know the acronym and more about whether you can spot when REST isn’t the right choice.
This post covers questions that show up consistently across full stack loops, with an emphasis on what a good answer actually demonstrates.
Browser and HTTP fundamentals
These come up early. They’re treated as warm-up questions, but failing them is a red flag.
1. what happens when you type a URL and hit enter?
The thorough answer: DNS resolution, TCP handshake, TLS negotiation (for HTTPS), HTTP request/response, HTML parsing, resource loading, rendering pipeline. Interviewers aren’t expecting every detail; they’re checking that you have a mental model of the whole chain, not just the frontend part.
2. what’s the difference between HTTP/1.1 and HTTP/2?
HTTP/2 supports multiplexing (multiple requests over a single connection), header compression, and server push. The practical implication: domain sharding and image sprites (old HTTP/1.1 performance tricks) are counterproductive in HTTP/2.
3. explain CORS
Browsers block cross-origin requests by default. Servers opt in by returning specific headers (Access-Control-Allow-Origin, etc.). Preflight requests (OPTIONS method) happen for non-simple requests. Common gotcha: the CORS error appears in the browser, but the fix is on the server.
4. what are HTTP status codes you actually use?
200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 409 (Conflict), 422 (Unprocessable Entity), 429 (Rate Limited), 500 (Internal Server Error). The 401 vs 403 distinction trips people up: 401 means “authenticate first,” 403 means “you’re authenticated but not allowed.”
JavaScript and the frontend layer
5. explain the event loop
Call stack, web APIs, microtask queue (Promises, queueMicrotask), macrotask queue (setTimeout, setInterval). Microtasks run before the next macrotask. This explains why Promise callbacks always run before setTimeout callbacks even with a 0ms delay.
6. what is a closure?
A function with access to its outer scope’s variables after the outer function has returned. Use cases: factory functions, module pattern, maintaining state in callbacks.
7. React hooks: useState and useEffect pitfalls
The two most common: (1) calling setState with the current value expecting to read the new value immediately in the same render (you can’t; state updates are async), and (2) forgetting a dependency in useEffect and ending up with a stale closure. The ESLint exhaustive-deps rule exists to catch the second one automatically.
8. virtual DOM and reconciliation
React keeps a lightweight copy of the DOM. When state changes, it diffs the old and new virtual DOM trees and applies only the necessary real DOM mutations. The key prop in lists is how React tracks which items changed, were added, or removed.
9. what triggers a re-render in React?
State change (via setState/useState setter), prop change, context value change, or parent re-rendering (unless the component is wrapped in React.memo). Interviewers often follow with: “What would you do if a component was re-rendering too often?”
APIs and the backend layer
10. REST vs. GraphQL: when would you pick each?
REST is simpler to build and cache, works well when data shapes are predictable, and is the right default. GraphQL is useful when clients have genuinely different data needs (mobile vs. web needing different fields), when you want to reduce over-fetching, or when you’re building a developer-facing API where query flexibility matters. Using GraphQL because it sounds advanced is the wrong reason.
11. explain authentication vs. authorization
Authentication: proving who you are. Authorization: determining what you’re allowed to do. These are separate concerns and mixing them up in architecture causes bugs. JWT tokens handle authentication. Role-based access control handles authorization. They should be independent layers.
12. session-based vs. token-based authentication
Sessions: server stores state (in memory or a DB), sends back a session ID cookie. Tokens: server is stateless; client stores the JWT and sends it with each request. JWT is better for horizontal scaling; sessions are simpler to revoke. The correct choice depends on your threat model and infrastructure.
13. what is middleware in Express?
A function that runs in the request-response cycle, has access to req, res, and next, and either ends the cycle or passes control to the next middleware. Common use cases: logging, authentication, request parsing, error handling.
14. how does async/await work in Node.js?
Syntactic sugar over Promises. Node’s event loop handles I/O without blocking; async functions return Promises and pause execution at await without blocking the thread. The common mistake: using await inside a forEach loop (each iteration creates an unresolved Promise that forEach doesn’t wait for; use for...of instead).
Databases
15. SQL vs. NoSQL: how do you choose?
SQL databases are the right default: relational data, ACID transactions, well-understood query patterns. NoSQL makes sense for specific use cases: document stores for highly variable schemas (MongoDB), key-value stores for caching (Redis), wide-column stores for time-series or high-write scenarios (Cassandra). “NoSQL because it scales better” is a myth; PostgreSQL handles enormous scale for most products.
16. what is an index and when does it help?
A database index is a data structure (usually a B-tree) that allows faster row lookup at the cost of slower writes and extra storage. Add indexes on columns you filter or sort by frequently. Don’t add indexes on columns you rarely query; they slow down writes for no benefit.
17. what is the N+1 query problem?
Fetching a list of N records and then making one additional query per record to fetch related data. Classic example: loading 100 posts and then making 100 individual queries for each post’s author. Fix: JOIN the related data in the initial query, or use an ORM’s eager-loading feature.
18. explain database normalization
Organizing data to reduce redundancy by splitting it into related tables. The tradeoff: normalized data requires JOINs to reassemble, which is slower at read time. Denormalization (storing redundant data) speeds up reads at the cost of more complex writes. Real applications often denormalize deliberately for performance-sensitive paths.
System design questions and what interviewers are really testing
Full stack system design questions aren’t asking you to produce a perfect architecture. They’re checking whether you can reason about constraints and tradeoffs without needing someone to guide you. The Stack Overflow Developer Survey 2024 consistently identifies system design as one of the skills developers feel least prepared for relative to how often it’s tested in interviews.
Common prompts at full stack loops:
- Design a URL shortener. Key decisions: how to generate short codes (random vs. hash-based), where to store the mapping (relational vs. key-value), how to handle redirect performance at scale.
- Design an activity feed. Fanout-on-write (pre-compute feeds for all followers) vs. fanout-on-read (compute at query time). The right answer depends on read/write ratio and user follower counts.
- Design a simple caching layer. Cache-aside, write-through, write-behind patterns. Cache invalidation strategy. How to handle cache stampede.
For all of these, start by asking clarifying questions: scale targets, consistency requirements, latency budget. LinkedIn’s engineering hiring research repeatedly identifies “asks before assuming” as a differentiating behavior in system design rounds.
Preparing by talking, not just reading
Reading a list of questions is a starting point. The feedback loop that actually builds interview readiness is speaking your answers out loud and having someone push back on the parts that are unclear or incomplete.
Craqly’s AI mock interview lets you run through questions like these in a realistic interview format, getting feedback on both the technical accuracy and the clarity of your explanations. The clearest signal that preparation is working is when you can explain the N+1 problem or the event loop without having to look anything up while talking.
One question worth sitting with: of the 18 topics above, which three would you struggle to explain clearly to someone who asked right now? Those are your actual prep priorities, not the ones that sound complicated.