Full Stack Developer Interview Help: Frontend, Backend, and Everything Between

Full Stack Interviews Cover a Lot of Ground

The challenge with full stack interviews is the breadth. You're expected to know frontend frameworks, backend architecture, databases, APIs, and at least a bit of DevOps. Nobody expects you to be a world-class expert in all of them — but you need solid working knowledge across the stack and genuine depth in at least one area.

Here are the questions that come up most frequently across full stack interviews, organized by layer. Each one comes with guidance on what the interviewer is really looking for.

Frontend: JavaScript and React

1. Explain the difference between let, const, and var in JavaScript.

How to answer: var is function-scoped and hoisted (legacy, avoid it). let is block-scoped and reassignable. const is block-scoped and can't be reassigned — but objects and arrays declared with const can still be mutated. The nuance about const and mutability is what separates good answers from textbook answers. Mention the temporal dead zone with let/const for bonus points.

2. What are React hooks? Explain useState, useEffect, and useCallback.

How to answer: useState manages component state without classes. useEffect handles side effects (API calls, subscriptions, DOM manipulation) and runs after render — it replaces componentDidMount, componentDidUpdate, and componentDidUnmount. useCallback memoizes functions to prevent unnecessary re-renders when passing callbacks to child components. The key insight: useCallback is about referential equality, not performance optimization for the function itself. Mention the dependency array pitfalls — stale closures are a common source of bugs.

3. How does the virtual DOM work? Why does React use it?

How to answer: React maintains an in-memory representation of the actual DOM. When state changes, React creates a new virtual DOM tree, diffs it against the previous one (reconciliation), and applies only the minimal set of changes to the real DOM. Direct DOM manipulation is expensive — batching updates through the virtual DOM is faster for most use cases. Mention that this isn't universally true — frameworks like Svelte compile away the virtual DOM entirely and can be faster for certain patterns.

4. Explain the event loop in JavaScript. How do promises and async/await fit in?

How to answer: JavaScript is single-threaded. The event loop processes the call stack, then checks the microtask queue (promises, queueMicrotask), then the macrotask queue (setTimeout, setInterval, I/O). Promises always resolve before setTimeout callbacks, even if the timeout is 0. async/await is syntactic sugar over promises — it doesn't change how the event loop works, it just makes async code read synchronously. Give a concrete example: "What's the output of this code?" questions are common.

5. What's the difference between client-side rendering, server-side rendering, and static site generation?

How to answer: CSR sends a minimal HTML shell and JavaScript builds the page in the browser — fast subsequent navigations but slow initial load and poor SEO. SSR renders HTML on the server for each request — good for SEO and first paint but higher server cost. SSG pre-builds HTML at build time — fastest but only works for content that doesn't change per-request. Most modern apps use a hybrid — Next.js lets you mix all three approaches per page. Choose based on the page's content dynamism and SEO requirements.

Backend: APIs and Server Logic

6. REST vs GraphQL — when would you choose each?

How to answer: REST is simpler, well-understood, and great when your data model maps cleanly to resources. GraphQL shines when clients need flexible queries (mobile vs. web wanting different data), when you have deeply nested relationships, or when over-fetching/under-fetching is a real problem. The tradeoff: GraphQL adds complexity on the server (resolvers, schema management, N+1 query problems) and makes caching harder. Don't just say "GraphQL is better" — show you understand when each fits.

7. How do you handle authentication and authorization in a web application?

How to answer: Authentication: JWT tokens (stateless, stored in httpOnly cookies not localStorage), session-based auth (server stores session, client gets a cookie), or OAuth 2.0 for third-party providers. Authorization: RBAC (role-based access control) for most apps, ABAC for complex permission models. Key security points: httpOnly and Secure flags on cookies, refresh token rotation, CSRF protection for cookie-based auth, rate limiting on login endpoints. Mention that JWTs have a revocation problem — you can't invalidate them without a blacklist or short expiry.

8. Explain middleware in Express/Node.js. How have you used it?

How to answer: Middleware functions have access to the request, response, and next function. They execute in order and can modify the request/response, terminate the cycle, or pass to the next middleware. Common uses: authentication checks, request logging, CORS handling, rate limiting, error handling, request body parsing. Show you've built custom middleware — "I wrote a middleware that validated API key scopes against route permissions" is much stronger than just describing what middleware is.

9. What happens when you type a URL in the browser and press Enter?

How to answer: DNS resolution (browser cache → OS cache → recursive resolver → root/TLD/authoritative servers), TCP connection (three-way handshake), TLS handshake (if HTTPS), HTTP request sent, server processes request (routing, middleware, controller, database queries), HTTP response returned, browser parses HTML (constructs DOM), fetches linked resources (CSS, JS, images), renders the page (CSSOM + DOM = render tree → layout → paint). The depth you go into depends on the role — backend roles care about the server side, frontend roles care about the rendering pipeline.

Databases

10. SQL vs NoSQL — how do you decide?

