Backend Developer interview scorecard template
A structured scorecard for interviewing a Backend 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 Backend Developer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Data modeling and storage design Whether the candidate models data around access patterns and invariants rather than convenience, since a wrong schema is the hardest thing to undo later. | 20% | Describes tables without naming a single constraint or index; treats schema migrations as something the ORM handles whenever the code changes. | Explains which invariants the database enforces versus the application, and describes a migration they ran on live data without downtime or data loss. |
| API design and contracts Whether the candidate designs endpoints consumers can use without reading the implementation, which determines how much support load each integration creates. | 18% | Shapes endpoints around the screen of the moment; changes response fields without versioning and describes broken clients as their problem to fix. | Explains a compatibility decision — additive change, versioned route, deprecation window — and how consumers were notified and migrated off the old shape. |
| Concurrency, consistency and failure handling Whether the candidate reasons about what happens when two requests collide or a downstream call fails, which is where most backend data corruption starts. | 18% | Assumes requests arrive one at a time and that calls succeed; adds a retry without asking whether the operation can safely run twice. | Names where they applied idempotency keys, locks or transactions, and explains the failure they were guarding against and how they tested it. |
| Query and throughput performance Whether the candidate can find the query or call path that dominates latency under real load, instead of optimizing code that was never the bottleneck. | 15% | Attributes slowness to the database in general; has never read an execution plan and cannot say which query ran most often. | Describes the measurement that isolated the hot path, the index or query rewrite applied, and how latency and load changed afterwards. |
| Security and data handling Whether authorization, input validation and secret handling are part of how the candidate builds, since backend mistakes here expose data directly. | 15% | Treats security as the infrastructure team scope; checks authentication but not whether the authenticated caller may touch that particular record. | Describes an authorization check they added at the data layer, and can explain how secrets and personal data are handled in code they wrote. |
| Observability and operational ownership Whether the candidate instruments services so a problem can be diagnosed from outside, which determines how long an incident lasts at three in the morning. | 14% | Logs only errors and only in development; learns about production failures when a user or another team reports them. | Names the metric or trace that made a past incident diagnosable, and describes an alert they added or removed after it proved noisy. |
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 me through a schema you designed and later had to change. What did the migration touch, how much data was live, and what did you do to avoid downtime?
- Describe a bug you fixed that only showed up under concurrent requests. How did you reproduce it, and what did the final fix guarantee?
- Tell me about an API change of yours that broke a consumer. How did you find out, and what did you change about the way you release contracts?
- Point to a query you made faster in production. What did the execution plan show before, and what was the latency after the change?
- What is the last authorization gap you found in code, yours or someone else's? How was it discovered, and what did the fix change?
Red flags
- Talks about scale in terms of technology names rather than the load a system actually handled.
- Has never looked at a query plan and cannot name the slowest endpoint in a service they owned.
- Describes data loss or corruption as impossible rather than as a risk they deliberately designed against.
- Treats authorization, retries and backups as another team responsibility in every example given.
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 Backend Developer →
Frequently asked questions
What should you look for when hiring a backend developer?
Evidence that they have owned data and traffic, not just written endpoints: a schema they migrated, a concurrency bug they reproduced, a query they measured and fixed. Ask what broke in production and how they found out. Language and framework experience matters less than whether they can reason about failure.
How do you assess backend system design without a whiteboard round?
Ask about a system the candidate actually built and push on the boundaries: why those services, what the database enforces, what happens when a downstream call fails. A real system exposes trade-offs a hypothetical design does not, because the candidate had to live with the consequences.
How should a backend interview scorecard be weighted?
Weight the competencies the role can fail on. A data-heavy service should put more weight on modeling and query performance; an integration-heavy one on API contracts and failure handling. Keep the weights adding to 100, write the anchors before the interview, and score each answer against the evidence the candidate gave rather than an overall impression.
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.