Web Developer interview questions and how to answer them
Most web developer interviews aren't won on trivia. They're won when you explain how you'd fix a slow, broken page for a real user, out loud, while someone watches you think. Here's what each round checks, the questions that come up again and again, and what separates a hire from a polite rejection.
What happens in each round
- 1
Recruiter screen
What happens
Whether your stack matches the posting (say React, WordPress, or plain HTML, CSS and JavaScript), whether you've shipped real sites, and whether you can describe your work without drowning them in jargon. Have a short story ready about one site you built and who used it.
- 2
Technical screen or take-home
What happens
Can you build a small page or component that works, looks right on a phone, and doesn't fall over with bad data. Reviewers read your commit history and your README as closely as your code. Clean, boring, well-named code beats clever code here.
- 3
Hiring manager
What happens
How you handle vague requests, pushy stakeholders and your own mistakes. They want to hear about a time a deploy went wrong and what you changed afterward, not a speech about loving to code.
- 4
Panel or pairing session
What happens
You'll often debug or extend existing code with a developer or designer beside you. They're watching whether you ask questions, read before you type, open DevTools early, and talk through tradeoffs instead of going silent.
Questions you're likely to get
1.A page on our site loads slowly on mobile. Walk me through how you'd find out why.
Why they ask
This is the job. Slow pages cost real users, and they want to see a method rather than a guess.
How to answer
- Reproduce it first: Chrome DevTools with network throttling and a mid-range phone profile, or a Lighthouse run
- Read the network waterfall for oversized images, render-blocking scripts and slow API calls
- Check Core Web Vitals, especially Largest Contentful Paint and layout shift, and what element is causing each
- Fix the biggest offender first (compress and lazy-load images, defer third-party scripts, cache responses) and measure again
- Mention checking real user data, not just your fast laptop
2.Explain the difference between how a browser handles CSS, JavaScript and the HTML on first load.
Why they ask
It shows whether you understand why pages feel slow or jumpy, not just how to write the code.
How to answer
- The browser parses HTML into the DOM and CSS into the CSSOM, then combines them to paint
- Stylesheets in the head block rendering, and plain script tags block parsing
- Use defer or async on scripts, and inline only the critical CSS when it matters
- Tie it to a real bug you fixed, like a flash of unstyled content or a font swap
3.How do you make a site accessible, and how do you check it?
Why they ask
Accessibility complaints and legal letters land on the web team. They want someone who builds it in, not someone who bolts it on.
How to answer
- Start with semantic HTML: real buttons, labels tied to inputs, proper heading order, alt text that describes purpose
- Keyboard test every flow, and make sure focus is visible and never trapped in a modal
- Run axe or Lighthouse, then do a quick pass with a screen reader like VoiceOver or NVDA
- Check colour contrast against WCAG guidance and use ARIA only when native elements can't do the job
4.A layout looks perfect in Chrome but breaks in Safari on an iPhone. What do you do?
Why they ask
Cross-browser bugs eat hours every week. They want to see you narrow it down calmly.
How to answer
- Reproduce on a real device or through Safari's Web Inspector, not just a resized desktop window
- Isolate the element, strip styles until the bug disappears, and find the property causing it
- Check support tables on Can I Use for things like newer flexbox gap behaviour or viewport height units
- Fix with a fallback or progressive enhancement, and add the case to your test checklist
5.When would you choose a framework like React or Vue, and when is plain HTML and a bit of JavaScript enough?
Why they ask
They've seen marketing sites turned into heavy single-page apps for no reason. They want judgment, not fandom.
How to answer
- Plain HTML, or a static site generator, fits content-heavy pages that barely change on the client
- A framework earns its weight when there's lots of shared state and interaction, like dashboards or checkout flows
- Consider who'll maintain it, SEO needs, and whether server rendering is required
- Give an example where you picked the lighter option and why
6.How do you handle forms and user input safely?
Why they ask
Forms are where spam, broken data and security holes come in. Every web developer touches them.
How to answer
- Validate on the client for a good experience, and always validate again on the server
- Escape output to prevent cross-site scripting, and use parameterised queries to avoid SQL injection
- Protect state-changing requests against CSRF and rate-limit the endpoint
- Show clear, specific error messages next to the field, not a generic banner
7.Walk me through how you'd ship a change to a live site without breaking it.
Why they ask
They need to trust you with production. How you deploy says more than how you code.
How to answer
- Work on a branch in Git, open a pull request, and get a review
- Test on a staging site that mirrors production, including on a phone
- Deploy at a sensible time, watch error logs and analytics right after, and know how to roll back
- Use feature flags or a small rollout for risky changes
8.What do you look at when you review someone else's pull request?
Why they ask
You'll review and be reviewed constantly. They're checking whether you catch real problems and stay kind about it.
How to answer
- Does it do what the ticket asked, and does it work when you pull it down and run it
- Edge cases: empty states, long text, slow networks, a logged-out user
- Readability and naming over personal style preferences
- Frame comments as questions or suggestions, and approve small nits rather than blocking on them
9.Tell me about a bug you caused that reached production. What happened next?
Why they ask
Everyone ships bugs. They want to know whether you own it, fix it fast and stop it happening again.
How to answer
- Pick a real one with real stakes, like a broken checkout button or a missing redirect
- Say how you found out, what you did in the first hour, and who you told
- Explain the root cause plainly
- Name the change you made afterward: a test, a checklist item, a monitoring alert
10.A marketing manager asks for a new landing page by Friday, and the design keeps changing. How do you handle it?
Why they ask
Web developers often sit between marketing, design and engineering. Scope creep is a weekly event.
How to answer
- Agree on what's fixed for Friday and what can come in a follow-up
- Build reusable sections so late changes are cheap
- Put decisions in writing, in the ticket or a Slack thread, so nobody's surprised
- Flag the tradeoff early if a change threatens the date, rather than quietly working late
11.How do you make sure a site gets found in search and shared properly?
Why they ask
On many teams the web developer owns the technical side of SEO, even if nobody says so in the posting.
How to answer
- Clean URLs, one clear title and meta description per page, and a sensible heading structure
- Server-rendered or pre-rendered content so crawlers see real text
- Sitemaps, canonical tags, redirects for moved pages, and Open Graph tags for social previews
- Check it in Google Search Console instead of guessing
12.How do you keep your skills current without chasing every new tool?
Why they ask
The web changes constantly. They want someone who learns on purpose and can tell hype from useful.
How to answer
- Name specific sources you actually read, like MDN, browser release notes or a team's engineering blog
- Describe a recent thing you learned and used on a real project
- Explain how you decide something's worth adopting: does it solve a problem you have today
- Mention side projects or contributions only if they're real
Mistakes that sink good candidates
Pointing to a portfolio where half the links are dead or the sites break on a phone
They will click them.
Going quiet during a live coding or pairing exercise
Talk through what you're checking, even when you're stuck.
Bad-mouthing a past client, designer or team for a project that went sideways
Claiming expertise in every framework on your resume
You'll get asked a hard question about the one you know least.
Need more Web Developer interviews to prep for?
HeroApply applies to Web Developer jobs that match you, every day. 632 jobs are open today.