Why pre-screen frontend developers before the technical exercise
Frontend candidates converge on the same framework list, and the framework is rarely the problem. What separates people is whether they have shipped to a real audience: whether they checked the layout on a small screen, whether the page is usable with a keyboard, and whether they profiled before optimising. Those habits produce a visibly different product and are invisible on a resume. A short screen surfaces them cheaply.
What actually matters when screening Frontend Developer candidates
- 01
Technical proficiency
Check depth in React or Vue with TypeScript: state management choices, hooks pitfalls, CSS architecture, bundler config (Vite, Webpack), and WCAG keyboard and ARIA work.
- 02
Systems and trade-offs
Probe how they reason about bundle size, hydration versus client rendering, component API design, and when they chose a framework, a library, or plain DOM.
- 03
Evidence and rigour
Test measurement habits: Core Web Vitals from field data, Playwright or Cypress coverage, visual regression checks, and how they proved a refactor improved anything.
- 04
Collaboration and communication
Assess handoff with designers in Figma, negotiation with backend teams over API shape, and how they handled review comments on large pull requests.
Pre-screening questions to ask Frontend Developer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Interfaces they shipped
4 questions01Can you provide examples of websites or applications you have developed?
Listen forLive links with a clear statement of which parts they built, and what they would change about them now.
Projects with no live example, or team work presented without separating their own contribution.
02What is one project you have done that you are proud of, and why?
Listen forPride grounded in a problem they solved rather than in the technology used, with the difficulty described.
The answer is about the stack rather than the outcome, or a project with no users.
03Which frontend frameworks have you worked with?
Listen forReal depth in one with an honest view on where it is a poor fit, rather than equal claims across several.
Frameworks listed with no shipped work, or an inability to work without a framework at all.
04Which JavaScript framework do you have the most experience with?
Listen forDepth demonstrated through a specific problem, such as state management or rendering behaviour they had to reason about.
Framework knowledge that stops at following its documentation, or no understanding of what it does underneath.
Beyond their own browser
3 questions05Are you familiar with responsive web design?
Listen forLayout driven by content with real device testing, and a specific layout that was difficult to make work small.
Responsiveness equated to using a framework's grid, or no testing on an actual phone.
06Do you have experience with cross-browser compatibility issues?
Listen forA specific browser difference they hit and how they found it, with a view on which browsers they test in.
Testing only in the browser they develop in, or compatibility assumed because a build tool handles it.
07Have you worked with CSS preprocessors or modern CSS tooling?
Listen forA view on how they structure styles so they stay maintainable, with what happens as a codebase grows.
Styles written with no structure, or specificity fought with repeated overrides.
Performance measured
3 questions08Are you familiar with performance optimisation techniques for frontend development?
Listen forA problem found by profiling with the metric and the number before and after, plus what the fix cost.
Optimisation applied without measurement, or performance discussed only as bundle size.
09Are you knowledgeable about web accessibility standards?
Listen forSemantic markup, keyboard order and focus visibility covered, ideally with screen reader testing they have done.
Accessibility reduced to adding attributes, or no testing beyond an automated linting rule.
10What tools do you use for debugging and troubleshooting frontend code?
Listen forBrowser tools used properly, including network and rendering panels, with a bug they diagnosed that way.
Debugging described as adding log statements, or no use of the browser's own tooling.
Working with design
2 questions11Do you have experience collaborating with design colleagues?
Listen forA working relationship where they push back on something impractical and implement the rest faithfully.
Designs implemented approximately, or every design decision questioned rather than the ones that matter.
12Are you comfortable working with APIs and integrating them into frontend applications?
Listen forLoading, empty and error states handled deliberately, with what they do when a request is slow or fails.
Only the successful response handled, or errors surfaced to users as raw messages.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names specific patterns used, explains hook dependency bugs or focus management fixes, and shows real accessibility remediation beyond a Lighthouse score.
Systems and trade-offs
25%5Weighs LCP and INP costs against developer velocity, cites a decision they later reversed, and explains the reasoning behind it.
Evidence and rigour
25%5Quotes before and after numbers from real users (RUM or CrUX), plus the test suite that stopped a regression reaching production.
Collaboration and communication
15%5Describes pushing back on an unbuildable design or payload, then landing a compromise both sides shipped without rework.
Frontend resumes converge on the same framework, which is rarely the problem. A one-way video screen asks what they shipped and what they measured.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for a frontend developer take?
Ten to fifteen minutes across eight to ten questions, answered async, with links to shipped work. Enough to establish what they built, test their browser and accessibility habits, and hear one performance problem.
Should I screen for a specific framework?
Only if you have a real constraint. Strong frontend developers move between frameworks in weeks, and filtering on one narrows the pool far more than it raises quality. Screen for CSS, browser behaviour and accessibility instead.
Evaluating answers
What is the strongest signal when screening a frontend developer?
A performance problem they measured. Real answers name the metric and the number before and after. Anyone describing optimisation without measurement has been guessing, and guessing on the frontend usually adds weight.
How do I judge accessibility answers?
Ask what they do beyond adding attributes. Sound answers cover keyboard order, focus visibility and semantic markup, and mention testing with a screen reader. Anyone who names only a linting rule has not tested anything.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
