{"id":260,"date":"2026-01-23T00:00:00","date_gmt":"2026-01-23T00:00:00","guid":{"rendered":"https:\/\/springgreen-curlew-885344.hostingersite.com\/blog\/full-stack-interview-questions\/"},"modified":"2026-06-19T09:42:48","modified_gmt":"2026-06-19T09:42:48","slug":"full-stack-interview-questions","status":"publish","type":"post","link":"https:\/\/lastroundai.com\/blog\/full-stack-interview-questions","title":{"rendered":"14 Full-Stack Interview Questions That Actually Separate Candidates"},"content":{"rendered":"

The BLS projects about 129,200 software developer openings per year through 2034<\/a>, and a meaningful share have “full stack” in the title. That doesn’t make the interview easier – you’re expected to hold a mental model of the browser, the server, the database, and the wire between them.<\/p>\n

I cut this from 50 full-stack interview questions to the 14 that actually decide the hire. The ones I dropped were trivia or framework-specific enough that a new hire learns them on the job. These patterns apply to mid-size companies and late-stage startups running a 3-5 round loop – I don’t have data on how they land at FAANG-scale with structured rubrics.<\/p>\n

JavaScript Fundamentals<\/h2>\n

1. Explain the JavaScript event loop<\/h3>\n

The actual mechanism: JavaScript is single-threaded. When an async operation completes, its callback goes into a queue. The event loop checks whether the call stack is empty and pulls the next item from the queue. Two queues matter: the microtask queue (Promises, queueMicrotask<\/code>) and the macrotask queue (setTimeout, I\/O). Microtasks drain completely before any macrotask runs.<\/p>\n

The answer interviewers want: write out what fires first when you mix Promise.resolve().then()<\/code> with setTimeout(() => {}, 0)<\/code>. Most candidates describe what the event loop does without demonstrating that queue priority. That’s where answers diverge.<\/p>\n

2. How do closures cause memory leaks?<\/h3>\n

A closure retains access to its lexical scope after the outer function returns. Memory leak: if a closure holds a reference to a large object and that closure stays alive (attached to an event listener, referenced by a timer), the garbage collector can’t release the outer scope.<\/p>\n

Concrete example: an event listener added inside useEffect<\/code> that closes over a stale ref and never gets cleaned up in the return function. That ships to production regularly.<\/p>\n

3. JWT vs. sessions – which do you use?<\/h3>\n

JWTs are stateless – each request carries signed claims. Sessions are stateful – the server stores session data, the client holds an ID cookie. JWTs work well for distributed systems where multiple services verify identity without calling each other. The catch: they can’t be invalidated before expiry without a token blocklist, which reintroduces statefulness.<\/p>\n

My honest take: sessions are simpler for most applications. JWT’s benefit only pays off when multiple services verify identity at actual scale. Taking on revocation complexity before you need it is a mistake.<\/p>\n

React and Frontend<\/h2>\n

4. How does React decide when to re-render?<\/h3>\n

A component re-renders when its state changes, when its parent re-renders (even if props didn’t change, unless you’ve used React.memo<\/code>), or when a consumed context value changes. That last case is the expensive one in larger apps.<\/p>\n

Prevention: keep state close to where it’s used, split context so auth changes don’t re-render unrelated components, and use React.memo<\/code> where profiling shows actual cost – not preemptively. React.memo<\/code> itself has a comparison cost.<\/p>\n

5. What are React Server Components?<\/h3>\n

RSCs run on the server and never ship JavaScript to the browser. They fetch data, read from databases, and render HTML without touching the client bundle. They can’t use hooks or event handlers.<\/p>\n

Use them for components that are primarily a data fetch and render: a product detail page, a blog post body, a sidebar showing numbers. Don’t convert your whole app. Identify subtrees with no interactivity and move data fetching there so the client bundle shrinks.<\/p>\n

Node.js and Backend<\/h2>\n

6. How does Node.js handle concurrency on a single thread?<\/h3>\n

Node uses non-blocking I\/O and an event loop. When your code makes a database query, Node hands it off to the OS and moves on. The callback goes into the event queue when the OS signals it’s done. CPU-bound work blocks the event loop entirely – a synchronous 500ms calculation makes every request wait. The fix is worker threads or a job queue like BullMQ, not setImmediate.<\/p>\n

7. How do you design a REST API that stays clean?<\/h3>\n

Version with a path prefix (\/v1\/<\/code>, not headers – headers are harder to debug), enforce consistent error shapes across all endpoints, and commit an OpenAPI spec to the repo so CI validates it. The mess comes from five engineers adding routes with different naming conventions and error formats.<\/p>\n

Also: add cursor-based pagination from the start. Retrofitting it at 2 million rows is painful.<\/p>\n

Databases<\/h2>\n

8. PostgreSQL vs. MongoDB – when do you pick which?<\/h3>\n

The 2025 Stack Overflow Developer Survey<\/a> found PostgreSQL is used by 55.6% of professional developers – the most popular database overall. Relational structure and ACID transactions solve most problems without the consistency tradeoffs document stores introduce.<\/p>\n

Use PostgreSQL when your data has clear relationships, joins need to be correct and fast, or referential integrity matters. Use MongoDB when documents genuinely vary in shape or when you’re prototyping with a schema that’ll change constantly. The trap is choosing Mongo for “flexibility” and then building application-level joins to compensate for missing foreign keys.<\/p>\n

9. Explain database indexes – and when they slow you down<\/h3>\n

An index (usually a B-tree) lets the database find rows without a full table scan. The “hurts” part is what separates complete answers: every index slows writes, because the database updates it on every insert, update, and delete. Too many indexes on a write-heavy table can degrade write performance significantly. Also: composite indexes are left-anchored. An index on (user_id, created_at)<\/code> doesn’t help WHERE created_at > Y<\/code> alone.<\/p>\n

System Design<\/h2>\n

10. Offset vs. cursor-based pagination<\/h3>\n

Offset pagination (LIMIT 20 OFFSET 1000<\/code>) has the database scan and discard 1,000 rows. At page 5,000 it scans 100,000 rows and throws them away. Cursor-based pagination filters from a stable reference point (last seen ID or timestamp) – constant-time regardless of depth. The tradeoff: no jumping to “page 47.” For feeds and activity streams, cursor-based is the right default. For admin tools with bounded data sets, offset is fine.<\/p>\n

11. Walk me through the CAP theorem<\/h3>\n

CAP says a distributed system can guarantee at most two of: Consistency (reads see the most recent write), Availability (every request gets a response), Partition Tolerance (system works during network splits). Because partitions happen in real systems, you’re choosing between C and A during one. CP systems (HBase, Zookeeper) refuse to serve stale data. AP systems (Cassandra, DynamoDB default mode) keep serving but might return stale data. Banking needs CP. A shopping cart tolerates AP – a stale item is a UX annoyance, not a data integrity failure.<\/p>\n

\n
\n

On system design questions<\/p>\n

Interviewers are watching how you frame trade-offs and ask clarifying questions before designing. Candidates who spend the first 3 minutes confirming constraints score higher than those who jump straight to a solution. See our system design interview guide<\/a> for a structured approach.<\/p>\n<\/div>\n<\/div>\n

12. Design a URL shortener<\/h3>\n

Base-62 encoding of an auto-incrementing ID gives you predictable, collision-free short codes. Store the mapping with the short code as primary key. Cache hot codes in Redis with a TTL – most traffic hits a small fraction of total links. Use 302 redirects (not 301) if you want click analytics, since 301s get cached by the browser and bypass your server. The redirect service is read-heavy – read replicas plus Redis handles scale. The write path is low volume and a single primary handles it for a long time.<\/p>\n

13. Your API is slow. How do you diagnose it?<\/h3>\n

“I’d look at logs” isn’t an answer. First isolate: is the slowness consistent or spiky? Consistent means a baseline problem. Spiky means resource contention or a specific input hitting a slow path. For consistent slowness, add timing instrumentation at each layer and run EXPLAIN ANALYZE<\/code> on your queries – look for sequential scans. For spiky slowness, check for N+1 query patterns and connection pool exhaustion.<\/p>\n

At LastRound AI, candidates using the mock interview tool<\/a> for full-stack prep often stumble here – not because they don’t know the theory but because they haven’t verbalized a real debugging sequence before. Being asked “which logs, what are you looking for?” after you’ve said “I’d check the logs” is where the interview turns.<\/p>\n

14. Walk me through a technical decision you’d make differently<\/h3>\n

Interviewers remember this one. They want to see that you update your beliefs when you get new information. A strong answer: a specific decision, a specific outcome that revealed it was wrong, and what you’d do now. “I’d use cursor-based pagination from the start instead of retrofitting at 2 million rows” beats any abstract reflection on maintainability.<\/p>\n

If you don’t have a story like this, the honest answer is you haven’t worked at a scale where those decisions bite. That’s fine. The software developer interview questions guide<\/a> has more scenario questions to practice before your loop.<\/p>\n

\n
\n

Practice with an interviewer who asks follow-ups<\/h3>\n

LastRound AI runs live mock full-stack sessions and follows up on your answers the way a real technical interviewer would, so you can test your explanations before they matter.<\/p>\n