Full Stack Developer Interview Questions
Full stack interviews live at the seams: where the browser meets the API, where auth crosses layers, where a feature spans database to pixel. Depth in one layer plus fluency across all of them beats shallow coverage of everything.
Q1Walk me through everything that happens between typing a URL and seeing the page.
What they're checking: The classic breadth check — where you go deep reveals your strengths.
A strong answer: DNS → TCP/TLS → request → server → response → parse → render is table stakes. Strong candidates pick two stages and go genuinely deep — say, TLS handshake details and the browser render pipeline.
Q2Design authentication for a SPA + API. Where do tokens live and why?
What they're checking: Security trade-off literacy — there is no perfect answer, only defended choices.
A strong answer: HttpOnly cookies (CSRF-protected) vs memory-held JWTs (XSS-exposed refresh flows) — pick one, defend it, and mention refresh rotation and logout-everywhere as the hard parts.
Q3Your feature needs a new field from database to UI. Walk through every layer you touch.
What they're checking: Whether you actually ship end-to-end or hand off at a boundary.
A strong answer: Migration → model → API contract (and versioning consequences) → client types → state → component → tests at each layer. Bonus: rollout order so old clients never break.
Q4How do you keep types in sync between backend and frontend?
What they're checking: Whether contract drift has bitten you and what you did about it.
A strong answer: Schema-first options (OpenAPI codegen, GraphQL, tRPC for TS monorepos) with honest trade-offs — codegen freshness, build coupling — beats "we are careful".
Q5Where should validation live — client, server, or database?
What they're checking: Defence-in-depth thinking versus dogmatism.
A strong answer: All three, with different jobs: client for UX, server as the source of truth, database constraints as the last line. Sharing one schema definition across layers is the mature answer.
Q6A user reports "the page is slow". How do you find out which layer is guilty?
What they're checking: Systematic debugging across the whole stack.
A strong answer: Reproduce, then bisect with evidence: browser devtools waterfall → API timing → database query plans. Say what you would measure at each step, not just the tools you would open.
Q7Explain optimistic UI updates. When are they the wrong choice?
What they're checking: UX-engineering judgement across the client-server boundary.
A strong answer: Apply locally, reconcile on response, roll back on failure. Wrong when failure is common or irreversible — payments, sends — where a fake success is worse than a spinner.
Q8How would you deploy a breaking API change without breaking mobile clients you cannot force-update?
What they're checking: Real-world versioning discipline.
A strong answer: Never break: additive changes, tolerant readers, versioned endpoints when unavoidable, deprecation windows measured against client update lag — and telemetry on old-version usage before removal.
Now try answering these under interview pressure
InterviewGPT runs a mock Full Stack interview — asks questions like these tailored to your situation, listens to your spoken answers, and scores every one with written feedback. First session free, no credit card.
Start a free Full Stack interview