Full Stack Engineering Interviews: End-to-End Technical Assessment 2026

Tech interviews are hard. I’ve been through dozens of them over the years, and I’ve sat on the other side of the table too, at a company that interviewed probably 200 full stack candidates in a single hiring cycle. The thing that strikes me most, looking back, is how predictable the questions are and how unpredictably candidates answer them.

This guide covers the 37 questions I’ve seen come up most often across real full stack interviews, split by domain. It’s not a study deck. It’s an attempt to explain what the interviewer actually wants to hear, which is almost never just the textbook answer.

JavaScript fundamentals: where most people slip

These questions feel basic. They’re not. Every company I’ve seen interview for full stack roles starts here, and the failure rate on this section is surprisingly high for people with 4-6 years of experience.

• Explain how the event loop works. The right answer names the call stack, the task queue (macrotasks), and the microtask queue, and explains that Promises resolve before setTimeout callbacks even if both are queued at the same time. Most candidates describe only the call stack and stop there.
• What’s the difference between var, let, and const? Scoping and hoisting, yes, but the follow-up is usually about temporal dead zones. A lot of people stumble on that.
• How does prototypal inheritance work? Draw the chain if you can. Object.create vs. class syntax is a common follow-up.
• What is a closure and when would you use one? “A function with access to its outer scope” is technically right but too thin. The best answers give a concrete use case, like private variables in a module pattern, or memoization.
• Explain async/await and how it relates to Promises. Interviewers will often ask you to rewrite an async/await block using raw Promises to test whether you actually understand what’s happening underneath.

The thing I notice about candidates who do well in this section: they don’t just answer the question. They briefly explain why the distinction matters in real code. “You’d hit this in practice if you…” is a sentence that signals genuine experience.

React questions that separate mid-level from senior

According to the Stack Overflow Developer Survey 2024, React remains the most widely used web framework, so it’s on almost every frontend and full stack screen. The questions below are the ones that separate candidates who’ve read the docs from candidates who’ve shipped things with React at scale.

• What triggers a re-render, and how do you prevent unnecessary ones? The correct answer involves React.memo, useMemo, useCallback, and knowing when each is worth the overhead (hint: often it’s not).
• How does reconciliation work? Interviewers want to hear about the virtual DOM diffing algorithm and the role of keys in lists.
• Explain the rules of Hooks. Why can’t you call a Hook inside a loop? This is one of those questions where reciting the rule isn’t enough. You need to explain the linked-list implementation reason behind it.
• How would you handle error boundaries? componentDidCatch and getDerivedStateFromError still matter even in a Hooks world, since there’s no Hook equivalent for catching render errors yet.
• What’s the difference between controlled and uncontrolled components? And when would you choose uncontrolled? This one trips people up because they default to “always use controlled” without being able to name a legitimate case for uncontrolled.
• How do you optimize a list that renders 10,000 items? Windowing/virtualization. React Window or React Virtual. The answer should mention that you’re only rendering what’s visible in the viewport.

If you’ve shipped a production React app that handled real performance problems, these answers come naturally. If you haven’t, you’ll sound like you’re reciting documentation. Interviewers can tell the difference within about 30 seconds.

Node.js and backend questions

The backend side of a full stack interview is usually shorter than the frontend side, in my experience, but the questions tend to be more unforgiving because there are fewer ways to fake fluency.

• Explain middleware in Express. Show you know the signature: req, res, next. The best candidates also explain error-handling middleware (four arguments instead of three) without being prompted.
• What’s Node’s single-threaded model and when does it become a problem? CPU-bound work blocks the event loop. The answer is worker threads or offloading to a separate service.
• How do you handle authentication in a Node API? JWT, session tokens, httpOnly cookies, the tradeoffs between them. Where you store the token matters as much as which mechanism you use.
• How would you implement rate limiting? Token bucket, sliding window, or a library like express-rate-limit. The follow-up is usually: what happens in a distributed system with multiple Node instances?
• Describe how you’d structure a REST API for a product with evolving requirements. This is where versioning, resource naming conventions, and backwards compatibility come up. There’s no one right answer, but candidates who say “it depends” without explaining what it depends on lose points.

Database and system design

Most full stack interviews I’ve seen spend 20-30 minutes on this section. It’s where senior engineers get to demonstrate genuine depth and where mid-level engineers sometimes get in over their heads.

• When would you use a relational DB vs. NoSQL? The answer should involve access patterns, not just “SQL is structured.” Interviewers who ask this want to hear about joins, transactions, ACID guarantees, and what you give up with document stores.
• How do you approach database indexing? The honest answer is that indexes help reads and hurt writes, and you should only add them based on actual query patterns, not guesses. Candidates who say “index everything” are flagged immediately.
• Explain N+1 queries. Classic. Usually comes with a follow-up asking how to detect them in production.
• Design a URL shortener. This is a genuine system design question that shows up constantly. You need to cover hashing strategy, collision handling, storage estimates, read/write ratio, caching, and what happens at scale.
• How would you paginate a large dataset? Offset pagination vs. cursor-based pagination. The interviewer usually pushes on performance at page 50,000 to see if you know why offset pagination breaks down.

The questions candidates forget to prepare for

These show up in roughly a third of full stack interviews and catch people off guard, because they’re not purely technical.

• Tell me about a production incident you caused. Interviewers want to see accountability and structured thinking. The STAR format works here if you actually fill it with real specifics.
• How do you decide when to refactor vs. ship? There’s no right answer, but candidates who say “always refactor first” or “always ship first” tend not to get offers. The interviewer wants to hear that you think about trade-offs in context.
• How do you stay current with front-end changes? Specific blogs, specific people on Twitter, specific newsletters. Vague answers (“I just keep up with the ecosystem”) do not land well.

The Bureau of Labor Statistics projects software developer employment to grow 25% through 2032, well above average. The market is competitive but the demand is real. Preparation is the one variable you can actually control.

One last thing. Some candidates use AI interview tools during live technical screens to help formulate answers in real time. Craqly is designed specifically for this, with a desktop overlay that stays invisible to screen share. It won’t answer the questions for you, but it can surface relevant patterns and remind you of things you studied if you blank under pressure. Whether you’d use something like that is a personal call, but it exists.

What I’d tell anyone about full stack prep: the candidates who get offers aren’t necessarily the ones who know the most. They’re the ones who can explain trade-offs clearly and who sound like they’ve actually shipped something. That’s harder to fake than the answers themselves.