What do full-stack developer interviews ask most?

A feature end to end, validation, sign-in, caching, API design, performance across the layers, file uploads, releases and stack choices, and for lead roles team shape and build-or-buy decisions.

Is there a coding round?

Usually a take-home app or a live task with a small frontend and API. Keep it simple and explain your trade-offs in writing.

Will they test me on both frontend and backend?

Yes, but not equally deep. Say which side you lean to, and show you can ship on the other.

Which stack should I use in the interview?

The one you know best, unless the job names one. A clean, well-tested app in a familiar stack beats a half-finished one in theirs.

How should I prepare in a week?

Say the two worked answers out loud, build one small feature end to end with sign-in and a database, deploy it, and prepare one story each about a cross-layer bug, a release and a trade-off.

Full-stack developer interview questions, with worked answers

Fifteen questions that full-stack developer interviews ask again and again, from first full-stack job to lead, engineering manager and head of engineering. For each: what the interviewer is checking, a short answer, the full answer in plain words, a weak answer to avoid, and a likely follow-up.

The cvscored teamPublished 27 Oct 2026 · Updated 27 Oct 2026

Contents

How to use these questions
What a full-stack developer is expected to know
A feature end to end
Between the layers
Releases and choices
Lead, manager and head of engineering questions
Your CV for these questions
Key takeaways
Frequently asked questions
More on the full-stack developer role

How to use these questions

Start with the short answer, out loud. Then pick two or three points from the full answer and add a feature you built across the layers: what the user did, what the server did, what the database kept, and what went wrong on the way. Full-stack interviewers like to change one layer and ask what happens to the others; be ready for it.

What a full-stack developer is expected to know

The browser: a framework such as React, Angular or Vue.js, with HTML and CSS good enough to ship a screen.
The server: a backend such as Node.js, Java with Spring, Python with Django, or PHP with Laravel.
One language where it helps: TypeScript on both sides, with types shared between the API and the screen.
Data: SQL and PostgreSQL, or MongoDB in JavaScript stacks, including safe schema changes.
Between the layers: REST APIs or GraphQL, sign-in, and caching.
Shipping: Git, Docker, CI/CD and a cloud such as AWS.

A feature end to end

Walk me through building a 'save for later' button on a shop, from the database to the screen.

What they check: that you see the whole feature, every layer and how they connect.

Short answer: "A table links users to saved products. Two API endpoints save and remove an item, and one lists them. The button changes at once when pressed and rolls back if the request fails. I add tests on both sides, release it behind a feature flag, and measure how many people use it."

The full answer, in six steps:

Ask first. Can guests save items, or only signed-in users? What happens to a guest's list when they sign in? Is there a limit? These answers shape every layer.
The data. A table of user, product and date saved, with a unique pair of user and product, so saving twice does nothing. An index on the user for the list.
The API. Save and remove are safe to repeat; the list is paginated. Every request checks that the list belongs to the signed-in user.
The screen. The button updates at once (an optimistic update) and goes back if the server says no. It has a clear label for screen readers and works with the keyboard.
Tests. A server test for the unique rule and the ownership check, a component test for the button, and one end-to-end test of save, reload, still saved.
Release and learn. Ship behind a feature flag (a switch that turns the feature on for some users), watch errors, then turn it on for everyone and measure use.

A weak answer: "I store the saved items in local storage." They vanish on another device and the business cannot see them.

Follow-up: "A saved product is deleted from the shop. What does the list show?" Keep the entry, show it as no longer available, and let the user remove it; never break the whole page.

Where do you validate a form: in the browser, on the server, or both?

What they check: that you know which checks protect the user and which protect the system.

Short answer: "Both, for different reasons. Checks in the browser help the user: quick messages next to the field. Checks on the server protect the system, because anyone can send a request without the browser. Where I can, both use the same rules, defined once."

