Web Developer interview questions and practice.
Builds and maintains websites and web applications, handling everything from page layout to the code behind forms and content.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Web Developer actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Structures components, data flow and state so that features can be added without regressions, and can justify where state lives and why.
Makes pages fast on real devices and networks by measuring Core Web Vitals, controlling bundle size and rendering work, and knowing which fix matters most.
Builds interfaces that work with keyboards, screen readers and assistive settings by using correct semantics and ARIA only where needed, and tests them.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
UI architecture & state management
Structures components, data flow and state so that features can be added without regressions, and can justify where state lives and why.
- Weak
- Describes state as 'we used Redux/Context' with no reasoning; cannot explain what goes in global versus local state, or give an example of a component structure that became unmaintainable and why.
- Adequate
- Explains the split between server state, URL state and local UI state for a real feature and one refactor they did to reduce prop drilling or re-renders, but cannot quantify the effect.
- Strong
- Walks through a real feature's data flow, names the alternatives rejected (e.g. a global store vs server-cache library), shows how they measured re-render or bundle impact, and what they would restructure in hindsight.
Web performance & loading
Makes pages fast on real devices and networks by measuring Core Web Vitals, controlling bundle size and rendering work, and knowing which fix matters most.
- Weak
- Performance work is described as 'lazy loading' or 'minifying' without measurement; cannot name LCP, CLS or INP or explain what caused a slow page they worked on.
- Adequate
- Has used Lighthouse or field data to find a problem (large images, blocking scripts, layout shift) and fixed it, but cannot say the before/after numbers precisely or how it behaved on a low-end device or 3G.
- Strong
- Gives before/after Core Web Vitals from field data, explains the root cause (render-blocking chain, hydration cost, unoptimised images), the fix chosen over alternatives, and how they set a budget so it did not regress.
Accessibility & semantic HTML
Builds interfaces that work with keyboards, screen readers and assistive settings by using correct semantics and ARIA only where needed, and tests them.
- Weak
- Treats accessibility as adding alt text or aria-labels afterwards; has never used a screen reader or keyboard-only navigation on their own work; cannot name a WCAG criterion.
- Adequate
- Uses semantic elements, manages focus in modals and checks contrast, and has fixed issues from an automated scan, but has not tested with a real screen reader or handled a complex widget's keyboard model.
- Strong
- Describes building or fixing a complex widget (combobox, data grid, dialog) with a correct focus and keyboard model, tested with NVDA/VoiceOver, and how they got accessibility into the team's definition of done.
Browser, network & JavaScript fundamentals
Understands the event loop, rendering pipeline, HTTP caching, CORS, cookies and security headers well enough to diagnose behaviour that the framework hides.
- Weak
- Relies entirely on the framework; cannot explain why an async callback ran late, what a CORS error means, or how the browser decides to repaint; debugging stops at 'it works in Chrome'.
- Adequate
- Explains the event loop, reflow vs repaint, and basic caching headers, and has debugged one real cross-browser or CORS issue, but is hazy on cookies, CSP or the critical rendering path.
- Strong
- Diagnoses a real problem beneath the framework (e.g. a memory leak from listeners, a layout thrash, a stale cache from wrong headers), explains it with the browser's mechanics, and describes the tooling used to prove it.
Frontend testing & release safety
Prevents regressions with the right mix of unit, component, visual and end-to-end tests, and ships behind flags or staged rollouts so problems are caught before all users see them.
- Weak
- Tests are snapshot tests or none; end-to-end tests are described as flaky and ignored; releases go to everyone at once and problems are found by users.
- Adequate
- Writes component tests for behaviour, has some end-to-end coverage for key flows and uses feature flags, but cannot explain how they keep e2e tests stable or what they chose not to test.
- Strong
- Explains a testing pyramid tailored to their app with examples of what each layer caught, how they made e2e tests reliable (test ids, network stubbing), and a release caught by monitoring or a canary before wide impact.
Collaboration with design & product
Turns designs and product intent into working UI by questioning gaps early, proposing feasible alternatives, and negotiating detail rather than silently deviating.
- Weak
- Implements mockups literally and blames design when edge states (empty, loading, error, long text) are missing; disagreements end with 'I just did what the designer said'.
- Adequate
- Reviews designs before building and raises missing states, and has proposed a cheaper alternative once, but negotiation is ad hoc and often happens after the work is done.
- Strong
- Describes a specific case where they spotted a feasibility or usability problem early, prototyped an alternative, and got design and product to agree with evidence (user data, effort estimate, accessibility impact).
Ownership of the shipped experience
Cares about what users actually experience after release: watches errors and analytics, fixes what is broken, and pushes for polish nobody asked for.
- Weak
- Considers the work done at merge; does not look at error tracking or usage data; cannot name a UX problem they found and fixed on their own initiative.
- Adequate
- Checks error monitoring after release and has fixed issues found there, but improvements are reactive and not tied to user metrics.
- Strong
- Gives examples of finding a problem in analytics or session replays (drop-off, rage clicks, JS errors on a specific browser), fixing it, and the measured change in conversion, error rate or support tickets.
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 Web 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 whole user flows or an area of the app including its performance and accessibility; accountable for 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: deciding where state lives: local, URL, global store, or server cache, improving Largest Contentful Paint and Interaction to Next Paint on a slow page and reducing bundle size: code splitting, tree shaking, and dependency audits, 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 features within an existing app (forms, pages, components) end to end including tests; expected to handle loading, empty and error states without being told. | Owns whole user flows or an area of the app including its performance and accessibility; accountable for quality in production. | Owns the frontend architecture for a product or platform (build, component library, testing strategy, performance budgets) and its technical direction. |
| Tolerance for ambiguity | Fills small gaps in designs sensibly and asks targeted questions on real ambiguities. | Takes a rough product idea and a partial design and produces a working, tested feature, resolving gaps with design and product directly. | Defines the frontend approach for new product areas from business goals; makes framework and tooling decisions with incomplete information and owns the consequences. |
| People leadership | None formally. | Mentors juniors, reviews most PRs in their area, may lead a small feature with others. | Technical lead for frontend engineers, drives design reviews and standards, mentors across teams. |
| Who they deal with | Own team, designer, QA. | Product manager, designers, backend engineers, QA, occasionally support with user issues. | Product and design leadership, backend and platform teams, security, and other teams consuming shared components. |
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 Web Developer would have said them.
- Describes building or fixing a complex widget (combobox, data grid, dialog) with a correct focus and keyboard model, tested with NVDA/VoiceOver, and how they got accessibility into the team's definition of done.
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