Hiring a strong web developer means testing more than framework trivia. The questions below cover the fundamentals that outlast any library, the practical skills that ship features, and the habits that keep sites fast and accessible. Pick 10-12 for a single round at {{Company name}}, ask every candidate the same set, and score answers against the guidance notes so interviews stay comparable.

Web fundamentals

• Walk me through what happens between typing a URL and the page rendering. Where can things go wrong?
• Explain the box model, flexbox, and grid. When do you reach for each?
• How does the browser event loop work, and how does it affect the code you write?
• What is the difference between cookies, localStorage, and sessionStorage, and when is each appropriate?
• How do you build a responsive layout without leaning on a CSS framework?
• What is semantic HTML, and why does it matter beyond styling?

What good looks like: strong candidates explain mechanisms, not memorized definitions — they can trace a request through DNS, TLS, and the render pipeline, and they connect each concept to a real decision they made. Vague answers that name-drop tools without explaining why are a warning sign, regardless of years of experience.

JavaScript and frameworks

• Describe a recent project where you chose a framework — or chose not to use one. What drove the decision?
• How do you manage state in a growing frontend application?
• What trade-offs do you weigh between server-side rendering, static generation, and client-side rendering?
• Tell me about a time a dependency upgrade broke your build. How did you resolve it?
• How do you structure components so they stay reusable as a codebase grows?

Performance and accessibility

• How would you diagnose a page that takes six seconds to load?
• Which performance metrics do you watch, and how do you move each one?
• How do you test a site for keyboard-only navigation and screen readers?
• What image and asset strategies do you use to keep pages light?
• Describe an accessibility fix you shipped. How did you find the issue in the first place?

What good looks like: the best answers start with measurement — a waterfall, a Lighthouse run, real-user metrics — before naming fixes, and they treat accessibility as a default practice rather than a retrofit. Candidates who can name a specific metric they improved and by how much are showing real ownership.

APIs and backend integration

• How do you handle errors from a third-party API so users are not left staring at a spinner?
• Compare REST and GraphQL from a consumer point of view. When does each fit?
• How do you keep secrets and tokens out of client-side code?
• How would you add caching to an API-heavy page?
• What does a good API contract between frontend and backend look like to you?

Debugging and quality

• Walk me through the last hard bug you fixed. What made it hard?
• What is your testing strategy for a feature with heavy user interaction?
• How do you use browser devtools beyond logging to the console?
• When a bug only reproduces in production, what do you do?

Collaboration

• How do you handle a design that is beautiful but expensive to build?
• Tell me about a code review that changed your approach.
• How do you explain technical trade-offs to non-technical stakeholders?
• What do you do when requirements are ambiguous and the deadline is fixed?