The full answer: The server is the only place that can be trusted, so every rule is checked there: types, lengths, allowed values, and rules that need the database, such as an email address already in use. The browser repeats the simple rules for speed and shows the server's errors next to the right field. With TypeScript on both sides, a shared schema can drive both. Error messages say how to fix the problem, in plain words, and keep what the user typed.

A weak answer: "The form checks it, so the API does not need to." Follow-up: "The server rejects a valid-looking address the browser allowed. What does the user see?" The server's message, next to the field, with the rest of the form kept.

How does sign-in work end to end in an app you built: sessions with cookies, or tokens?

What they check: authentication across the browser and the server, and its risks.

Short answer: "For a web app on one domain, I prefer a server session in a cookie the script cannot read, marked secure and same-site. Tokens suit mobile apps and APIs used by other services. Either way, passwords are hashed with a slow algorithm, or I use a tested sign-in provider."

The full answer: With a session, the server keeps who is signed in and the browser keeps only an ID in an HttpOnly cookie, so a script injected into the page cannot steal it; protection against forged requests from other sites (CSRF) comes from the same-site setting and a token in forms. Tokens such as JWTs carry the user's identity themselves; they spread across servers easily but are hard to cancel before they expire. Add rate limits on sign-in, a safe reset flow, and two-step sign-in for admin accounts. Treat sign-in as a feature with its own tests.

A weak answer: "I keep the token in local storage." Any script on the page can read it. Follow-up: "The user changes their password. What happens to their other sessions?" End them all, except perhaps the current one.

Between the layers

A user edits their profile but still sees the old name after a reload. Where do you look?

What they check: that you know every place a copy of data can live, from the database to the screen.

Short answer: "I follow the data from the database outwards. Is the new name saved? Does the API return it, or a cached copy? Is a CDN or the browser caching the response? Does the frontend keep an old copy in its state or its query cache? I check each layer until I find the old copy."

The full answer: Caches sit at every layer: the database's read replica may lag a moment behind; the server may cache in memory or a shared store; a CDN, servers near the user that keep copies, may cache API answers by mistake; the browser follows cache headers; the frontend's data library keeps results. The fix is in the right layer: send no-store headers for personal data, delete the server cache entry when the profile changes, read the user's own data from the main database, and refetch or update the frontend cache after the edit.

A weak answer: "Tell the user to clear the browser cache." Follow-up: "It only happens for some users." Look at what differs: a CDN region, a replica, or a second open tab with old state.

How do you design the API between your own frontend and backend: REST, GraphQL, or something else?

What they check: that you choose by the product's screens and team, and know each option's cost.

Short answer: "For most products, REST: simple, cacheable and understood by everyone. GraphQL helps when many different screens need different slices of the same data, or several clients use one API. When frontend and backend are one TypeScript codebase, typed calls with shared types are often the simplest."

The full answer: With REST APIs, each resource has an address, and HTTP caching works out of the box; screens sometimes need several calls or receive too much. GraphQL lets each screen ask for exactly what it needs in one request, but caching is harder and one careless query can load the database heavily, so limits on query depth and cost are needed. A backend for frontend, a thin API shaped for one app, is another answer. Whatever the style, share the types, describe the API in one place, and version it if outside clients use it.

A weak answer: "GraphQL, because it is newer." Follow-up: "A list screen makes fifty API calls." Add an endpoint that returns the list with what the screen needs, or batch the calls.

A page is slow. How do you find out whether the browser, the network, the API or the database is to blame?

What they check: performance across the whole request, measured layer by layer.

Short answer: "I split the time. The browser's network tab shows how long the API call takes against how long the page takes to show. If the call is slow, the server's logs and traces show time in the code against time in the database. Then I fix the layer that takes the most time."

The full answer, in five steps:

Reproduce it as the user has it. A phone on a mobile network, with real data; a developer laptop with an empty database hides most problems.
Browser or server? If the API answers fast but the page is slow, the cause is in the browser: too much JavaScript, a large image, or a long list rendered at once.
Network. Many calls one after another, large answers, or no compression; combine calls and send only what the screen shows.
Server. A trace with a request ID shows each step. Often one database query is slow, or the same query runs once per row in a list (the N+1 problem).
Database and back. Read the query plan, add the index or rewrite the query, then measure the whole page again, because the next slowest layer is now the target.

