Role interview guide
Full-stack developer interview questions and what to expect
Full-stack developer interviews usually check that you can build a feature end to end: a working interface, the API behind it and the database underneath. Candidates commonly report a take-home or live exercise building a small app, then questions on JavaScript or the role's main language, databases and deployment; experienced candidates are often asked to design a whole feature.
What candidates commonly report; it varies by employer, level and country. Last reviewed 18 October 2026.
The usual stages
- 1Recruiter or HR screen
- 2Take-home or online test: often a small app with a frontend, an API and a database
- 3Technical interview: walk through your code, then extend or fix it live
- 4Fundamentals across the stack: JavaScript, a framework, APIs, databases and deployment
- 5Feature or system design for experienced roles
- 6Hiring manager or behavioural round
What interviewers check
- Building something that works end to end, not just one layer
- Knowing where logic belongs: browser, server or database
- Sound data modelling and API design
- Security basics on both sides: validation, authentication and secrets
- Getting code deployed and running, not only working locally
- Pragmatism: choosing simple tools and shipping
Behavioral questions
Tell me about a time you delivered a feature on your own across frontend and backend under a deadline.
A good answer covers
- The scope, and what you cut to make the deadline
- How you split the work between screens, API and data
- What shipped and what you cleaned up afterwards
Describe a bug that turned out to be in a different layer from where you first looked.
A good answer covers
- The symptom and where you first looked
- How you traced it across the browser, network, server and database
- The real cause and what it taught you about debugging
Tell me about a time you had to learn a new framework or tool quickly for a project.
A good answer covers
- Why it was needed and how much time you had
- How you learned: the docs, a small prototype, someone experienced
- What you built, and what you'd do differently
Tell me about a time you pushed back on a feature request or suggested a simpler way to do it.
A good answer covers
- The request and the cost you saw in it
- The simpler option and how you made the case
- The outcome for users and the team
Questions about the job
Walk me through an app you've built: the stack, how data flows from a click to the database, and why you chose each part.
A good answer covers
- A short picture of the frontend, API, database and hosting
- One request traced from the click to the database and back
- A choice you'd make differently now, and why
Talk me through how you'd build a simple notes app with login, from the database tables up to the screens.
A good answer covers
- Tables or collections for users and notes, with each note tied to its owner
- API endpoints that check the user is logged in and owns the note on every request
- Screens with loading and error states, and how it gets deployed
Where should input validation happen: in the browser, on the server, or both? Why?
A good answer covers
- The browser for quick feedback to users
- The server because anything sent from a client can be changed
- Database constraints as a last line of defence
How does a login session work across the frontend and backend? Compare cookies and tokens.
A good answer covers
- Server-side sessions with a cookie versus self-contained signed tokens
- Where tokens are stored and the risks of each: cross-site scripting, CSRF
- Expiry, logout and refreshing a session
What is CORS, and why might a request work from Postman or curl but fail from the browser?
A good answer covers
- The browser's same-origin rule, and what CORS headers allow
- Preflight requests for some methods and headers
- Fixing it on the server by allowing the right origins, not a wildcard everywhere
In a MERN-style app, when would you use MongoDB, and when would a relational database be the better choice?
A good answer covers
- Documents suit nested data that's read together; relational suits many relationships and joins
- Consistency needs, such as orders and payments
- Explaining the choice you made in your own project
How do you deploy a full-stack app, and how do you keep secrets such as API keys out of the code?
A good answer covers
- A build step, hosting for the frontend and the API, and a managed database
- Environment variables or a secrets manager, never committed to Git
- Separate settings for development, staging and production
A list page gets slow once there are thousands of records. What would you change across the stack?
A good answer covers
- Pagination or infinite scroll instead of loading everything
- An index for the query, and returning only the fields the page needs
- Caching, and a loading state so the page feels responsive
How would you add live updates, such as chat messages or order status, to an existing web app?
A good answer covers
- Polling, server-sent events and WebSockets, and when each fits
- Reconnecting, and messages that arrive late or out of order
- Making it work with more than one server
When an API changes, how do you keep the frontend and backend in step?
A good answer covers
- Shared types or an API schema, and versioning
- Tests that check the API contract
- Changing in steps so older clients keep working
Talk me through how you'd let users upload and display a profile photo safely.
A good answer covers
- Checking file type and size on the server, not just in the browser
- Storing files in object storage rather than the database, and serving them through a CDN
- Resizing images, and controlling who can see them
Motivation and fit
Do you see yourself leaning more towards frontend or backend over time? Why?
A good answer covers
- An honest answer, with an example of work you enjoyed
- Why knowing the whole stack still helps in that direction
- What you're learning now
Why do you want to work here as a full-stack developer?
A good answer covers
- Something specific about the product or its users
- How your experience fits the stack the team uses
- What you'd hope to own in your first year
Tips
- Treat a take-home like work you'd ship: a README, clear setup steps, a few tests and a note on what you'd do with more time.
- Expect to change your take-home live; know your own code well enough to extend it without searching.
- Have a deployed project with a live link; it shows you can get past 'works on my machine'.
- Say which layer you're talking about as you answer; full-stack answers get muddled quickly otherwise.
- Don't list every technology you've touched; pick the stack you know best and be ready to go deep on it.
Practise it out loud
A mock interview asks what full-stack developer interviews usually test, follows up on your answers and gives you a report. The warm-up is free, needs no account and checks five of these questions as you answer.
About this guide
Written by Orbit from what candidates and interviewers commonly describe for this kind of job. The questions are Orbit's own practice questions, not questions taken from any employer's interviews. Processes change, so check the job post and what your recruiter tells you.