Full-stack Developer Interview Questions: 20 Real Examples (+ How to Answer Them)

Most advice for full-stack interviews is a frontend list and a backend list stapled together. That's not what the loop is, and preparing that way is why strong candidates come out feeling like they were graded twice and passed neither time.

Here's the actual shape of it. You get two interviewers, and each one is a specialist in one half of your job title. Neither is impressed by your competence in their half — they live there. What they're both watching is the part neither of them owns alone: the seam. Who validates. Who caches. What the screen does while the server thinks. What breaks when only one side ships.

So every question below sits on that seam, ordered the way a real feature moves — contract, storage, trust, screen, release.

The contract

Where the two halves agree on what exists. Asked early, and it sets the tone.

1. You're adding a feature. Do you design the API first or the screen first?
2. Who owns validation — client, server, or both? What do you do about the duplication?
3. The screen needs data from three tables. Do you shape the response for the screen, or keep it generic?
4. The web client and the mobile client need different shapes of the same data. One endpoint or two?

Saying it out loud: question 2 is the one that reveals whether you've actually held both sides. There's a wrong answer people give confidently — "validate on the client for UX, on the server for security" — which is correct and stops one sentence too early, because it leaves the duplication unaddressed and duplication is the whole reason the question exists. Keep going: "So the rules exist twice, which means they drift. Wherever it's worth the effort I'd generate the client rules from the same schema the server enforces, and where that's overkill I'd at least make the server the one that produces the error message, so the client is displaying the server's opinion rather than inventing its own."

Question 4 has no correct answer, which is the point — it's checking whether you'll ask what it turns on before picking. How different are the two shapes really, how often does each client change, and can you live with one endpoint that grows a new flag every time a consumer appears? Candidates who answer immediately are answering a question nobody asked.

The data layer

What actually gets stored, and what gets recomputed. Usually the backend interviewer's territory — but asked through the screen.

5. Where does derived data live — computed on read, or stored on write?
6. A list that was small is now long. What changes on both sides?
7. A user edits the same record on two devices. What wins?
8. The same data is cached on the server and held in client state. Which one is the source of truth?

Saying it out loud: question 6 sounds like a pagination question and it isn't — it's a question about what the client is quietly assuming. The answer that scores names the assumption before the mechanism: "The client's assumption right now is that one request equals the whole list, so anything doing client-side filtering or a total count is about to be wrong. Once it's paged, the server owns sorting and filtering, and the client owns cursor state and what happens when a row is added while the user is on page three." Then pick a mechanism. Say offset or cursor, and why for this data.

If the storage half of this section is where you feel thinnest, that's the half to work on first — we cover it question by question in Backend Developer Interview Questions.

The trust boundary

The seam's sharpest edge, and the section most likely to end a loop early.

9. What can you never trust from the client, and what do you do about it?
10. How do you keep a user signed in, and where does the token live?
11. A user must not see another user's data. Where do you enforce that?
12. Someone finds an endpoint that isn't linked from any screen. What protects it?

Saying it out loud: question 11 has a beginner's answer that sounds thorough — "I filter by the user's ID in the query" — and it's not wrong, it's just not where the answer belongs. Say where the check lives and why it lives there: "It has to be enforced server-side on every request, from the identity in the session rather than from any ID the client sent. The client hiding the button is a UX decision, not a security one. And I'd put it somewhere structural — a scoped query layer or middleware — rather than trusting every future endpoint to remember, because the one that forgets is the one that leaks."

The client, while the server is slow

Where full-stack candidates who lean backend usually lose points — and it's rarely about CSS.

13. The request takes three seconds. What is the screen doing meanwhile?
14. The request fails. What does the user see, and what do you retry automatically?
15. Optimistic update, or wait for the server? How do you choose?
16. The same record appears on three screens. How do you keep them in sync?

Saying it out loud: question 15 rewards a rule, not a preference. The weak answer picks a side; the strong one names the condition: "Optimistic where the action almost always succeeds and is cheap to reverse — a like, a reorder, a toggle. Not optimistic where failure is expensive or embarrassing to undo, like anything involving money or sending something to another person. And if I go optimistic, I need the rollback path designed before I ship it, because the failure case is exactly the one nobody tests."

Question 14 is worth preparing separately, because "show an error" is a non-answer. Which errors retry automatically, which are permanent, whether the user loses their input, and what a 401 does differently from a timeout — that's the answer.

The client-side depth behind these — rendering, state, and what the browser does while it waits — is its own conversation, and we go through it in Frontend Developer Interview Questions.

Shipping both halves

Senior weighting. This is where "full-stack" stops being two skills and starts being one job.

17. The API change and the client change have to go out together. How do you do that safely?
18. Something's broken in production. How do you work out whether it's the client or the server?
19. What do you test end to end, and what do you test in isolation?
20. You've just shipped a feature you can't watch all day. What did you add so you'd find out it broke?

Saying it out loud: question 17 is the most senior question in the list, and the answer is that you don't ship them together — you make it so you don't have to: "I'd deploy the server change first in a backwards-compatible shape, so it serves both the old and new client. Then ship the client. Then remove the old path once the old version is drained. If they truly must be simultaneous, that's a flag, not a deploy window — because a deploy window means a rollback of one half puts you in a state you never tested." The word interviewers are listening for is "backwards-compatible". The reasoning they're listening for is what happens on rollback.

The question underneath the whole loop

There's one more thing being evaluated, and it's usually never asked directly: how deep are you really, and where?

This is where full-stack candidates get caught. Two specialists are in the room, and claiming even depth across both halves invites both of them to go find the bottom — and they will. What sounds like modesty is actually the stronger position, as long as it comes with a boundary you can defend.

The reason this matters more than it looks: "full-stack" means something different at every company. At a five-person startup it means you own the feature to production. At a large company it often means a frontend role that isn't afraid of the API. Which one you're being interviewed for changes what your best answer to every question above even is — and it's worth finding out before the call rather than during it. That's part of what we mean by researching a company before the interview.