Full Stack Developer interview questions and practice.
Works across both the front end and back end of web applications, from user interfaces to APIs and databases. An interviewer hiring a Full Stack Developer is not testing whether you know what the job is. They are trying to establish whether you can be handed a half-defined problem and be trusted to ship something that still works in six months, without anyone standing over you.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
What interviewers for Full Stack Developer actually ask
Three questions from the bank below, each scored against one competency. The follow-up is what separates a prepared answer from a memorised one.
Walk me through the design of the last non-trivial thing you built. Why that shape and not a simpler one?
Tell me about a time the requirements you were given did not make sense.
Tell me about a production incident you were involved in.
What they are really assessing
That gets scored against 7 competencies: problem decomposition & design, code quality & testing discipline, debugging & production incidents, systems & data fundamentals, delivery & scope management, code review & technical collaboration and ownership beyond the ticket. Each one is assessed from the specifics in your answers, which is why "we improved the process" scores lower than a sentence with a number, a date and a decision in it.
At mid level they assume you can do the job and are testing how you handle the parts that go wrong. Expect them to push hardest on design trade-offs with real numbers, production incidents they owned, and how they broke down and delivered a multi-week feature.
Problem decomposition & design
Breaks an ambiguous requirement into components, chooses appropriate data structures and boundaries, and can explain the trade-offs of the design they picked.
- Weak
- Describes the solution only at the level of 'I built the feature'; cannot name alternatives considered or why the chosen approach was better; trade-offs are absent or generic.
- Adequate
- Explains the main components and one or two real trade-offs (e.g. consistency vs latency) but the reasoning is partly post-hoc and constraints are vague.
- Strong
- Walks through the constraints first, names 2-3 options with concrete pros/cons, states what they would change in hindsight and cites measurable outcomes (latency, error rate, cost).
Code quality & testing discipline
Writes code that others can read and change safely, and uses tests deliberately to protect behaviour rather than to hit a coverage number.
- Weak
- Talks about tests as something added at the end or required by the pipeline; cannot describe what a given test protects against or a bug that a test caught; 'clean code' is asserted, not shown.
- Adequate
- Describes unit and integration tests they wrote and a review comment they acted on, but cannot say which tests were most valuable or how they decided what not to test.
- Strong
- Explains how they chose the test boundary (unit vs contract vs end-to-end), gives a concrete bug caught or missed and what changed as a result, and describes a refactor they made safe with tests first.
Debugging & production incidents
Finds the root cause of unexpected behaviour methodically using logs, metrics and reproduction, and closes the loop so the same failure does not recur.
- Weak
- Debugging stories consist of 'I tried things until it worked' or restarting the service; no hypothesis, no use of logs or metrics, and no follow-up after the fix.
- Adequate
- Describes forming a hypothesis and using logs or a debugger to confirm it, and shipped a fix, but the root cause is uncertain and there was no post-incident action beyond the patch.
- Strong
- Gives a specific incident with a timeline: symptom, how they narrowed scope (bisecting, correlating metrics, reproducing locally), the confirmed root cause, the fix, and the alert, test or design change that prevents recurrence.
Systems & data fundamentals
Understands how their code behaves on a real machine and network: concurrency, memory, I/O, databases, caching and the failure modes of distributed calls.
- Weak
- Treats the database, network and framework as black boxes; cannot explain why a query was slow, what happens under concurrent writes, or what a timeout on a downstream call should do.
- Adequate
- Can explain indexing, N+1 queries, basic caching and retries, and has applied at least one of these to a real performance or reliability problem, though numbers are approximate.
- Strong
- Explains a real bottleneck they diagnosed with measurements (p99, query plans, CPU/memory profiles), the fix chosen and rejected alternatives, and reasons about idempotency, back-pressure and partial failure without prompting.
Delivery & scope management
Ships working software on a predictable cadence by slicing work, surfacing risks early, and negotiating scope rather than silently missing dates.
- Weak
- Estimates are guesses and slips are explained by 'unexpected complexity'; cannot describe breaking a feature into shippable increments or telling anyone early that a date was at risk.
- Adequate
- Describes breaking a feature into tickets and flagging a delay to the manager, but the slicing is technical layers rather than user-visible increments and the flag came late.
- Strong
- Gives an example of cutting scope to hit a date with the product owner's agreement, explains what was deferred and why it was safe, and shows how they reduced risk by shipping the riskiest piece behind a flag first.
Code review & technical collaboration
Gives and receives code review that improves the codebase, and works through technical disagreements with evidence rather than seniority or volume.
- Weak
- Describes review as approving or nitpicking style; cannot give an example of a review that changed a design, or of being wrong in a technical argument.
- Adequate
- Gives an example of a substantive review comment and of accepting one, but disagreements are resolved by deferring to whoever is more senior rather than by evidence.
- Strong
- Describes a technical disagreement resolved by a prototype, benchmark or written proposal; explains how they review for correctness and design rather than style, and how they calibrate tone for a junior versus a peer.
Ownership beyond the ticket
Takes responsibility for the system and its users rather than only assigned tasks: notices problems, fixes what is broken, and follows work through to production and beyond.
- Weak
- Work ends at 'merged'; describes production issues as the ops team's or the on-call's problem; cannot name an improvement they made that nobody asked for.
- Adequate
- Follows their changes to production and checks dashboards, and has fixed something outside their ticket, but does not systematically look for the next problem.
- Strong
- Gives concrete examples of catching a problem nobody assigned (flaky test, misleading metric, on-call pain), the fix and its measured effect, and of staying with a rollout until users confirmed it worked.
10 questions you should expect
What a strong answer contains, not a model answer to memorise. A memorised answer falls apart on the first follow-up, and there is always a follow-up.
Walk me through the design of the last non-trivial thing you built. Why that shape and not a simpler one?
Scored against: Problem decomposition & designA strong answer contains: The actual problem before the solution, two options you weighed with the trade-off between them named out loud, the constraint that decided it (deadline, team size, existing system, data volume), and one thing you would design differently now that you have run it in production.
And then they askWhat was the simplest version that could have worked, and what did the extra complexity buy you?
Tell me about a time the requirements you were given did not make sense.
Scored against: Problem decomposition & designA strong answer contains: The specific contradiction or gap, who you went to and what you asked them, and the fact that you kept moving on the unambiguous parts while you waited. Interviewers are watching for whether you escalate or quietly build the wrong thing.
And then they askHow long did you sit on it before raising it, and would you raise it sooner now?
Tell me about a production incident you were involved in.
Scored against: Debugging & production incidentsA strong answer contains: The symptom and how you found out, your first hypothesis and the signal you checked to confirm or kill it, what you did to stop the bleeding versus fix the cause, a number for the impact, and the change you made afterwards that has held since.
And then they askWhat did you rule out first, and what would you add to the monitoring so you found out sooner next time?
Describe a bug that took you far longer than it should have. What made it hard?
Scored against: Debugging & production incidentsA strong answer contains: An honest account of the wrong assumption you held, how you eventually broke it (a reproduction, a bisect, a log line, someone else's fresh eyes), and what you changed in how you debug because of it.
And then they askAt what point should you have asked for help, and what stopped you?
How do you decide what to test and what not to test?
Scored against: Code quality & testing disciplineA strong answer contains: A rule you actually apply rather than "everything should be tested": branching logic and money-touching paths get covered, thin mapping code that changes weekly does not. Ideally an example of a bug that reached production and the test you added because of it.
And then they askTell me about a test you deleted, and why.
Tell me about a piece of code you inherited that you had to change without breaking it.
Scored against: Code quality & testing disciplineA strong answer contains: How you built confidence before touching it (characterisation tests, feature flags, a shadow run, a narrow first change) rather than "I read it carefully". A specific thing you deliberately left alone matters as much as what you fixed.
And then they askWhat did you decide not to refactor, and how did you justify leaving it?
A read endpoint has got slow as the table grew. How do you work out why?
Scored against: Systems & data fundamentalsA strong answer contains: Measure before guessing: where the time actually goes, the query plan, whether the index matches the access pattern, N+1 calls, payload size. A strong answer treats caching as a decision with an invalidation cost, not a first move.
And then they askSuppose the query plan looks fine. Where do you look next?
Tell me about a deadline you were going to miss.
Scored against: Delivery & scope managementA strong answer contains: When you knew, who you told and how early, what you offered to cut rather than just asking for more time, and what actually shipped. The tell is whether the warning came before or after the date.
And then they askWhat was the earliest moment you could have known, and what would have shown you?
Tell me about a code review where you disagreed with the reviewer, or where you were the reviewer.
Scored against: Code review & technical collaborationA strong answer contains: The technical substance of the disagreement, how you separated preference from correctness, and how it resolved. Being talked round on evidence is a strong answer; so is holding a line and saying what would have changed your mind.
And then they askHow do you raise a serious problem in a review without it becoming personal?
What happened to the last feature you shipped after it went live?
Scored against: Ownership beyond the ticketA strong answer contains: That you actually looked: adoption, error rate, latency, a support ticket you chased down. Best of all, something you changed or removed afterwards because the numbers said the original idea did not land.
And then they askDid anything you built turn out not to be worth it? What did you do about it?
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Full Stack Developer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns medium-sized features or a service area independently, including design, rollout and on-call for it; accountable for its quality in production.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: aPI design and versioning for a public or partner-facing interface, debugging a production incident from logs, metrics and traces and designing a relational schema and choosing indexes for a known query pattern, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns well-defined features or bugs end to end (code, tests, deploy) with review; expected to write tests and read logs without being told. | Owns medium-sized features or a service area independently, including design, rollout and on-call for it; accountable for its quality in production. | Owns a system or domain across multiple services and its technical direction; accountable for reliability, scalability and the team's technical decisions in that area. |
| Tolerance for ambiguity | Handles tickets with some gaps by asking targeted questions; should not need every edge case spelled out. | Turns a one-paragraph product ask into a design and a plan; identifies unknowns and resolves them with the right people. | Defines the problem from a business goal, pushes back on requirements that do not make sense, and makes decisions with incomplete data that they can defend later. |
| People leadership | None formally; may pair with an intern. | Mentors juniors, reviews most of the team's PRs, may lead a small feature with one or two others. | Technical mentor to the team, drives design reviews, sets standards; may lead projects with several engineers without line authority. |
| Who they deal with | Own team, tech lead, occasionally QA or a product owner. | Product manager, QA, adjacent engineering teams, occasionally support or customers when investigating issues. | Product leadership, architects, platform and security teams, other teams depending on their system. |
Where candidates lose this interview
Describing the team's work, not yours
"We decided", "we noticed", "the team fixed it". Every answer in the plural reads as either modesty or evasion, and the interviewer cannot score either. They need one sentence per story that starts with "I". Say what the team did, then say what you personally did inside it.
Designing for a scale you never had
Reaching for queues, sharding and microservices on a system with two thousand daily users tells the interviewer you optimise for sounding senior rather than for the problem. Name the actual load, then justify the design against it. Choosing the boring option and saying why is a strong answer, not a weak one.
No numbers anywhere
"It got much faster", "a lot of users", "quite a big table". Engineers who did the work remember roughly what the numbers were. If you genuinely do not know, say the order of magnitude and say you are estimating: that scores far better than a vague adjective.
The incident story with no personal decision in it
Candidates narrate an outage as a sequence of events that happened to them. What is being scored is judgement under pressure: what you checked first, what you ruled out, whether you mitigated or fixed, and who you told. If the story has no decision you made, pick a different story.
Treating testing as an ideology
Both "I always write tests first" and "tests slow us down" score badly, because neither is a judgement. Interviewers want a threshold you can defend and an example of applying it: including a case where you chose not to test something and were right, or were wrong.
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Full Stack Developer would have said them.
Walk me through the design of the last non-trivial thing you built. Why that shape and not a simpler one?
- The actual problem before the solution, two options you weighed with the trade-off between them named out loud, the constraint that decided it (deadline, team size, existing system, data volume), and one thing you would design differently now that you have run it in production
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report