You push a change and 5 minutes later you see a spike in 500 errors and your error rate goes from 0.1% to 8%. What do you do?

First action: immediately check if you can roll back the deployment — most modern deployment platforms (Vercel, Railway, Render) have a one-click rollback. If rollback is safe and fast, do it before investigating. The cost of 5 more minutes of investigation at 8% error rate usually exceeds the cost of rolling back and re-deploying later. Then investigate: pull the error traces and look at the stack — is it a null pointer in your new code, a schema mismatch, a missing environment variable? Communicate to stakeholders that you are aware and investigating. After mitigation, write a brief postmortem: what changed, what broke, what you will add to prevent this (a staging environment test, a canary deploy, a database migration test).

What does "component renders" mean in React, and what causes unnecessary re-renders?

A React component renders when its state changes, when its props change (by reference equality, not deep equality), or when its parent re-renders — even if the props did not change. A render is React calling the component function and computing the new virtual DOM. It does not necessarily update the real DOM if the virtual DOM diff shows no change. Unnecessary re-renders happen when: a parent re-renders and passes a new object/array literal as a prop (creates a new reference on every render); a Context provider value changes; useEffect dependencies change on every render due to unstable references. Fixes: React.memo to skip re-render if props are shallowly equal; useMemo to memoize expensive computations; useCallback to stabilize function references passed as props; moving state down to only the components that need it.

How do you handle authentication in a full-stack app — specifically, where do you store the JWT and why?

Store the JWT in an HttpOnly, Secure, SameSite=Strict cookie — not localStorage. Reason: HttpOnly cookies are not accessible to JavaScript, so a cross-site scripting (XSS) vulnerability cannot steal the token. localStorage JWTs are vulnerable to any XSS on your page, including XSS in a third-party script you loaded. The tradeoff with cookies: you need CSRF protection (SameSite=Strict handles most cases; add a CSRF token for non-GET mutation endpoints). For API-only backends (mobile app clients), where cookies are less natural, use short-lived access tokens (15 minutes) stored in memory, paired with a longer-lived refresh token in an HttpOnly cookie. Implement token refresh on 401 response. For logout, clear the cookie server-side (set it to an empty value with an expired date) — do not rely on the client to delete it.

How do you decide, for a given feature, whether to fetch data on the server (SSR) or the client?

Server-side data fetching (SSR or RSC): use when (1) the page needs to be indexable by search engines and the content is meaningful for SEO; (2) the data is available at request time and relatively stable (product pages, blog posts, user profiles); (3) you want the page to be complete on first load (no loading spinners for the initial content). Client-side data fetching: use when (1) the data is user-specific and not meaningful for SEO (dashboard, settings); (2) the data changes frequently and needs to stay fresh (real-time feeds, live counts); (3) the fetch is triggered by user interaction (search results, pagination). The mixing pattern: SSR the layout and above-the-fold content, hydrate and client-fetch the personalized or dynamic parts. In Next.js App Router: use async server components for server fetching, useQuery (React Query) or SWR for client fetching.

Implement a debounced API search with React. Handle loading, error, and empty states.

State: query (string), results (array), isLoading (boolean), error (Error | null). Debounce: useEffect with a setTimeout cleanup. Stale request cancellation: AbortController in the effect, cancel on cleanup. Minimum query length: only fire the request when query.length >= 2. Error boundary or try/catch around the fetch. Empty state: distinguish "no results for this query" from "type to search" — these should display different UI. Accessibility: use role="status" or aria-live on the results area so screen readers announce when results change. TypeScript: type the response shape with an interface, not "any."

Tell me about a time you owned a feature end-to-end. What was the hardest technical decision you made?

Pick a feature where you made a meaningful technical choice that could have gone the other way. Set the context (what the feature was, what the constraints were), then describe the decision — specifically, two options you considered, why you chose one, and what you gave up. Common real decisions for full-stack engineers: chosen database schema design that turned out to be hard to query, API design that needed to support both web and mobile clients, a state management approach that did not scale with the UI complexity. Close with the outcome and what you would do differently.

What is CORS and why does it exist? How do you configure it correctly without disabling it?

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts which origins can make requests to your API. It exists because browsers enforce the Same-Origin Policy — JavaScript on origin A cannot read responses from origin B without explicit permission from B. For simple GET requests, the browser sends the request and checks the response headers. For "preflighted" requests (non-simple methods like POST, PUT, DELETE, or requests with custom headers), the browser sends an OPTIONS request first and checks the Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers response headers before sending the actual request. Correct configuration: list specific allowed origins (not *) for authenticated endpoints; * is acceptable only for public read-only APIs; Access-Control-Allow-Credentials: true requires a specific origin, not a wildcard; configure CORS at the server level (Express cors() middleware, nginx headers), not per-route.