A weak answer: "I would add caching everywhere." That hides the cause and adds stale data.

Follow-up: "It is only slow for customers with many orders." Something grows with the data: a missing index, a query per order, or a list without pagination.

How do you handle a file upload, such as a profile picture, end to end?

What they check: limits, security and storage across browser, server and cloud.

Short answer: "The browser checks type and size and shows a preview. The server issues a short-lived signed address so the browser uploads straight to file storage, not through my server. The server then checks the file, makes the sizes the app needs, and saves only the file's key in the database."

The full answer: Cloud storage such as S3 on AWS offers signed upload addresses that expire in minutes and allow one file of a set type and size. Never trust the file name or the type the browser reports; check the content. Remove hidden data such as the photo's location, make smaller copies for lists, and serve images through a CDN. Personal photos are personal data under GDPR (EU) and similar laws, so delete them when the account is deleted.

A weak answer: "I store the image in the database as text." Follow-up: "Users upload photos from new phones in a format the browser cannot show." Convert them on the server to a format every browser reads.

How would you add a live notification count that updates without a page reload?

What they check: the options for real-time updates and their cost on both sides.

Short answer: "I start with the simplest option that meets the need. Polling every half minute is often enough for a count. If it must be instant, server-sent events send updates from the server down an open connection; WebSockets are for two-way traffic such as chat."

The full answer: Polling is simple and works everywhere, but most requests return nothing new. Server-sent events keep one connection open per user and suit updates from the server only. WebSockets allow both directions and need care with load balancers and reconnecting. Real-time connections need a shared channel between server copies, such as Redis, so an event on one server reaches users connected to another. On the screen, reconnect after sleep or a lost network, and fetch the current count when the connection returns.

A weak answer: "WebSockets for everything." Follow-up: "Ten thousand users are connected and you deploy." All connections drop at once; clients reconnect with a random delay so the new servers are not flooded.

Releases and choices

A feature needs a frontend change, an API change and a database change. How do you release it so nothing breaks?

What they check: that you know the halves are released at different moments, and plan for it.

Short answer: "In steps that are each safe alone. First the database change that the old code ignores, then the API that supports old and new requests, then the frontend, behind a feature flag. Old pieces are removed only when nothing uses them."

The full answer: Users keep an old version of the frontend open in a tab for hours, and mobile apps for months, so the API must accept both. This is expand and contract: expand by adding the new column or field next to the old one, move readers and writers over, then contract by removing the old. A feature flag lets you turn the feature on gradually and off at once if errors rise. The CI/CD pipeline runs the end-to-end test of the main flows against the new version before the switch.

A weak answer: "We deploy everything together at night." Even then, an open tab still runs the old frontend. Follow-up: "The flag has been on for everyone for months." Remove it and the old code; old flags are hidden complexity.

You are starting a new product with two developers. Which stack do you choose, and why?

What they check: judgement and trade-offs, not a favourite framework.

Short answer: "The one the team already knows well, as one deployable app, a monolith, with a relational database and a managed host. For a web product that often means TypeScript with React and Node.js, or a framework such as Django or Laravel that comes with sign-in and admin. Speed of learning from users matters more than scale on day one."

The full answer: List what the product needs: sign-in, payments, email, admin screens, maybe search. A batteries-included framework gives many of these for free; a lighter stack gives more freedom and more work. One language on both sides lets two people move across the code. Choose boring, well-documented tools that are easy to hire for. A monolith with clear modules can be split later if a part needs it; splitting early costs a small team most of its time. Write the decision down with its reasons.

A weak answer: "Microservices on Kubernetes, so we are ready to scale." Follow-up: "An investor asks whether it will handle a million users." Explain which part would need to change first, and that the plan exists; it is not built before it is needed.

