Full Stack Developer interview scorecard template
A structured scorecard for interviewing a Full Stack Developer: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The Full Stack Developer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Frontend implementation and UI state Whether the candidate can build interfaces that hold up under real data and real state changes, not just render a static happy path. | 18% | Describes components they built but cannot explain how loading, error and empty states were handled, or why a re-render loop appeared in one of them. | Walks through a specific state bug — a stale cache, a race between two fetches — names how they reproduced it and what the fix changed in the render path. |
| API and backend design Whether they design endpoints and contracts that survive change, since a full stack hire owns both sides of every interface they ship. | 18% | Lists frameworks they have used but cannot say why an endpoint returned the shape it did, or what broke when a client needed a new field. | Explains a contract they versioned or deprecated, who was consuming it, and how they rolled the change out without breaking the clients already in production. |
| Data modeling and query behavior Whether they can shape a schema and reason about what the database actually does, which is where most full stack performance problems begin. | 16% | Writes queries that return the right rows but cannot explain why a join duplicated them or how they confirmed the row count was correct. | Points to a schema decision they made — a denormalization, an index, a nullable column removed — and the query behavior or bug that motivated it. |
| Cross-stack debugging Whether they can follow a failure from the browser through the API to the database, instead of guessing at the layer they know best. | 18% | Describes production issues in terms of what was fixed, with no account of how the cause was isolated or what evidence ruled the other layers out. | Reconstructs one incident end to end: the symptom, the logs or traces they read, the hypotheses they eliminated, and how they confirmed the fix held. |
| Shipping and release practice Whether their code reaches users safely: tests that catch real regressions, deploys they can reverse, and changes sized to be reviewable. | 16% | Talks about tests and CI in general terms but cannot name a bug their tests caught, or describe how a bad deploy was rolled back. | Describes their release routine concretely: what is covered by tests and what deliberately is not, how a change reaches production, and the last rollback they ran. |
| Scope judgment and product sense Whether they push back on work that will not survive contact with users, which matters because full stack roles sit close to product decisions. | 14% | Reports requirements as handed down and cannot recall a time they questioned one, or names conflict as the reason they stopped asking. | Recalls a specific ticket they renegotiated, the cost or risk they surfaced, who they raised it with, and what the team shipped instead. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Walk us through a bug that took you more than a day to find. What was the symptom, what did you check first, and what turned out to be wrong?
- Describe an API you designed that later had to change. Who was consuming it, how did you version or migrate it, and what broke anyway?
- Tell us about a query or a page that got slow in production. How did you measure it, and what did the fix actually change?
- What is the last change you rolled back or had to hotfix? How did you find out it was bad, and how long did that take?
- Describe a feature where you pushed back on the requirement. What was your argument, who did you make it to, and what shipped in the end?
Red flags
- Cannot name a single production bug they personally diagnosed, only features they delivered.
- Defines full stack as having used a framework on both sides, with no ownership of data or deploys.
- Attributes every technical decision to the team or the tech lead, with no account of their own reasoning.
- Dismisses tests, code review or rollbacks as process overhead without describing what they use instead.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a Full Stack Developer →
Frequently asked questions
What should a full stack developer interview actually cover?
Cover both sides of the stack with the same rigor: one interface or state problem, one API and data modeling problem, and one debugging exercise that crosses layers. Then confirm shipping practice — tests, deploys, rollbacks — because that is where full stack ownership is either real or not.
How do I tell a strong full stack developer from someone with shallow coverage of both sides?
Depth shows up in causes, not in tools. Ask for a specific failure and listen for how it was isolated: which layer was ruled out, and what evidence did that. Shallow candidates list technologies; strong ones name symptoms, hypotheses and the check that settled it.
How do I keep scoring consistent across full stack candidates?
Fix the competencies and weights before the first interview, score every candidate against the same anchors, and write the evidence next to each score. Verdict works the same way on the CV side — every score is tied to a cited snippet, so candidates are compared on the record rather than on impressions.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.