Full Stack Engineer Interview Questions (2026)

Name your center of gravity plainly and back it with the kind of work you are trusted with there. For the weaker layers, describe your competence honestly and your compensating behaviors: when you pull in a specialist for review, the resources you learn from, a recent example of closing a gap deliberately. Teams are hiring the judgment to know what you do not know as much as the skills themselves.

Describe the filter: deep updates only on the layers you ship daily; headlines elsewhere until a project demands depth, then learn against the real problem. Name your inputs concretely (a couple of newsletters or repos you actually follow, not a recited list) and one recent example of just-in-time depth — learning enough Postgres partitioning or React streaming for the feature at hand. Acknowledging that nobody covers it all, and that the skill is fast targeted ramp-up, is the senior answer.

Calibrated questions: what does "full stack" mean on this team in practice — what did the last person in the role ship; who owns infrastructure and deploys; how do design handoffs work; what is the on-call arrangement. For startups, add runway and what the next two quarters must produce. The answers tell you whether this is one coherent job or three jobs wearing one title.

Frontend: debounced input, request cancellation for stale queries, keyboard navigation, loading and empty states. API: a fast read endpoint with a result cap and clear ranking contract. Data: depends on scale — prefix indexes or trigram matching on the database at moderate scale, a search engine when relevance or volume demands it. The cross-layer points win the round: the debounce interval relates to backend latency, cancellation prevents out-of-order rendering, and caching popular prefixes (CDN or Redis) cuts most of the load.

Update the UI immediately, fire the request, and keep enough information to reconcile: on failure, roll back the local change and tell the user (a toast with retry beats silent reversion). Cover the subtleties that show experience: races when the user toggles twice quickly (last-write-wins with request ordering or disable-until-settled), cache invalidation versus surgical cache updates in your data library, and idempotency on the server so retries are safe. Mention when you would NOT use optimistic updates: destructive or financial actions.

Schema: comments table with parent_comment_id (adjacency list) is the right default; mention materialized paths or closure tables if deep-tree queries dominate. API: paginate top-level comments with the first N replies inlined and a "load more replies" endpoint per thread — never ship the whole tree. Frontend implications drive the design: cursor pagination for stable infinite scroll, counts denormalized for display, and new-comment insertion that does not reorder what the user is reading. Soft-delete with tombstones because threads reference deleted parents.

Open the network tab: if the API call takes 3 seconds, the problem is behind the API (trace it: query, N+1, missing index, slow dependency). If responses are fast but the page is not, profile the frontend: large bundle, render blocking, hydration cost, waterfall of sequential requests. Mention the dishonest middle: fast p50 with slow p95, payloads that are fast to serve but heavy to render, and sequential client requests that are each fast but serialize. Field data (RUM) over local measurement for deciding what matters.

Default recommendation: HTTP-only, secure, SameSite cookies carrying a session (server-stored or short-lived JWT), because cookie storage is XSS-resistant where localStorage tokens are not. Cover CSRF (SameSite plus tokens for state-changing requests where needed), refresh strategy and revocation if using JWTs, and where checks live: route protection in middleware/proxy on the server, with client-side route guards as UX only — never the security boundary. Saying "I would use a maintained auth library rather than hand-rolling" is a sign of judgment, not weakness.

SSR for first-paint speed and SEO on public or content pages; CSR for authenticated app surfaces where interactivity dominates. The full stack half of the answer: SSR moves rendering cost from many clients to your servers (CPU per request, caching strategy becomes critical), couples page latency to every data dependency on the critical path, and changes the failure mode — a slow database now blocks paint. Static generation and ISR escape most of the cost when content allows. Frame it as a per-route decision, not an app-wide ideology.

Client requests a presigned URL from your API (authorizing and constraining type/size server-side), uploads directly to object storage with progress from the upload events, then notifies your API or relies on a storage event to enqueue processing (thumbnails, scanning, transcoding) on a worker. UI shows per-state progress: uploading, processing, ready, failed-with-retry. Failure handling: orphaned-upload cleanup, idempotent processing, and validating the actual file (never trust extension or declared MIME type). Never proxy bytes through your app servers without a reason.

Backend: an endpoint that fetches the document, calls the model API with a versioned prompt, and returns the result — with timeouts, retry policy, cost tracking per call, and caching of summaries keyed by document version since regeneration is expensive and deterministic enough. Frontend: streaming the response token-by-token converts dead air into perceived speed; design explicit loading and error states. Mention rate limiting per user (cost abuse is real), evaluation of output quality before launch, and graceful degradation when the model API has an incident — because it will.

Pick a feature with substance at every layer and narrate it as one system: the product problem, the schema decision and why, the API shape and its tradeoffs, the frontend architecture and one hard UI problem, the deploy and what you watched after release. Name where you consulted others — a DBA on the index, a designer on the interaction — because claiming solo omniscience reads worse than collaboration. End with the outcome metric and one thing you would do differently.

Real examples land best: a frontend polling interval that became a self-inflicted DDoS at scale, an API that returned unbounded lists until a power user had 10,000 items and the page died, an aggressive cache header that served stale prices. Describe how the symptom appeared on the opposite side from the cause, how you traced it across the boundary, and the fix plus the contract change (pagination requirement, rate limit, cache policy) that prevented recurrence.

Cover your actual pipeline (CI stages, preview environments, how production deploys and rolls back) and your post-ship habits: the dashboard you watch, the error tracker, what threshold sends you back to roll back. A specific story helps — a deploy that looked fine and was not, how you caught it, what you added so it gets caught automatically next time. If you have carried on-call for your own features, say so; it is a differentiator.

Buy or adopt everything undifferentiated: auth (a library or service, never hand-rolled), payments (Stripe), email, hosting on a platform that handles deploys. Build only the thing the product is — the core loop users come for. Skip: admin tooling (use the database console), perfect test coverage (one smoke test on the money path), design polish beyond a clean component library. Do not skip: data-model care (migrations are cheap now and brutal later), backups, and error tracking. The shape of the answer — explicit triage rather than enthusiasm — is what they grade.

Go back to the designer with a concrete split: what ships in week one (the core interaction, fully working), what follows (the animation polish, the advanced states), and anything where a cheaper pattern achieves the same goal. Make the cut list together — designers cut better than engineers guess. Flag it to the PM so the tradeoff is owned, not discovered. The anti-patterns being screened: silently shipping a worse version, or heroically attempting two weeks of work in one and shipping bugs in both.

Frontend export (serialize what the client already has) is an hour of work and fine when the table is small and complete in memory. It breaks when data is paginated (exports only the visible page — a classic bug), large, or needs server-side filtering and joins. Backend export (a streaming endpoint or async job with a download link) costs more but is correct at any scale. State the decision inputs: row counts today and in a year, whether users expect filtered-or-full data, and timeout limits. Picking the simple one with a stated upgrade trigger is a fine answer; picking it unknowingly is the bug.