How do you structure a project's database schema for a multi-tenant SaaS application?

Three models: (1) Shared schema with tenant_id column — every table has a tenant_id, all tenants share one database. Cheapest to operate, scales to thousands of tenants, but requires rigorous Row Level Security (PostgreSQL RLS) or application-level filtering to prevent data leakage. Risk: missing a WHERE tenant_id = ? clause anywhere causes a multi-tenant data breach. (2) Separate schema per tenant — one database, multiple PostgreSQL schemas (search_path). Better isolation than (1), easier backup per tenant, but schema migrations must be applied to all tenant schemas. (3) Separate database per tenant — full isolation, best for enterprise compliance, but expensive and hard to scale to many tenants. Choice for early-stage SaaS: shared schema with RLS is almost always correct. Choice for enterprise contracts with strict data residency requirements: separate database. Implement at the application level: use a middleware that injects tenant context on every request so no route handler can accidentally query without it.

When a full-stack role says "you lean frontend" or "you lean backend," how do you think about which side to emphasize in your prep and in the interview?

Be honest about your lean: "I lean backend — I have designed distributed systems and built APIs at scale, and my React experience is solid for building product UIs but not deep on React internals or performance optimization." Then show you know what "credible on the other side" means: for a backend-leaning candidate, it means understanding component design, state management patterns, and how to read a React component and review it for correctness and performance. For a frontend-leaning candidate, it means understanding database indexing, API design principles, and being able to reason about a production incident in a backend service. Tell the interviewer your lean proactively in the hiring manager screen — it sets calibration and shows self-awareness.

How do you test a full-stack feature — what is your testing strategy across database, API, and UI?

Layer by layer: database — seed test data, run migration tests, verify constraints and triggers work correctly. API — integration tests against a real (test) database, not mocks; test the full request-response lifecycle including authentication middleware and error responses; use a test database transaction per test case, roll back after. Frontend — unit tests for business logic in hooks and utilities; component tests with React Testing Library for user-visible behavior (not implementation details); one or two end-to-end tests with Playwright or Cypress for the critical paths (sign in, create a record, see it in the list). What to skip: avoid mocking the database in API tests — you lose confidence that the SQL is actually correct. Avoid snapshot tests for UI — they break on every style change and add no signal.

Tell me about a time you had competing priorities — a product manager wanted a feature shipped, but you identified a technical debt that would make it slower and buggier if not addressed first. What did you do?

Name the specific debt and quantify the risk concretely: "This data model will require three JOIN queries per page load — at current traffic that is 200ms of added latency, but at projected traffic in 3 months it is 2 seconds." Then describe your decision to the PM in those business terms, not technical ones. Propose a concrete plan: ship with the debt but schedule a refactor sprint in the next cycle, or ship a partial fix this sprint with a documented plan for the rest. Avoid the two failure modes: blocking the ship indefinitely for perfectionism, or shipping silently and letting the debt accumulate.

What is the difference between a web socket and server-sent events, and when do you use each?

WebSockets: full-duplex, bidirectional communication over a single TCP connection. Use for real-time bidirectional needs — chat, multiplayer games, collaborative editing (multiple clients sending and receiving simultaneously). Cons: more complex server setup, stateful connection, requires careful scaling (sticky sessions or a Redis pub/sub layer). Server-Sent Events (SSE): unidirectional — server pushes to client, client sends data via regular HTTP requests. Built on top of HTTP, works through proxies and load balancers that support HTTP/2, simpler to implement. Use for server-push use cases: live dashboards, notification feeds, progress updates, stock tickers where the client only receives. SSE reconnects automatically on connection drop; WebSocket requires client-side reconnect logic. For most dashboards and notification systems, SSE is the simpler and correct choice. For chat or collaborative features, WebSocket.

Do you have questions for us?

For the hiring manager: "What does end-to-end ownership look like here — do full-stack engineers own the database schema and API design, or are those done by dedicated backend engineers?" For a senior engineer: "What is the biggest cross-stack problem the team is working on right now — something where frontend and backend concerns interact in a complicated way?" For anyone: "How do you handle feature work that requires changes on both the API and the frontend when different engineers lean different ways — is there a review process or a designated owner?"