How to answer: SQL (PostgreSQL, MySQL) when you have structured data with clear relationships, need ACID transactions, and your query patterns are well-defined. NoSQL (MongoDB, DynamoDB, Redis) when your schema evolves frequently, you need horizontal scalability, or your data is naturally document-shaped or key-value. The honest answer: most applications work fine with PostgreSQL. Don't reach for NoSQL unless you have a specific reason. Mention the CAP theorem if relevant — consistency vs. availability tradeoffs in distributed databases.

11. What's database indexing? How do you decide what to index?

How to answer: An index is a data structure (usually B-tree) that speeds up reads at the cost of slower writes and extra storage. Index columns that appear in WHERE clauses, JOIN conditions, and ORDER BY clauses. Don't index everything — each index slows down INSERT/UPDATE operations. Composite indexes matter — an index on (user_id, created_at) covers queries filtering by user and sorting by date. Use EXPLAIN to verify your indexes are actually being used. Mention covering indexes if you want to go deeper.

12. Explain database normalization vs denormalization. When would you choose each?

How to answer: Normalization eliminates data redundancy (3NF: no partial or transitive dependencies). Denormalization adds controlled redundancy for read performance. Normalize when data integrity is critical and writes are frequent. Denormalize when read performance matters more and you can tolerate some data duplication. In practice, most production databases are somewhere in between — normalized core tables with materialized views or cache layers for read-heavy access patterns.

DevOps and Infrastructure Basics

13. Explain Docker and containerization. Why is it useful?

How to answer: Docker packages your application with all its dependencies into a standardized unit (container) that runs identically everywhere. Containers are lighter than VMs because they share the host OS kernel. Benefits: consistent development/staging/production environments ("works on my machine" problem solved), easy scaling, fast startup. Mention Dockerfiles, images vs containers, and docker-compose for multi-service local development. If you've used Kubernetes for orchestration, mention it but don't deep-dive unless asked.

14. What's CI/CD? Describe a pipeline you've set up or worked with.

How to answer: Continuous Integration: automatically build and test code on every commit. Continuous Deployment: automatically deploy to production after passing tests. A typical pipeline: push to GitHub → run linting → run unit tests → run integration tests → build Docker image → deploy to staging → run E2E tests → deploy to production. Mention tools you've used (GitHub Actions, GitLab CI, Jenkins). The best answers include specific improvements you made — "I reduced our pipeline time from 45 minutes to 12 by parallelizing test suites and caching dependencies."

System Design Fundamentals

15. How would you design the backend for a simple e-commerce app?

How to answer: Core services: user management, product catalog, cart, order processing, payment integration. Database schema: users, products, orders, order_items, payments. Key considerations: inventory management (race conditions when multiple users buy the last item — use optimistic locking or database constraints), payment processing (never process the same payment twice — idempotency keys), and order status management (state machine: pending → paid → fulfilled → shipped → delivered). Start monolithic, extract services if and when specific bottlenecks emerge.

16. What's caching? How would you implement it in a web application?

How to answer: Caching stores frequently accessed data in a faster layer to reduce database load and response times. Layers: browser cache (Cache-Control headers), CDN (static assets, API responses), application cache (Redis/Memcached for database query results, session data), database cache (query cache, buffer pool). Key decisions: cache invalidation strategy (TTL, write-through, write-behind, cache-aside), what to cache (expensive queries, rarely changing data), and what NOT to cache (user-specific real-time data, security-sensitive information). "There are only two hard things in computer science: cache invalidation and naming things."

Behavioral Questions for Full Stack Roles

17. Tell me about a time you had to learn a new technology quickly for a project.

How to answer: Full stack developers do this constantly. Pick a specific example — maybe you learned GraphQL in a week for a project, or picked up Kubernetes when your team moved to container orchestration. Focus on your learning approach (docs first vs. build a prototype vs. pair with an expert) and the outcome.

18. How do you decide between building something from scratch vs using a third-party service?

How to answer: Build when the feature is core to your product and competitive advantage. Buy/integrate when it's commodity (auth, payments, email sending, monitoring). Consider: maintenance burden, cost at scale, vendor lock-in, and time to market. Real example: "We built our own analytics pipeline because the data was our product. But we used Stripe for payments because building payment processing would have been months of work with no business differentiation."

Preparation Strategy

Don't try to study everything equally. Identify the company's stack (check their job posting, tech blog, and GitHub repos) and weight your prep accordingly. A company using Python/Django needs different preparation than one using TypeScript/Next.js.

Build something small that touches every layer — a full stack todo app with auth, database, API, and deployment is boring but covers all the bases. The experience of deploying something end-to-end is worth more than reading about it.

Practice explaining your architectural decisions out loud. Full stack interviews love "walk me through how you'd build X" questions, and your ability to articulate tradeoffs matters as much as your technical knowledge. Craqly's AI interview copilot can provide real-time feedback as you work through these design problems, helping you sharpen both your technical thinking and your communication.

And remember — nobody expects you to be equally strong across the entire stack. Know your strengths, be honest about your growth areas, and show genuine curiosity about the parts you're still learning. Start your full stack interview prep with Craqly for a structured plan that covers all layers.