Full-Stack Questions
How to Use This Question Bank
What interviewers expect at 4+ years, how the questions are grouped, and a one-page map of every topic.
On this page
In one line: at four or more years, an interviewer is not checking whether you know the words. They want to hear why you choose something, what it costs, and what breaks first. This question bank is built to help you answer in that way.
What changes at 4+ years
A junior question is "What is a hook?" A question for four years or more is "A page re-renders too often. How do you find out why, and how do you fix it without making the code harder to read?"
Interviewers listen for four things:
| They listen for | What a good answer sounds like |
|---|---|
| A clear definition | One or two plain sentences, no buzzwords. |
| A trade-off | "This is faster, but it costs memory." "This is simpler, but it does not scale past one server." |
| A real example | A small number, a bug you have seen, or a short piece of code. |
| Honesty about limits | "I would measure first." "I have not used that in production, but here is how I would test it." |
You do not need to know everything. You need to show that you can reason, measure and say what you do not know.
How the questions are marked
Every lesson ends with an Interview questions section. Click a question to see a model answer, written the way you could say it out loud. Many answers carry one of three tags:
- Must know: almost every interviewer asks it. Get these right first.
- Senior signal: the question that separates a 2-year answer from a 4-year answer.
- Trap: a popular but wrong or out-of-date answer. Knowing the trap shows you have used the tool.
Map of the lessons
| Lesson | Topic | What it covers |
|---|---|---|
| 1 | HTML & CSS | Semantics, the cascade, flexbox, grid, container queries, stacking contexts |
| 2 | Tailwind CSS | v4 setup, how classes are generated, merging, design tokens |
| 3 | TypeScript | Generics, narrowing, utility types, tsconfig, typing React and APIs |
| 4 | React | Component design, hooks, performance, forms, React 19, code review |
| 5 | Next.js | App Router, Server Components, caching, Server Actions, proxy |
| 6 | Node.js & Express | Event loop, streams, workers, Express 5, security, shutdown |
| 7 | MongoDB | Schema design, indexes, aggregation, transactions, sharding |
| 8 | Prisma & SQL | Prisma 7, migrations, relations, N+1, transactions, SQL |
| 9 | Hasura & GraphQL | Permissions, remote schemas, events, subscriptions, GraphQL basics |
| 10 | LLMs, agents, RAG | Agent vs agentic AI, workflows, harness, MCP, RAG, evaluation |
| 11 | Vercel AI SDK | Streaming, tools, structured output, multi-step loops, testing |
| 12 | Meilisearch & Mixpanel | Search relevance and security; events, identity, funnels |
| 13 | Popular libraries | TanStack Query, Zustand, Zod, forms, auth, Redis, Stripe, testing |
| 14 | The experience round | Ownership, trade-offs, stories, code review, system design lite |
| 15 | JavaScript core | Types and coercion, prototypes, classes, this, copying, iterators, modules, newer methods |
| 16 | Async JavaScript | Event loop puzzles, promises, concurrency, cancellation, race conditions |
| 17 | JavaScript coding round | Polyfills and utilities you are asked to write, with tested solutions |
| 18 | Redis and caching | Cache patterns, TTL, stampedes, eviction, locks, rate limiting |
| 19 | Queues and webhooks | BullMQ, retries, idempotency, outbox, webhook signatures |
| 20 | Realtime | WebSocket vs SSE vs polling, Socket.IO, scaling, auth |
| 21 | Testing tools | Jest, Vitest, Testing Library, MSW, Playwright |
| 22 | Auth libraries, OAuth, OIDC | PKCE, tokens, Auth.js, Better Auth, RBAC, passkeys |
| 23 | Payments and integrations | Stripe, S3 uploads, email, retries and circuit breakers |
| 24 | Git and monorepos | Merge vs rebase, recovery, workflows, pnpm and Turborepo |
| 25 | State and data libraries | Redux Toolkit, TanStack Query, Zustand, forms |
| 26 | Deployment and monitoring | Vercel, Docker, CI/CD, Sentry, OpenTelemetry, SLOs |
| 27 | SEO, i18n, PWA, PostgreSQL | Metadata, locales, service workers, SQL and locks |
For deeper background, these earlier series pair well with this one: Senior Frontend Depth, Backend in Depth, Scenario Debugging, Practical Design Problems and Browser & Web Fundamentals.
How this bank was built
- Each lesson was written from the project's own documentation and source code, and from long-standing, widely used interview-question collections. Brand-new or thinly maintained sources were left out.
- Every code sample was run or compiled against the real packages (current stable versions at the time of writing). Where something could not be run, such as a database server or a hosted service, the lesson says so.
- Many popular interview answers online are out of date. Each lesson marks those traps. Here are the ones that surprise people most:
| Old answer people still give | What is true now |
|---|---|
"Put scripts just before </body>." | Use defer in the head. |
"z-index: 9999 fixes stacking." | The cause is a stacking context. Fix that. |
"Tailwind needs a content array and tailwind.config.js." | Tailwind v4 is CSS-first with @theme and finds files by itself. |
"The React Compiler means you never need useMemo." | The compiler is a separate opt-in tool, and the hooks remain an escape hatch. |
| "Objects are passed by reference in JavaScript." | JavaScript always passes by value. For objects, the value is a reference. |
"Deep copy with JSON.parse(JSON.stringify(x))." | structuredClone keeps Date, Map, Set and cycles. |
"fetch is cached by default in Next.js." | Not since Next.js 15. In 16 you opt in with use cache. |
"middleware.ts handles requests." | It is proxy.ts now, on the Node.js runtime. |
"npm i prisma gives the stable version." | It can install a release candidate. Pin the version. |
"prisma.$use middleware." | Removed. Use client extensions. |
"nextTick always runs first." | In an ES module, a resolved promise runs first. |
"CMD [\"npm\",\"start\"] is fine in Docker." | It can swallow SIGTERM, so shutdown never runs. |
"alias() links Mixpanel users." | That is the legacy way. Use identify with simplified ID merge. |
| "Temperature 0 means the same answer every time." | Not in practice. |
| "AI agent and agentic AI are two defined terms." | There is no standard definition. Say what you mean. |
A two-week plan
- Days 1–3: JavaScript core and async (lessons 15 and 16), HTML & CSS, Tailwind, TypeScript. Do the "must know" questions out loud.
- Days 4–6: React and Next.js. Re-read the traps, then rebuild one small example from memory.
- Days 7–9: Node.js, MongoDB, Prisma and SQL, Hasura and GraphQL.
- Days 10–11: LLMs, agents and RAG, then the AI SDK. Be ready to explain the two meanings of "harness".
- Day 12: Meilisearch, Mixpanel and the library lesson.
- Days 13–14: The experience round and the JavaScript coding round (lesson 17). Say three stories out loud with real numbers, write two utilities from memory, then do two mock interviews with a friend.
- Days 15–17 (extras): Redis, queues and realtime (lessons 18 to 20), then testing, auth and payments (21 to 23), then Git, state libraries, deployment and SEO/PostgreSQL (24 to 27). Pick the ones that match the job description first.
Interview questions
What do interviewers look for at four years that they do not look for at two?
They look for judgement. At two years it is enough to know how a tool works. At four years they want to know when you would not use it, what it costs, and how you would find out if it was the wrong choice. I try to answer with a definition, a trade-off and a short example, in that order.
A question has several correct answers. How do you pick one?
I first ask one or two clarifying questions: how big is the data, how many users, what is the deadline. Then I give the simple option and say why it is enough for now. Then I say what would make me change it. That shows I do not over-build and that I know the next step.
You do not know the answer. What do you do?
I say so, plainly, and then I reason from what I do know. For example: "I have not used that library, but it sounds like it solves the same problem as X. I would check the docs for how it handles failure, and I would test it with a small example first." Honest reasoning scores higher than a confident guess that turns out wrong.
How do you show experience without a long story?
I use numbers and one concrete detail. "The page loaded in 4.2 seconds. I found a 600 KB library used in one place, loaded it lazily, and got it to 2.1 seconds." The numbers make it believable, and the detail shows I did the work myself.
Should you memorise the answers in this bank?
No. Read the definition and the trade-off, then close the page and explain it in your own words. If you can explain why the trap is a trap, you will handle a version of the question you have never seen.
How should you use the "trap" questions?
As a checklist of things that have changed. If you worked with an older version, say so: "Before version 15, fetch was cached by default. Now you opt in." That shows you have used the tool for a long time and kept up with it.
What if the interviewer asks about a tool you have never used?
I connect it to something I know, and I say that I am doing so. "Meilisearch is a search engine, so I would think about it like Elasticsearch: indexes, documents, ranking. The main thing I would check is how it handles typos and how to keep it in sync with the database." Then I ask what they use it for.
How do you end an answer well?
With one sentence about how you would check it. "I would confirm it with the profiler." "I would add a test that fails without the fix." "I would watch the error rate for a day." It tells the interviewer that you treat your own answers as claims to prove.
Published by Jainik · Last updated · How these lessons are made
Keep learning
Part of the study guide
Related series