How do full stack developer interviews differ from software engineer interviews?

Software engineer interviews typically go deeper on algorithms and systems design at scale. Full stack interviews go broader — both frontend and backend — and specifically test whether you can own a feature end-to-end. The algorithm component is usually lighter (LeetCode easy to medium), while the systems design component is more product-focused (build X feature, not design Twitter at a billion users).

Do I need to know both React and Node.js, or can I use different frameworks?

Check the job description carefully — it will name the stack. If it says "React + Node.js" and your experience is Vue + Django, your competence in the underlying concepts matters more than the specific framework, but you need to demonstrate you can get productive quickly. Most interviewers will accept a brief "I use Vue, but the concepts transfer — here is how I would approach this in React" provided you actually know what you are doing.

What should I submit in a full-stack take-home to stand out?

Three things stand out: (1) real error handling across all layers — not just the happy path; (2) a clear README that explains your architecture choices, what you would do with more time, and any tradeoffs you made; (3) the database migration or schema setup scripted and repeatable — not "just run these SQL commands manually." Reviewers are imagining what your PRs will look like on the team — completeness and communication matter as much as cleverness.

How do I handle a full-stack interview when I am much stronger on one side?

Disclose your lean early — ideally in the hiring manager screen: "I lean backend, with strong frontend competence for product UI." This calibrates the interviewer and lets you show depth where you are strong. Trying to fake equal strength on both sides fails when the technical questions expose the gap. Most companies hiring full-stack engineers know specialists lean one way and are comfortable with it — they are hiring for ownership, not equal seniority on both sides.

Are full stack developer roles actually full stack in 2026, or are they just frontend roles?

It varies significantly. At early-stage startups, full-stack typically means owning everything. At growth-stage companies, full-stack engineers often focus more on one side as the team specializes. At large companies, "full-stack" often means a frontend-leaning role that can touch APIs. Before accepting a role or even investing in the interview process, ask explicitly: "What percentage of my time would be on frontend vs. backend work, and who owns the database schema?" The answers reveal what the role actually is.

Technology$80,000 - $170,000

Full Stack Developer Interview Questions

What 2026 full stack interviews actually look like

Full stack interviews are not two half-interviews stitched together — they test whether you can own a feature end-to-end: database schema, API design, React component, deployment. The challenge is that interviewers will probe depth on whichever side your resume implies you are stronger. These questions and frameworks cover both sides plus the architectural judgment that defines a senior full stack engineer.

Typical rounds

End-to-end time

3-5 weeks

Questions covered

What the Full Stack Developer interview loop actually looks like

Recruiter Screen

• Phone call• 30 min

Stack breadth (React/Vue + Node/Python/Go), whether you lean frontend or backend, and what kind of full-stack ownership you have had. Expect to be asked about the biggest end-to-end feature you shipped.

Hiring Manager Screen

• Video call• 45 min

One feature you built end-to-end — the database schema, the API design, the frontend component, and the deploy. They want to know how you make decisions across the stack, not just whether you can do each piece.

Technical Take-Home or Live Coding

• Take-home (24-48 hrs) or 90-minute live session• 90 min

Build a small but complete feature — typically a CRUD interface with a real API and a database. The evaluators look at all three layers, but they will scrutinize the layer corresponding to your claimed strongest side.

Technical Loop

• 3-4 back-to-back sessions• 180 min

1 frontend depth (JavaScript, React, browser internals), 1 backend depth (API design, database, distributed systems basics), 1 systems/architecture (how would you build X end-to-end), 1 behavioral.

Final / Cross-functional

• Video call with a product or engineering leader• 45 min

Communication, prioritization, and how you make tradeoffs when frontend and backend concerns conflict. They are evaluating whether you can ship independently without hand-holding.

14 Full Stack Developer interview questions

Tap any question to see what the interviewer is really asking, how to structure your answer, and the red flags to avoid.

What they're really asking

Can you think through an entire feature without gaps? This question surfaces whether you know the correct upload pattern (direct-to-S3, not through your API server), the database schema change required, the frontend UX considerations, and the API contract.

Answer framework

Frontend: file input with preview, client-side validation (file type, size limit), progress indicator. API: do not pipe the file through your Node/Python server — get a presigned S3 URL from your backend, upload directly from the browser to S3 (avoids saturating your API server bandwidth), then call your API to confirm upload and update the user record. Backend: POST /me/avatar/upload-url generates a presigned PUT URL (30-second expiry), POST /me/avatar/confirm updates the user's avatar_url in the database. Database: add avatar_url column to users table, nullable. Image processing: trigger a Lambda or background job on S3 PutObject event to resize to standard dimensions and strip EXIF metadata. CDN: serve from CloudFront, not raw S3. Security: validate MIME type server-side (not just client-side), use content-type in the presigned URL to prevent MIME spoofing.