Something fails on the server. What does the user see, and how do you find the cause later?

What they check: error handling that serves both the user and the developer, across the layers.

Short answer: "The user sees a short message in plain words that says what to do next, and keeps what they typed. The server returns a clear error code and a reference, logs the details with a request ID, and the same ID is in the frontend's error report, so I can follow one failure from the click to the database."

The full answer: Decide which errors the user can fix (a wrong field, an expired session) and which they cannot (a bug, an outage); the first get a precise message, the second an apology and a retry. Never show a stack trace or a database message to users; it confuses them and helps attackers. Catch errors at the edge of each layer: an error boundary on the screen so one broken widget does not blank the page, one error handler on the server that turns exceptions into the same response shape. Collect frontend errors too, since most never reach the server's logs.

A weak answer: "I show 'Something went wrong'." Follow-up: "Support says users see errors you cannot find." Add the reference to the message so users can quote it, and check the frontend error reports for failures that never called the API.

How do you deploy a full-stack app, and what goes in the pipeline?

What they check: that you can run what you build, not only write it.

Short answer: "Every push runs the checks: type checks, tests for both halves, and a build in Docker. Every pull request gets a preview to click through. Merging to main deploys to staging, then production, with database changes run first and a quick way back."

The full answer: Docker builds the same image for every environment. Secrets live in the host's secret store. The frontend's static files go to a CDN; the backend runs as several copies behind a load balancer, with a health check so a broken copy gets no traffic. Database migrations run in a separate step before the new code. After a release, watch errors and response times for some minutes; roll back by deploying the previous image. Keep staging close to production, or it will not catch what production breaks.

A weak answer: "I copy the files to the server." Follow-up: "A migration fails half way." Migrations run in a transaction where the database allows it, are tested on a copy of production data first, and the old code keeps working until they finish.

Lead, manager and head of engineering questions

You are the only engineer who knows both the frontend and the backend. How do you stop being the bottleneck?

What they check: for senior and lead roles, spreading knowledge instead of holding it.

Short answer: "I make myself unnecessary on purpose: short written notes on how each part works, pairing with others on the side they know less, reviews that teach, and a rule that two people can release every part. My goal is to be on holiday without the team waiting."

The full answer: Find where work waits for you: reviews, releases, questions. Write down the decisions and the setup steps. Pair a frontend-leaning developer on an API change and a backend-leaning one on a screen. Make the local setup one command with Docker, so anyone can run the whole app. Share on-call. Measure it: how long reviews wait, how many people have released each part in the last month.

A weak answer: "I just work longer hours." Follow-up: "The team says your code is the hardest to change." Ask which parts, and pair on rewriting them with the people who have to change them.

The team is growing from four to fifteen engineers. Do you split it into frontend and backend teams?

What they check: for lead and engineering manager roles, how team shape affects the product.

Short answer: "I would split by product area, not by layer: each team owns a part of the product, such as onboarding or billing, from screen to database. Teams split by layer hand work to each other for every feature, and that waiting is what slows growing companies down."

The full answer: Small teams of about five to eight people, each with a clear area and a product manager, can ship without asking others. Inside a team, people still lean to frontend or backend; that is fine. Some work needs a shared home: the design system, the sign-in, the deploy pipeline. Give those owners, or a small platform team once there are enough teams. Organise the code to match: modules per product area with clear boundaries, so teams rarely change each other's code.

A weak answer: "Frontend team and backend team, because that is how skills are organised." Follow-up: "Two teams both need to change the checkout." One owns it and reviews; the other contributes, or the work is planned together.

As head of engineering at a small company, how do you decide what to build yourselves and what to buy?

What they check: for head of engineering and solutions architect roles, judging cost, risk and focus for the business.

Short answer: "We build what makes the product different, and buy or use open-source for everything else: sign-in, payments, email, search, monitoring. I compare the full cost, including the engineers' time to build and run it, against the price and the risk of depending on a vendor."

