Full-stack developer interview questions test whether you can follow one request from the browser to the database and back. The Bureau of Labor Statistics splits that path in two, writing that "Front-end web developers create the technical features for a website's look," and that "Back-end web developers are responsible for the overall technical construction of the website." A full-stack interview asks you to own both halves and explain every decision on the way.
The BLS puts the median annual wage for web developers at $92,650 in May 2025, and projects employment of web developers and digital designers to grow 5 percent from 2025 to 2035, with about 13,600 openings a year. The BLS has no separate full-stack occupation. It counts software developers on their own, with a median annual wage of $135,980 in May 2025.
What do full-stack developer interviews test?
A full-stack developer interview tests breadth with one layer of depth underneath it. Prepare for five areas, which are HTTP and API design, browser behavior such as CORS and caching, data modeling and queries, security at the boundaries, and a walkthrough of a feature you built end to end. A coding round in JavaScript or another language sits beside those, and senior loops add system design.
The stack itself is predictable. In the 2025 Stack Overflow Developer Survey, JavaScript was the most-used language at 66% of all respondents. Node.js (48.7%) and React (44.7%) were the two most-used web frameworks and technologies, and PostgreSQL led databases at 55.6%. If the job posting does not say which stack the team uses, prepare for some version of that one.
The depth layer is where candidates separate. A strong answer names what breaks when a definition is ignored, because that is what a full-stack engineer gets paged for.
What HTTP and API questions do full-stack interviews ask?
HTTP questions in a full-stack interview test whether you design endpoints that behave correctly when a network fails halfway through a request. The usual openers are "What is the difference between GET and POST?", "When would you use PUT over PATCH?" and "What makes an endpoint idempotent?"
The strong answer goes to the standard. RFC 9110, the current HTTP semantics specification, says methods are "safe" "if their defined semantics are essentially read-only." It calls a method idempotent when "the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request." GET, PUT and DELETE meet that definition. POST does not.
Then say why it matters. RFC 9110 states that "A client SHOULD NOT automatically retry a request with a non-idempotent method" unless it knows the request is idempotent or was never applied. That is why a payment endpoint built on POST needs an idempotency key of its own, and why a mobile client that retries on timeout can charge a customer twice.
Expect a follow-up on status codes and error shapes. Pick a convention, such as 400 for invalid input, 401 for missing or invalid credentials, 403 for an identity without permission and 409 for a conflict, and explain how the front end handles each one.
How should you answer the CORS question in a full-stack interview?
The CORS question tests whether you understand that the browser enforces it, which is why a request that works in curl can fail in the app. A good answer starts with the same-origin policy, which stops a page on one origin from reading responses from another by default. CORS is the set of headers a server sends to relax that policy for origins it trusts.
Next comes the preflight. MDN's CORS guide explains that browsers send a "preflight" request to the server hosting the cross-origin resource "in order to check that the server will permit the actual request." That preflight is an OPTIONS request, and it is triggered by things like a JSON content type or an Authorization header.
Expect the question to turn into a debugging story. "The front end gets a CORS error after we added auth" is a common prompt. Walk through it in order. Check the network tab for the OPTIONS request, check whether the server answers it at all, then check whether the allowed headers include Authorization. If the app authenticates with cookies, add that MDN's guide says a server responding to a credentialed request must name an explicit origin instead of the * wildcard, so a wildcard origin is the wrong fix.
What caching questions come up in full-stack interviews?
Caching questions test whether you can make a page fast without serving a user someone else's data or yesterday's price. A common prompt is "What is the difference between no-cache and no-store?", and the names make it easy to get backwards.
MDN's HTTP caching guide says the no-cache directive "does not prevent the storing of responses but instead prevents the reuse of responses without revalidation." For the stricter case, the same guide says "If you don't want a response stored in any cache, use no-store."
Build the rest of the answer in layers. Static assets with hashed filenames can be cached for a long time, because a new build produces a new URL. HTML and API responses that change per user should be marked private or not cached at a shared layer. Server-side caches, such as Redis in front of a slow query, raise the invalidation question, and the interviewer will ask what happens when the underlying row changes. Name the strategy you would use and the staleness you would accept.
What database and security questions should you expect?
Database questions in a full-stack interview test whether your queries and your schema survive real traffic and hostile input. Typical prompts are "Design the tables for a comments feature", "Why is this page slow?" and "How do you prevent SQL injection?"
For the schema, talk through keys, the one index the main query needs, and what happens on delete. For the slow page, describe how you would find out before guessing. Read the query plan, check for a missing index, and look for an N+1 pattern where the code runs one query per item in a list.
For injection, the OWASP SQL Injection Prevention Cheat Sheet tells developers to "Use parameterized queries for data values," to use fixed application-owned choices for dynamic parts of a query such as a sort column, and to run the database account with least privilege. The same cheat sheet strongly discourages escaping input by hand, so lead with parameterized queries.
Authorization comes next, and it is easy to get wrong when the front end and back end are both yours. Hiding a button in the UI does not stop a request. Say that every endpoint checks who the user is and what they may touch on the server, and give an example from your own code.
How do you answer "walk me through a feature you built"?
The feature walkthrough tests ownership. The interviewer wants to see that you can explain one feature across every layer it touched.
Pick a feature you built yourself, with a real constraint. Start with the problem and who it was for. Then go layer by layer through the UI state and how it loaded data, the API contract, the schema change, and how you shipped it safely, whether behind a flag, with a migration plan or with a rollback. Finish with one thing that went wrong and what you changed afterward.
Expect the interviewer to pick the layer you spent the least time on and dig. "Why did you put that logic in the client?" "What happens if two users edit at once?" Prepare the follow-up for each layer, because a walkthrough that is detailed on the front end and vague on the database tells the interviewer which half of the title you actually hold.
What is overrated
Memorizing framework trivia. Lifecycle method names and hook APIs get renamed and deprecated across major versions. Interviewers ask about rendering and state because they want to hear the trade-offs, and those outlast any one release.
Claiming equal depth everywhere. Very few engineers are as strong in CSS layout as in query tuning. Saying which side you are deeper on, and showing you can work competently on the other, reads as more credible than claiming both.
Long lists of tools. A résumé naming twelve frameworks invites twelve sets of questions. Name the stack you have shipped with, and be ready to defend every item on it.
Prepare for a full-stack interview this week
- Write down one feature you built end to end, with the problem, each layer, the deploy plan and one failure. Practice telling it in four minutes.
- Explain idempotency, CORS preflight, and no-cache versus no-store out loud without notes, using the wording in RFC 9110 and MDN as your check.
- Design a schema for a small feature, such as comments or bookmarks, and name the index the main query needs.
- Review the JavaScript interview questions guide for the coding round, and the SQL interview guide for the query questions.
- If the loop includes design, work through the system design interview questions guide, starting with the ones closest to your product.
- Run the rounds out loud. In Four-Leaf's AI mock interviews, a Custom round takes the name you give it, such as "API design and caching," and generates the questions an interviewer would ask in that round, with follow-ups on what you said.
Where this is heading
Full-stack interviews reward the engineer who can explain the boundaries between layers, because that is where production bugs live. A CORS error, a retried POST and a stale cached page all start at a boundary somebody assumed would hold.
Prepare by tracing one request through your own code until you can explain every hop. The interviewer is hiring the person who knows where it breaks.