What a strong answer signals

You propose presigned URLs without prompting — this is the standard production pattern. You address EXIF metadata stripping (privacy concern). You mention CDN for serving, not raw S3. You handle the database schema change.

Red flags to avoid

•Piping the file through your API server — does not scale, saturates bandwidth
•No mention of client-side and server-side size/type validation
•Not addressing what happens if the S3 upload succeeds but the API confirmation call fails

How Full Stack Developer hires actually get decided

Approximate weight hiring committees place on each dimension. Use this to focus your prep on what actually moves the decision.

End-to-end ownership and architecture judgment

35%

Can you design a feature across database, API, and UI without hand-holding? This is what "full stack" actually means in practice and is evaluated through the take-home and the systems design round.

Depth on the company's weighted side

25%

Every company weights one side more — usually whichever side has the current bottleneck. The depth evaluation is approximately as demanding as a dedicated frontend or backend screen on that side. Prepare accordingly.

Breadth and credible competence on the other side

20%

You do not need to be a specialist on your weaker side, but you must be able to write correct code, review a PR, and identify obvious problems. "I don't do frontend" is a fast-fail for a full-stack role.

Behavioral and independence signal

12%

Can you ship features independently without escalating every cross-stack decision? Full-stack engineers are hired specifically because they reduce coordination overhead — candidates who need a dedicated backend or frontend partner for every feature reduce the return on the hire.

Security and production readiness awareness

Auth patterns, CORS configuration, input validation, SQL injection prevention. Full-stack engineers control more of the attack surface than specialists — awareness of security at each layer is weighted accordingly.

How to prepare for a Full Stack Developer interview

Find out which side the company actually cares about before your screen

Despite the "full stack" title, most companies weight one side more heavily. Check the job description for verb density: if it leads with "React component architecture" and mentions database in passing, expect frontend depth questions. If it leads with "API design, PostgreSQL, distributed systems" and mentions React as needed, expect backend depth. Calibrate your prep accordingly — spend 60% of your prep time on their weighted side.

Build one complete feature with all layers before the take-home

Build a small but complete app: a task list with a real database (PostgreSQL, not JSON files), a real API (Express or FastAPI), a real React frontend with loading/error states, and deployed somewhere (Railway, Render, or Vercel). The purpose is muscle memory — you should be able to build a feature across all layers without friction during a take-home. Candidates who have only built frontend apps in isolation struggle to wire up a backend under time pressure.

Know the security fundamentals across the stack

Full-stack engineers are responsible for security at every layer: XSS prevention (CSP headers, escaping in templates), SQL injection prevention (parameterized queries — never string interpolation), CSRF protection (SameSite cookies, CSRF tokens), auth token storage (HttpOnly cookies, not localStorage), and CORS configuration. Interviewers at security-conscious companies ask one security question per layer. Knowing the name of the vulnerability and the fix demonstrates the level of carefulness hiring managers want in a full-stack owner.

Practice talking through architecture decisions out loud

Full-stack architecture questions — "how would you build X end-to-end" — require real-time narration of decisions across the stack. The traps are: starting with a specific technology before clarifying requirements, jumping to implementation before addressing the data model, and going quiet for 30 seconds while you think. Practice with a timer: take a real product feature you know well, and narrate the full-stack design in 10 minutes with no pauses longer than 5 seconds.

Know TypeScript enough that type errors do not slow you down in a live screen

Full-stack take-homes and live screens increasingly default to TypeScript. Candidates who spend their time fighting type errors instead of building features signal that they do not use TypeScript in daily work. Practice building with strict TypeScript — no "any" — on a personal project. At minimum, know how to type API request/response shapes, React component props, and hook return values.

Full Stack Developer interview FAQs

More for Full Stack Developers

Full Stack Developer resume example Full Stack Developer cover letter Full Stack Developer salary guide Skills for Full Stack Developers How to become a Full Stack Developer

Interview prep for related roles

Software Engineer interview questions

Technology • $80,000 - $180,000

Frontend Developer interview questions

Technology • $70,000 - $150,000

Backend Developer interview questions

Technology • $80,000 - $160,000

Data Analyst interview questions

Technology • $60,000 - $120,000