Frontend Developer interview scorecard template
A structured scorecard for interviewing a Frontend 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 Frontend Developer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Component and UI architecture Whether the candidate designs components that stay composable as a product grows, which determines how much of the interface has to be rewritten each quarter. | 20% | Describes components by the screen they appear on; cannot explain when a prop should become a slot, a context or a separate component. | Explains where they drew the boundary between presentational and stateful components, and names a duplication they collapsed and one they deliberately left alone. |
| Rendering and front-end performance Whether the candidate can tie a slow interface to a measured cause — bundle size, layout thrash, re-renders — rather than applying generic optimizations. | 18% | Lists optimizations as habits — memoize, lazy load, compress images — with no before-and-after number and no idea which one actually helped. | Names the metric that was bad, the profiling tool that located it, the change that was made, and the measured result after that change shipped. |
| Accessibility and semantic markup Whether accessibility is built into the markup from the start or bolted on after an audit, which decides how much of the interface works by keyboard and screen reader. | 16% | Treats accessibility as adding aria attributes at the end; builds interactive controls out of div elements and cannot describe the keyboard path through a form. | Reaches for native elements before aria, has tested a real flow with a keyboard or a screen reader, and can name a specific pattern they fixed. |
| Client state and data fetching How the candidate separates server data from local UI state, which governs how often the interface shows stale or contradictory information to users. | 16% | Puts every value into one global store; describes loading and error handling as something the library takes care of automatically. | Distinguishes cached server data from ephemeral UI state, and describes a concrete race or stale read they hit and how the fix changed the data flow. |
| Cross-device behavior and design fidelity Whether the candidate ships an interface that holds up across viewports, input types and content lengths, which is where most front-end rework originates. | 15% | Checks work only at their own screen size; treats a broken layout on a narrow viewport or with long text as an edge case for later. | Describes testing with real content lengths and touch input, and names a case where they pushed back on a design that could not survive a long string. |
| Working with design and API contracts Whether the candidate resolves gaps in a design or an endpoint early instead of guessing, which determines how much of a sprint is spent on rework. | 15% | Builds what the mockup shows and reports blockers only at review; describes missing states as something design or backend should have specified. | Names states the design omitted — empty, error, loading, long text — and describes negotiating a response shape with the backend before implementing. |
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.
- Describe an interface you made measurably faster. What number was bad before, what did the profile point to, and what was the number after?
- Tell me about a component that got reused in ways you did not anticipate. What broke, and how did you change its interface afterwards?
- Describe the last time you tested a flow with only a keyboard or a screen reader. What did you find, and what did you change in the markup?
- Walk me through a design handoff where the mockup did not cover a real state. How did you find the gap, and who did you go to?
- What is a bug in your own front-end code that appeared only on a specific device or browser? How did you reproduce it without that device in front of you?
Red flags
- Describes the work entirely in framework terms and cannot explain what the browser is doing underneath.
- Treats accessibility as a legal checkbox or as something a plugin resolves at the end of a project.
- Reports performance improvements with no measurement before or after, only a claim that it feels faster.
- Blames design or backend for every rework and cannot cite a question they asked before building.
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 Frontend Developer →
Frequently asked questions
What competencies belong on a frontend developer scorecard?
Component architecture, rendering performance, accessibility, client state and data fetching, cross-device behavior, and collaboration with design and backend. Weight them by what the role will actually spend time on — a design-system role and a product-feature role are not the same job. Keep the weights adding to 100 so every interviewer scores on the same scale.
Should a frontend interview include a live coding exercise?
A short exercise close to real work is more informative than an algorithm puzzle: build a small component with a loading and an error state, or fix a layout that breaks on a narrow viewport. Let the candidate use the tools they normally use. What you are scoring is how they decide, not whether they remember an API.
How do you tell a strong frontend developer from someone who only knows a framework?
Ask what the browser is doing underneath, and what happened when the framework did not solve the problem. Strong candidates can explain a rendering or layout issue without framework vocabulary and can point to a measured fix. Scoring each answer against written anchors, with the candidate evidence cited next to the score, keeps that judgment consistent across interviewers.
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.