Full-Stack Interview Questions
Full-stack interviews rarely test depth in both halves — there is not time. They test the seam. What the client does when the request is slow, what the server does when the client submits twice, what the user sees when the call fails, and whether the two sides agree about what the data means.
The weakness that shows up most is a candidate who is genuinely competent on both sides and has never thought about the boundary as a design surface. They build a clean API and a clean UI, and the combination double-submits on a slow network, shows a spinner forever on a failure, and renders optimistic state that the server later rejects with no reconciliation.
Written and reviewed by Sahil Srivastav
What the bar actually is
You should treat every network call as something that can be slow, fail, or succeed without the client learning about it. That means disabling or debouncing the submit, deciding what the UI shows in each state, and making the endpoint idempotent so a retry — whether from your code or the user's impatient second click — cannot double-apply.
You are also expected to have a position on where validation and business rules live. Duplicating a rule in both layers means they drift; implementing it only in the client means it is advisory. The defensible answer is that the server is authoritative and the client duplicates selectively for responsiveness, with the client version understood as a convenience rather than a guarantee.
How the rounds are structured
A small end-to-end feature
An API plus a UI that consumes it. The scoring concentrates on the states you handle: loading, empty, error, stale, and the double-submit case.
API contract design
Shapes, status codes, pagination, and what the client does with each error class. Expect to be pushed on what a 409 means to the user.
One side in depth, the other at a working level
Usually a backend round at depth plus frontend fundamentals, or the reverse depending on the role. Clarify which before you prepare.
Debugging across the boundary
A symptom that could originate on either side. Being able to narrow which half owns it, from evidence, is the differentiator.
What this interview bar tests
Every state the UI can be in
Loading, empty, error, partial, stale, offline. Designs usually specify the happy path only, and noticing the missing states unprompted is a strong signal.
Double submission
The user clicks twice on a slow network. Disable the control, and make the endpoint idempotent — client-side prevention alone is a UI nicety, not a guarantee.
Optimistic updates and reconciliation
Applying the change locally before confirmation is good UX and requires a rollback path when the server disagrees. Optimistic without reconciliation is a bug.
One authoritative source of rules
Server authoritative, client duplicating selectively for responsiveness. Rules implemented twice drift; rules implemented only client-side are advisory.
A preparation plan that works
- 1Build one small feature end to end and enumerate every state before writing the component: loading, empty, error, stale, submitting. Working from that list is what interviewers see as design rather than reaction.
- 2Deliberately throttle the network and watch your own UI misbehave — double submits, stale renders, spinners that never resolve. Fixing what you observe is more convincing than reciting best practice.
- 3Make one endpoint properly idempotent with a client-supplied key, and wire the client to reuse the key across retries. This is the full-stack version of the most-asked backend question.
- 4Practise narrowing a cross-boundary bug: is the payload wrong, the render wrong, or the cache stale? Naming the evidence you would look at first is the whole skill.
Questions you should expect
The user clicks submit twice on a slow connection. What happens?
Two things must be true for the answer to be complete: the control is disabled or the handler debounced so the second click does not fire, and the endpoint is idempotent on a client-supplied key so that if it does fire — or the client retries after a timeout — nothing is applied twice. Client-side prevention alone fails the moment the network retries for you.
Your API returns 409. What does the user see?
Something specific and actionable, which requires the API to distinguish conflict causes. "Someone else updated this; here is what changed" is a usable 409; a generic conflict message leaves the user with no next step. This question is really asking whether you designed error responses for a human consumer.
Where should validation live?
The server is authoritative because the client can be bypassed entirely. The client duplicates the cheap, high-value checks for responsiveness, understood as convenience rather than enforcement. Say explicitly that duplication risks drift, and that the mitigation is sharing the schema rather than reimplementing the rule.
The list shows stale data after an update. Why?
Usually cache invalidation: the mutation succeeded but the query cache was not invalidated or refetched, so the component renders the previous response. Could also be an optimistic update that was never reconciled with the server's answer. Naming both candidates and the evidence that distinguishes them is the full answer.
What gets candidates rejected
- Handling only the happy path and the error state, missing empty, stale and submitting
- Preventing double submission in the UI only, with a non-idempotent endpoint behind it
- Optimistic updates with no rollback when the server rejects
- Implementing business rules in the client as though they were enforcement
- Generic error messages that give the user no next action
- Being unable to say which side of the boundary a bug lives on
- Claiming depth on both halves and having it tested in one
What to practise, in order
React debugging interview questions
Stale state, effect dependencies and re-render bugs — the client half of the boundary, as real broken code.
Webhook event idempotency and ordering
The server-side guarantee that makes client retries safe, with duplicates and reordering driven by the tests.
E-commerce coupon application engine
Rules that must agree across layers, and an extension the interviewer will add while you watch.
Large table pagination failure
Pagination as a contract between client and server, where offset-based paging duplicates and skips rows under concurrent writes.
FAQ
Will I be tested equally on both sides?
Almost never. Most loops go deep on one side and working-level on the other, determined by what the team needs. Ask which before you prepare — it is a reasonable question and the answer changes your plan substantially.
Is full-stack seen as weaker than specialising?
Not when you can name the seam problems. The credibility risk is claiming equal depth everywhere; the credibility win is depth on one side plus genuine fluency about the boundary, which specialists frequently lack.
How much system design is asked?
Usually feature-scoped rather than architecture-scoped: design this flow end to end, including the API shape, the states and the failure handling. That is a narrower and more concrete exercise than a backend design round.
Do I need to know a specific frontend framework deeply?
Whatever the role names, usually React. The probed depth is state management, effect correctness and render behaviour — the things that produce real bugs — rather than API surface recall.