Full Stack Developer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
Full stack interviews test both ends without expecting deep specialism in either: a coding exercise, a practical task such as building a small feature with an API and a UI, questions on databases and deployment, and a behavioural round.
Interviewers want to know you can take a feature from database schema to the screen on your own, and that you can judge where each piece of logic belongs.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Walk me through a feature you built end to end.
What they're really asking: Can you own the whole slice, and what did you decide at each layer?
Answer outline (STAR)
- SituationA feature that needed a schema change, an API and a UI.
- TaskDeliver it largely on your own.
- ActionThe schema and API design, the UI states, tests at each layer, and the rollout.
- ResultUsage after launch, and one thing you'd design differently.
Full sample answer (fictional example)
I built team invites for a scheduling app: schema, API, UI and emails. I designed an invitations table with an expiry and a unique token, built three endpoints, and made the UI show pending, accepted and expired states. I wrote integration tests and a Playwright test for the main flow, and rolled it out to 5 percent of accounts first. In its first month 1,900 invites were sent and 62 percent were accepted. Looking back, I'd add rate limiting from day one, because one customer sent 400 invites in a minute.
2.Tell me about a time you had to learn a new part of the stack quickly.
What they're really asking: Full stack roles always have gaps; how fast and how well do you fill them?
Answer outline (STAR)
- SituationA task in an unfamiliar language, framework or piece of infrastructure.
- TaskDeliver without a long ramp-up.
- ActionRead the existing code and docs, build a small spike, ask targeted questions.
- ResultWhat you shipped, and how long it took.
Full sample answer (fictional example)
My team needed an installable web app that worked offline, and I had never written a service worker. I had ten days. I read the platform docs and a few open-source examples, then built a spike that cached one page offline. I asked a colleague who knew service workers to review it for 30 minutes, which saved me from a caching bug that would have shown stale prices. The app shipped in nine days, and I presented the cache pattern at the team demo so others could reuse it.
3.Describe a time you found a problem in someone else's layer.
What they're really asking: Do you fix or escalate across boundaries constructively, without blame?
Answer outline (STAR)
- SituationA frontend bug that turned out to be an API or data issue, or the reverse.
- TaskGet it fixed properly.
- ActionProve the cause with evidence, propose a fix, pair with the owner.
- ResultThe fix, plus a contract test or validation that prevents a repeat.
Full sample answer (fictional example)
Users saw wrong totals on the order page, and the frontend team assumed a UI bug. I checked the network tab and found the API returned the discounted price in one field and the full price in another, depending on a flag. I wrote up the evidence, with two response examples, and paired with the backend owner to fix it that afternoon. I also added a contract test on the response shape, so a change like that fails in CI instead of confusing a customer.
4.Tell me about a technical decision you'd make differently now.
What they're really asking: Self-awareness: do you learn from the consequences of your own choices?
Answer outline (STAR)
- SituationA framework, schema or shortcut that aged badly.
- TaskLive with it or undo it.
- ActionWhat you knew then, what changed, and how you migrated.
- ResultWhat you'd decide today, and the rule of thumb you took from it.
5.Tell me about building a feature with a non-technical stakeholder.
What they're really asking: Can you translate between a business need and the technical options?
Answer outline (STAR)
- SituationA request from sales, support or operations.
- TaskFind out what they actually needed.
- ActionAsk about the problem, show a quick mock-up, agree a small first version.
- ResultWhat shipped, and how it changed their work.
6.Tell me about saying no to a feature request, or cutting its scope.
What they're really asking: Can you protect the schedule while keeping the requester on side?
Answer outline (STAR)
- SituationA request that would take weeks for a small gain.
- TaskDecline or shrink it without losing trust.
- ActionEstimate the cost, ask what problem it solves, offer a smaller version.
- ResultWhat shipped instead, and how the requester reacted.
Full sample answer (fictional example)
Sales asked for a custom report builder, which I estimated at five weeks. I asked what they were trying to do and learned that three customers wanted the same weekly export. I proposed a scheduled CSV export with four filters, which took four days, and offered to revisit the builder if the export didn't cover it. Sales agreed, the three customers were happy, and nobody has asked for the builder since. I wrote the estimate and the decision on the ticket, so the reasoning was easy to find later.
7.Tell me about improving how your team releases software.
What they're really asking: Do you fix the pipeline, not just your own tasks?
Answer outline (STAR)
- SituationManual deploys that took hours and sometimes broke.
- TaskMake releases fast and boring.
- ActionAutomate build and tests in CI, add preview environments, script the rollback.
- ResultDeploy time and failures, before and after.
8.Tell me about choosing between a bug fix and a new feature.
What they're really asking: How do you set priorities when everything feels urgent?
Answer outline (STAR)
- SituationA sprint with a customer-reported bug and a launch-date feature.
- TaskDecide the order with the information you have.
- ActionSize the bug's impact, check with support and product, agree the order in writing.
- ResultWhat shipped first, and how it turned out.
9.Tell me about customer feedback that changed what you built.
What they're really asking: Do you stay close to the people who use the product?
Answer outline (STAR)
- SituationA feature that drew complaints or silence after launch.
- TaskFind out why, and decide what to change.
- ActionRead support tickets, talk to two customers, prototype the fix.
- ResultThe updated feature, and the usage afterwards.
10.Describe mediating between a designer and a backend developer who disagreed.
What they're really asking: Can you use your view of both layers to settle a dispute?
Answer outline (STAR)
- SituationA design needing data the API couldn't provide cheaply.
- TaskFind a solution both could live with.
- ActionState each side's constraint, sketch two options, test the cost of each.
- ResultThe compromise reached, and how it held up.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.Design the data model and API for a simple booking system.
What they're really asking: End-to-end design in one question: schema, endpoints and concurrency.
Answer outline
- Tables for resources, time slots and bookings, with constraints that prevent double-booking.
- Endpoints to list availability and to create or cancel a booking, with clear errors.
- When two people book the same slot at once, a unique constraint or a lock decides.
12.Where should validation live: the frontend, the backend or both?
What they're really asking: Do you know that anything the browser sends can be faked?
Answer outline
- Both: the frontend for fast feedback, the backend because clients can't be trusted.
- Share schemas where you can (for example zod or JSON Schema) so the two don't drift.
- Database constraints add the final guarantee.
Full sample answer (fictional example)
Both, for different reasons. The frontend validates for speed and kindness: it tells the user about a missing field before a round trip. The backend validates because anything the browser sends can be faked, so it can never trust the client. I'd share one schema between the two with a library like zod, so the rules can't drift apart, and add database constraints such as not null and unique as the final guarantee. On the backend I'd validate types and sizes too, and return clear field-level errors.
13.How does a web session work, from login to logout?
What they're really asking: Security across both layers: cookies, tokens and their risks.
Answer outline
- After login the server issues a session cookie or a token.
- HttpOnly, Secure and SameSite cookie flags reduce XSS and CSRF risk.
- Logout must invalidate the session on the server, not just delete the cookie.
Full sample answer (fictional example)
After login the server creates a session record and sends back a random session ID in a cookie. The browser sends that cookie with every request, and the server looks up who it belongs to. I'd set the cookie as HttpOnly so scripts can't read it, Secure so it only travels over HTTPS, and SameSite to limit cross-site requests. On logout the server deletes the session record, because deleting only the cookie leaves a stolen ID working. I'd also expire sessions after inactivity and rotate the ID at login.
14.Server-side or client-side rendering: when would you use each?
What they're really asking: Do you know the trade-offs for search engines, speed and complexity?
Answer outline
- Server rendering gives a faster first paint and better SEO, at the cost of server work.
- Client rendering is simpler to host and good for rich interaction, but slower on first load.
- Mention hybrids such as static generation and incremental regeneration in Next.js.
Full sample answer (fictional example)
I'd choose by what the page needs. Server rendering sends finished HTML, so the first paint is fast and search engines see the content; it suits marketing pages, listings and anything public. The cost is server work and some complexity. Client rendering ships JavaScript that builds the page in the browser, which is simpler to host and fits a logged-in dashboard with lots of interaction, but the first load is slower. Frameworks like Next.js let me mix them, with static generation for pages that rarely change.
15.How do you deploy a full stack app safely?
What they're really asking: Do you own the path to production, not only the code?
Answer outline
- CI tests and builds every change, and the same artefact goes to every environment.
- Database migrations stay backward compatible and run before the code that needs them.
- Roll out gradually, with health checks and a fast rollback.
16.What's the N+1 query problem, and how do you fix it?
What they're really asking: A common performance trap with ORMs and GraphQL.
Answer outline
- Loading a list and then running one more query per item means N+1 round trips.
- Fix it with eager loading, a join, or batching such as DataLoader.
- Spot it in query logs or traces before users do.
17.How would you add real-time updates to a page?
What they're really asking: Do you know the transport options and what each costs?
Answer outline
- Polling is simplest, server-sent events suit one-way updates, WebSockets suit two-way traffic.
- Plan for scaling open connections and for reconnecting.
- Degrade gracefully when the connection drops.
18.When would you use JWTs instead of server-side sessions?
What they're really asking: Can you weigh a popular tool against a simpler default?
Answer outline
- Sessions are simple and easy to revoke; the cookie holds only an ID.
- JWTs suit stateless services and third-party APIs, but resist early revocation.
- Keep them short-lived with a refresh token, and put no secrets in the payload.
19.How do you handle file uploads from browser to storage?
What they're really asking: A practical problem touching security, cost and user experience.
Answer outline
- Upload straight to object storage with a presigned URL, bypassing your servers.
- Check size and type on the server, and scan for malware before others can download.
- Show progress, allow retry, and clean up abandoned uploads.
20.What is CORS, and how do you debug a CORS error?
What they're really asking: The most common cross-layer error: do you know what the browser protects?
Answer outline
- Browsers block cross-origin requests unless the server's headers allow the origin.
- Read the failing response in the network tab and check the preflight request.
- Fix it on the server with an allow-list, never a wildcard with credentials.
21.How do you design an API so the frontend doesn't need ten calls per screen?
What they're really asking: Do you shape the backend around the screens that use it?
Answer outline
- List what each screen needs, and return it in one request.
- Options: a backend-for-frontend layer, GraphQL, or embedding related data on demand.
- Watch payload size and caching, and keep the endpoints documented.
22.Would you use an ORM or write SQL by hand?
What they're really asking: Pragmatism: do you use the tool well and know where it leaks?
Answer outline
- An ORM speeds up simple reads and writes and keeps migrations tidy.
- Complex reports and bulk updates are clearer, and faster, in hand-written SQL.
- Read the SQL the ORM generates, and watch for N+1 queries.
Take-home or live exercise: tips
Full stack loops often hand you a small feature to build end to end, such as a booking form with an API and a database, live or as a take-home.
- Start with the data model and one working path from UI to database, then add edge cases.
- Validate input on both sides, and show errors to the user rather than failing silently.
- Include a few tests and a README, and say what you'd harden before launch.
Skills employers test for
Technical rounds follow the job ad. These skills are named most often in the 479 newest full stack developer job ads we analysed (out of 3,818 live postings), shown as the share of ads that mention each. Expect questions on the top few.
- 1React63%
- 2TypeScript59%
- 3CI/CD53%
- 4JavaScript44%
- 5AWS43%
- 6Python42%
- 7Node.js39%
- 8Java38%
Full list: Full Stack Developer resume keywords.
From live job ads · computed November 2, 2026 · refreshed daily
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.You're the only developer on a feature with a tight deadline. What do you cut?
What they're really asking: Will you protect what matters and say plainly what won't make it?
Answer outline
- Keep the core user path and data integrity; cut the nice-to-haves.
- Agree the cut list with the product owner, in writing.
- Don't cut tests on anything that writes data or handles money.
Full sample answer (fictional example)
I'd protect the core path and data integrity, and cut the rest. First I'd list what the feature must do for a user to finish the task, and what is merely nice: filters, animations, an admin screen. I'd show that list to the product owner and agree the cuts in writing, so nobody is surprised at launch. I wouldn't cut tests on anything that writes data or touches money, and I'd keep a visible list of what was deferred, with rough estimates, so it can be scheduled next.
24.A page takes eight seconds to load. How do you tell if it's the frontend or the backend?
What they're really asking: Can you locate a problem in the stack before guessing at fixes?
Answer outline
- The network panel shows it: a slow time to first byte points to the server; long scripting points to the browser.
- Trace the slow API calls on the server.
- Fix the biggest contributor first, then measure again.
Full sample answer (fictional example)
The browser's network panel answers it quickly. If the time to first byte for the main request is long, the server is slow; if the response arrives fast but the page still takes seconds, the time is in the browser: large scripts, rendering or slow third-party tags. For the server side I'd look at traces to find the slow query or API call. For the browser side I'd open the performance panel. I'd fix the biggest contributor first and measure again before moving on.
25.You inherit a full stack app with no documentation. How do you get productive?
What they're really asking: Can you get productive on your own, without someone guiding you?
Answer outline
- Run it locally and trace one request from the UI down to the database.
- Write down what you learn as you go; that becomes the documentation.
- Fix one small bug early to learn the deploy path.
26.A customer says their data saved and then disappeared. What do you check?
What they're really asking: Careful debugging when data integrity is at stake.
Answer outline
- Find the write in the API logs and the database, and any later update or delete.
- Look for race conditions, a cache showing stale data, or a failed transaction.
- Keep support informed, and restore from backup if data was really lost.
27.A feature needs a change to a table with millions of rows, in the same release. What do you do?
What they're really asking: Do you plan schema changes so they can't take the site down?
Answer outline
- Split it: a backward-compatible migration first, the code that uses it later.
- Add the column without a default that rewrites the table, and backfill in batches.
- Release behind a flag, and keep the rollback path open for a few days.
28.A form works in staging but fails in production. How do you find out why?
What they're really asking: Do you compare environments systematically instead of guessing?
Answer outline
- Get the exact error from logs and the browser's network tab.
- List the differences: environment variables, data volume, CORS, proxies, flags.
- Reproduce with production-like data if you can, and add a check for the config gap.
29.Your frontend and backend colleagues disagree on an API shape. How do you help?
What they're really asking: Can you turn an argument into a decision using your view of both sides?
Answer outline
- Ask each to state the use case and the constraint, not the preferred solution.
- Mock both shapes, and compare the cost to the client and the server.
- Write down the decision and the reason, and set a date to review it.
30.A customer says they can see another customer's data. What do you do?
What they're really asking: Security incident instincts: speed, containment and honesty.
Answer outline
- Treat it as an incident: tell your lead and the security contact at once.
- Reproduce it, find the missing authorisation check, and ship a fix or disable the feature.
- Check logs for how long and how widely it happened, and help with notification.
Full sample answer (fictional example)
I'd treat it as a security incident. I'd tell my lead and the security contact at once, then reproduce it to confirm. The cause is almost always a missing authorisation check, such as an endpoint that looks up a record by ID without checking the owner. I'd ship the fix, or disable the feature if the fix isn't ready, and add a test that fails when one user requests another's record. Then I'd check the logs for how long it was exposed and who accessed what.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Claiming equal expertise in every layer.
Say where you are strongest, how you cover the rest, and how you ask for review in the weaker layer.
Leaving security out of design answers.
Mention authorisation, input validation and session handling unprompted when you describe a feature.
Calling frontend or backend work the 'easy' part.
Credit the specialists, and describe a time one of them corrected you.
Having no idea how code reaches production.
Describe your pipeline, how migrations run and how you would roll back.
How to prepare for a full stack developer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: Pick your layers
Mark the frontend, backend and data tools in the ad, and decide which two layers you'll be asked about most.
Day 2: Trace a request
Write out one request from click to database and back: DNS, cookies, API, query, render. Fill any gaps.
Day 3: Build a small feature
Build a CRUD feature with auth and tests in two hours, then note what you'd harden before launch.
Day 4: Data and API design
Design a booking system's schema, endpoints and double-booking guard, and explain it aloud in ten minutes.
Day 5: Speed and deploys
Review N+1 queries, caching layers, migrations and rollbacks, and write a short answer for each.
Day 6: Mock the loop
Prepare five STAR stories, then do a mock with a friend: one design question and three behavioural.
Day 7: Demo day prep
Rehearse a five-minute tour of your best project, prepare three questions, and rest.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- How is work split between frontend, backend and infrastructure on this team?
- Which parts of the stack would I own in my first months?
- How do you handle database migrations during releases?
- What's the balance of new features and maintenance right now?
- How do developers hear from users?
Preparation tips
- Polish one small full stack project you can demo, with a real database and authentication.
- Revise the basics on both sides: HTTP and caching, SQL joins, and your framework's rendering model.
- Be ready to say where a piece of logic belongs (browser, API, database or background job) and why.
- Practise building a small CRUD feature with tests in about two hours; many loops include one.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for full stack developer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
The live skills section is based on 479 full stack developer job ads analysed, the newest we track, with the same deterministic skill matcher as our in-demand skills report: no AI model reads the postings. It was last computed on November 2, 2026 and refreshes daily.
Last reviewed on November 1, 2026.