Full Stack Developer interview questions and how to answer them
Full stack interviews test whether you can carry a feature across the whole app without dropping it at the boundary between front end and back end. Expect questions that start in the browser and end in the database, plus a take-home or live build that checks you can actually ship. The candidates who do well talk about tradeoffs, not just tools.
What happens in each round
- 1
Recruiter screen
What happens
Whether your stack matches theirs closely enough, what level you're aiming for, and whether you can explain a recent project in plain words without drowning in jargon.
- 2
Technical screen or take-home
What happens
Whether you can write working code on both sides. A take-home is often a small app with an API and a UI; a live screen might be building a component that fetches and filters data.
- 3
System design conversation
What happens
How you'd structure a feature end to end: the data model, the API contract, caching, and what the front end does while it waits. Mid and senior candidates get more weight here.
- 4
Code review or pairing session
What happens
How you read someone else's code, what you flag first, and whether you can work alongside a teammate without taking over the keyboard.
- 5
Hiring manager and team fit
What happens
How you handle production incidents, disagreement with product or design, and ownership of work that crosses team lines.
Questions you're likely to get
1.Walk me through what happens when a user submits a form in your last app, from the click to the database and back.
Why they ask
This is the full stack question in its purest form. They want to see that you understand every layer, not just the one you're comfortable in.
How to answer
- Start with client-side validation and how the form state is held, for example React Hook Form or controlled inputs
- Describe the request itself: the HTTP method, the payload, how the auth token or session cookie rides along
- Cover the server side: routing, validation again on the server, the service logic, and the SQL or ORM call inside a transaction if it needs one
- Explain the response and how the UI updates, including the error path and what the user sees if the request fails
2.A page in our app has gotten slow. How would you figure out whether the problem is the front end or the back end?
Why they ask
Full stack developers are often the first to look at performance problems because they can read both sides. They want a method, not a guess.
How to answer
- Open the browser's network tab and check how long the API calls take versus how long the page takes to render
- If the API is slow, check server logs or an APM tool like Datadog or New Relic and look at the query with EXPLAIN
- If rendering is slow, use the React Profiler or Lighthouse to find heavy components, big bundles or needless re-renders
- Mention fixing the biggest cost first and measuring again before calling it done
3.Design the API for a comments feature on a blog post. What endpoints, what data, what edge cases?
Why they ask
They're checking whether you design an API around how the front end will actually use it, and whether you think about the ugly cases early.
How to answer
- Sketch REST routes or a GraphQL schema, with a clear shape for a comment and its author
- Handle pagination, ideally cursor-based for a long, growing list
- Cover permissions: who can edit or delete, and what happens to replies when a parent is deleted
- Mention rate limiting or spam handling, and how the UI shows a comment optimistically before the server confirms it
4.How do you handle authentication in a web app you've built?
Why they ask
Auth mistakes are common in full stack work and costly. They want to hear that you know the moving parts and the risks.
How to answer
- Explain your choice between session cookies and tokens like JWTs, and why
- Say where the token or session lives in the browser and how you protect it, such as httpOnly and secure cookie flags
- Mention password hashing with bcrypt or argon, or handing auth to a hosted provider like Okta or Clerk
- Touch on CSRF and XSS and how your setup guards against them
5.When would you choose server-side rendering over a single-page app?
Why they ask
Frameworks like Next.js and Remix blur the line between client and server. They want to know you pick an approach for a reason.
How to answer
- Name the tradeoffs: SEO and first load speed versus a snappier feel once the app is running
- Give an example, like a marketing page or product listing that needs search visibility versus an internal dashboard that doesn't
- Mention hybrid options such as static generation or rendering some routes on the server and others on the client
- Note the cost of server rendering: more server load and more complexity around data fetching and caching
6.Tell me about a database schema you designed and something you'd change about it now.
Why they ask
Plenty of full stack candidates are weaker on data modeling. This checks whether you've owned a schema and learned from living with it.
How to answer
- Describe the tables, the key relationships and why you normalized or denormalized where you did
- Mention indexes you added and what query they were for
- Name a real regret, like a JSON column that turned into a mess or a missing foreign key
- Explain how you'd migrate away from it without downtime
7.How do you test a feature that spans the UI and the API?
Why they ask
They want to know where you put your tests and whether you understand what each kind is good for.
How to answer
- Unit tests for tricky logic on both sides, with Jest, Vitest or pytest
- Integration tests for the API against a real test database rather than mocking everything
- A small number of end-to-end tests in Playwright or Cypress for the main user path
- Say which tests you'd skip under time pressure and why
8.Here's a pull request. What would you comment on?
Why they ask
Code review is a big part of the job. They're watching what you notice first and how you phrase feedback.
How to answer
- Read for correctness and security first, such as an unvalidated input or an unparameterized query
- Then look at readability, naming and whether the change matches the patterns already in the codebase
- Separate blocking comments from suggestions, and phrase them as questions where you're unsure
- Mention checking that the PR has tests and that the description explains the why
9.Tell me about a production incident you helped fix.
Why they ask
They want to see how you act under pressure and whether you follow through after the fire is out.
How to answer
- Set the scene briefly: what broke and who noticed
- Explain how you found the cause, with the actual tools, like Sentry, logs or a feature flag rollback
- Say what you shipped to fix it and how you confirmed it worked
- Close with what changed afterward, such as a new test, an alert or a postmortem action
10.Product wants a feature by Friday that you think will take much longer. What do you do?
Why they ask
Full stack developers often talk directly with product managers and designers. They're checking that you push back with options instead of just saying no.
How to answer
- Break the feature into pieces and show which parts are expensive and why
- Offer a smaller version that ships on time and a plan for the rest
- Flag the risk of cutting corners, like skipping tests on a payment path
- Describe how you'd keep product updated rather than going quiet until Friday
11.Which side of the stack are you strongest on, and how do you keep the other side sharp?
Why they ask
Nobody is equally strong everywhere. They want an honest self-assessment and a real habit of learning.
How to answer
- Name your stronger side plainly and give an example of deep work there
- Admit a specific gap on the other side, like CSS layout or query tuning
- Describe what you do about it, such as picking those tickets on purpose or pairing with a specialist
- Connect it to how you'd help their team
Mistakes that sink good candidates
Listing every framework you've touched instead of going deep on the stack you actually used
Blaming the other team, front end or back end, for bugs in stories about past projects
Skipping the error and loading states when you build a UI in a live exercise
Handing in a take-home with no README, no tests and no note on the tradeoffs you made
Need more Full Stack Developer interviews to prep for?
HeroApply applies to Full Stack Developer jobs that match you, every day. 672 jobs are open today.