The full answer: A small team's time is the scarcest thing it has. Building sign-in or payments yourself means owning their security and their failures for years. Buying means a monthly bill, less control, and a plan for leaving the vendor if prices rise or the service ends. Check data protection: where the vendor keeps personal data, and whether a contract covers it. Review the choices once a year, because what was right for five engineers may not be right for fifty. Explain each decision to the founders in money and risk, not in tools.

A weak answer: "Engineers can build anything, so we build it." Follow-up: "The search vendor triples its price." Know in advance how hard leaving would be, keep your data exportable, and compare the alternatives before the contract renews.

Your CV for these questions

What is on your CV becomes the interview. For each topic below, write one line that names both halves of the work and ends in a result:

Skill	Weak line	Strong line, with proof
Feature ownership	Implemented new features.	Shipped saved searches from database to email alerts in 3 weeks; 1 in 5 active users set one up.
Sign-in	Implemented authentication.	Replaced home-made password storage with a sign-in provider and two-step login for admins; account takeovers stopped.
Performance	Improved application performance.	Traced the slow orders page to a query per row; one query and pagination took it from 6 s to under 1 s.
Releases	Worked with CI/CD.	Introduced feature flags and preview deploys; hotfixes after releases down from weekly to monthly.
Team	Helped grow the team.	Wrote the setup and architecture notes and paired with each new hire; time to first release down from 3 weeks to 3 days.

Then score your CV against a real full-stack job: it shows which layers the job leans on, and where your CV proves only one half of the stack.

Key takeaways

Answer by following the request: the click, the API, the database, and back to the screen.
Validate on the server always, and in the browser for the user's sake.
Find a slow page by splitting the time between browser, network, server and database.
Release changes that touch both halves in steps that are each safe on their own.
Lead and manager roles add team shape, spreading knowledge, and build-or-buy decisions.

Frequently asked questions

What do full-stack developer interviews ask most?: A feature end to end, validation, sign-in, caching, API design, performance across the layers, file uploads, releases and stack choices, and for lead roles team shape and build-or-buy decisions.
Is there a coding round?: Usually a take-home app or a live task with a small frontend and API. Keep it simple and explain your trade-offs in writing.
Will they test me on both frontend and backend?: Yes, but not equally deep. Say which side you lean to, and show you can ship on the other.
Which stack should I use in the interview?: The one you know best, unless the job names one. A clean, well-tested app in a familiar stack beats a half-finished one in theirs.
How should I prepare in a week?: Say the two worked answers out loud, build one small feature end to end with sign-in and a database, deploy it, and prepare one story each about a cross-layer bug, a release and a trade-off.

How to use these questions

What a full-stack developer is expected to know

A feature end to end

Walk me through building a 'save for later' button on a shop, from the database to the screen.

Where do you validate a form: in the browser, on the server, or both?

How does sign-in work end to end in an app you built: sessions with cookies, or tokens?

Between the layers

A user edits their profile but still sees the old name after a reload. Where do you look?

How do you design the API between your own frontend and backend: REST, GraphQL, or something else?

A page is slow. How do you find out whether the browser, the network, the API or the database is to blame?

How do you handle a file upload, such as a profile picture, end to end?

How would you add a live notification count that updates without a page reload?

Releases and choices

A feature needs a frontend change, an API change and a database change. How do you release it so nothing breaks?

You are starting a new product with two developers. Which stack do you choose, and why?

Something fails on the server. What does the user see, and how do you find the cause later?

How do you deploy a full-stack app, and what goes in the pipeline?

Lead, manager and head of engineering questions

You are the only engineer who knows both the frontend and the backend. How do you stop being the bottleneck?

The team is growing from four to fifteen engineers. Do you split it into frontend and backend teams?

As head of engineering at a small company, how do you decide what to build yourselves and what to buy?

Your CV for these questions

Key takeaways

Frequently asked questions

More on the full-stack developer role