Questions to Ask a Full Stack Developer
Twenty interview questions for a full stack developer, aimed at what someone has actually shipped rather than what they can recite. They cover ownership boundaries, database and state decisions, migrations against live data, deployment and rollback, authentication, incidents, testing across a third party boundary, and accessibility. Each one notes what a strong answer contains and what a weak one sounds like.
The questions
Open any question for the note
Walk me through something you built end to end. What did you own, and who owned the rest?
Why ask it
The scope of ownership is the entire question behind a full stack claim. Listen for the parts they did not build. Candidates who describe owning everything on a team of six are usually inflating, and the ones who say a colleague handled infrastructure are the ones you can believe about the rest.
What did you choose for the database on that project, and what would have gone wrong with the other option?
Why ask it
There is no right answer here, only evidence that a decision was made. Strong candidates describe the shape of the data and how it gets read. Weak ones say it is what the team already used, which means they have never watched a database choice hurt.
Where does the state live in the last frontend you worked on, and what went wrong with that arrangement?
Why ask it
State management is where frontends rot. The second half is the useful half: duplicated server data, a global store that turned into a junk drawer, cache invalidation nobody owned. Someone reporting no problems has worked only on small apps or was not watching.
Tell me about the last schema migration you ran against a table with live traffic on it. What was the rollback plan?
Why ask it
Migrations on live data separate people who have deployed from people who have only committed. Look for locking, batching, additive changes first, and a plan that does not depend on undoing data loss. No rollback plan means somebody else has always caught their mistakes.
How do you decide a change is finished? What is on your list before you open a pull request?
Why ask it
Definition of done exposes real habits: tests for the failure path, the migration run against a copy, screenshots, the ticket updated, dead code removed. Vagueness here reliably predicts pull requests that come back three times.
What is in your CI pipeline right now, and what makes it fail?
Why ask it
Ask about the pipeline they have rather than the one they would design. What they name as the usual failure, flaky tests, a lint step everyone skips, a deploy needing a manual click, tells you which daily friction they have learned to tolerate.
How do you ship a change to only some users?
Why ask it
Flags, canaries, and staged rollouts are the difference between shipping weekly and shipping nervously. Someone who has only ever released to everybody at once will not know how to unpick a bad deploy, which is exactly the hour you need them.
Users say the app is slow. How do you work out where the time is going?
Why ask it
The right instinct is measurement before theory: timings, the slow query log, the network panel, a profiler. Candidates who jump straight to adding a cache or changing framework are guessing, and guessing is expensive once traffic is real.
Walk me through how your app decides a request really comes from the user it claims to be. Explain it as if I were reviewing the code.
Why ask it
Asking for it at code level catches the gap between naming a library and knowing what it does. Listen for where tokens are kept, how they expire, and what logout actually invalidates. Hand-waving on this is the highest-risk answer in the whole interview.
What is the last security problem you found in your own code?
Why ask it
Everyone has shipped a vulnerability. What matters is whether they have ever gone looking, and whether they can describe one without defensiveness. A candidate who has never found any is usually not reviewing their own work with that lens at all.
How would you test a form that talks to a payment provider?
Why ask it
A third party boundary makes testing philosophy concrete: a sandbox account, recorded responses, a fake at the edge, one real end to end check. Anyone who says they click through it manually is telling you their release process runs on memory.
Describe the last production incident you were part of, from the alert to the fix.
Why ask it
Incidents show temperament more than skill. You want a sequence: what alerted, what they looked at first, who they told, what stopped the bleeding, what changed afterwards. Blame aimed entirely at another team is worth noting quietly.
What is in your logs, and how would you trace one user's failed request through the system?
Why ask it
This separates developers who can hold a pager from developers who cannot. Good answers mention request identifiers, structured logs, and following one transaction across services. If the answer stops at printing to the console, debugging there happens by guesswork.
What does accessibility mean in practice for a form you have built, and what did you actually check?
Why ask it
This weeds out people for whom accessibility is a checkbox. Concrete answers involve keyboard order, labels bound to inputs, errors that get announced, and having used a screen reader at least once. Naming a standard without naming a check is not an answer.
What is the ugliest code you own, and why is it still there?
Why ask it
Inviting them to criticize their own work shows whether they can hold two ideas at once: this is bad, and shipping it was correct. It also reveals how they talk about deadlines and other people's decisions when nobody from that team is listening.
How much of your last codebase did you not understand, and what did you do about that?
Why ask it
Every real codebase has regions its maintainers route around. Honest answers involve reading it, adding tests before touching it, or finding the one person who remembers. A claim of complete understanding means the project was tiny, or the claim is not true.
Tell me about a time you disagreed with a product decision.
Why ask it
You are looking for someone who argued with evidence and then committed to the result. The two failure modes are the developer who quietly built it badly to prove a point, and the developer who has never once questioned a requirement.
What have you changed about the way you work in the last year, and what caused it?
Why ask it
Ask for the cause rather than the reading list. Real answers trace back to an outage, a bruising review, or a project that went sideways. A list of frameworks means they follow release notes, which is not the same as having learned something.
What kind of work do you not want to do?
Why ask it
Late in a conversation this gets an honest answer, and it protects both sides. Someone who dislikes being on call, avoids frontend work, or wants no part of customer calls is telling you precisely how the role ends badly if it includes those things.
What do you want to know about how we work here?
Why ask it
Their questions show what they have lived through. On-call rotation, review turnaround, who decides scope, how deploys happen: these come from someone who has been in a badly run team and is checking. No questions at all is the weakest signal in the interview.
Running the interview
Practical guidance for the conversation itself
Structure that gets you real signal
- Pick one system they actually built and stay inside it for twenty minutes. Depth on one project beats a tour of eight technologies, because a rehearsed summary falls apart under a third follow-up question.
- Ask about the last time rather than the general approach. How do you handle migrations produces the textbook; tell me about the last migration you ran produces the truth.
- Give them the codebase problem you actually have. If your real difficulty is a five-year-old application nobody wants to touch, ask how they would work in it rather than how they would design a new one.
- Let them use documentation and a search engine during any live exercise. You are hiring the version of this person who will have both.
What to stop doing
- Trivia about syntax, method names, and framework versions. It measures recall and biases toward whoever interviewed most recently.
- Unpaid take-home projects longer than a couple of hours. They select for candidates with free evenings rather than for skill, and strong candidates with children or a current job simply decline.
- Asking the same person to prove both deep frontend craft and deep infrastructure knowledge, then rejecting them for being weaker on one. Almost every full stack developer leans one way. Decide which lean you need before the interview, not during it.
- Treating a candidate's nerves as a signal about their engineering. Give them the questions in advance if you want to see how they think rather than how they perform.
Reading the answers
- Count the trade-offs they name unprompted. Experienced developers volunteer the cost of their own choices; less experienced ones present decisions as obvious.
- Notice who they credit. Someone who names the colleague who found the bug or designed the schema is describing how they actually work in a team.
- Distrust polish on incidents. A story with no confusion in the middle has been sanded down, and the confusion is the part you wanted to hear about.
- Follow anything vague once, then move on. One clarifying question is fair; three turns the interview into an interrogation and tells you nothing new.
If you are the candidate
Prepare one project you can discuss for twenty minutes at any depth, including the parts you got wrong and what you would do differently. Say plainly which side of the stack you are stronger on, because claiming even mastery of everything reads as inexperience to anyone who has done the job. Ask about on-call expectations, how long code review takes, how often deploys happen, and who decides what ships. If those answers are vague or defensive, you have learned more about the job than any technical exercise would have told you.