A web developer interview usually has three layers. First, a screening conversation about your stack, the sites and applications you've built, and how you choose languages, frameworks, and tools for a given job. Second, a technical round: reading and critiquing code, discussing HTML/CSS/JavaScript behavior, writing or explaining server-side logic, sketching a database schema for a web application, and talking through an API or query you'd optimize. Third, behavioral and situational questions about working with designers, clients, and non-technical stakeholders, handling a broken production site, and prioritizing updates against deadlines.
Prepare by picking two or three projects you can describe end to end: the user need, the technical requirements you derived, the architecture, the testing you did across browsers and devices, and what you'd change now. Be ready to talk specifics — how you validate markup and accessibility, how you handle cross-browser inconsistencies, how you back up files and databases before a deploy, how you profile a slow page. Have a portfolio or repository you can screen-share and narrate. Interviewers also probe how you stay current: what you've read or learned recently, and how you evaluate whether a new tool is worth adopting. Answer with concrete decisions and tradeoffs rather than tool name-dropping.
1. Walk me through a website or web application you built end to end — from the user need to launch.
What they're testing
Whether you can own a project across front end, back end, data, and deployment, and explain it coherently.
A strong answer
Start with who the users were and what problem the site solved. Cover how you turned that into technical requirements, the stack you chose and why, the data model, how you tested before launch, and how it performed afterward. End with a concrete thing you'd do differently.
Common failure mode: Listing technologies used instead of decisions made, or claiming credit for a team effort without saying which parts you personally wrote.
Likely follow-up: Which part of that build gave you the most trouble?
2. How do you decide which programming language, framework, or design tool to use for a new project?
What they're testing
Operations analysis and judgment rather than defaulting to whatever you know best.
A strong answer
Describe criteria: the project's requirements, what the existing codebase and team already support, hosting constraints, maintenance burden, and long-term support of the library. Give one example where you picked something unfamiliar and one where you deliberately chose the boring, established option.
Common failure mode: Advocating a single favorite stack for every situation, or choosing based on what's currently popular.
Likely follow-up: When have you argued against adopting a new framework?
3. Describe how you test a site across browsers, devices, and operating systems.
What they're testing
Concrete compatibility testing practice, not just awareness that it matters.
A strong answer
Explain your matrix — which browsers and viewport sizes you target and how you decide, based on the site's actual traffic. Cover the mix of automated checks, device or emulator testing, and manual passes. Give an example of a specific incompatibility you found and how you fixed it without breaking other targets.
Common failure mode: Saying "I test in Chrome and it usually works everywhere" or naming a testing tool with no description of the process.
Likely follow-up: How do you handle a CSS feature one target browser doesn't support?
Reading answers isn't rehearsing them.
Run these exact questions with a voice AI interviewer and get scored on your real answers — the first five minutes are free.
4. A page on the production site is loading slowly. How do you diagnose and fix it?
What they're testing
Systematic performance debugging across the client, network, server, and database.
A strong answer
Start by measuring — network waterfall, time to first byte, rendering profile — before changing anything. Separate front-end causes (unoptimized images, blocking scripts, excess payload) from server-side ones (slow queries, missing caching, N+1 access patterns). Describe fixing the biggest contributor first and re-measuring to confirm.
Common failure mode: Jumping to a list of generic optimizations (minify, use a CDN) without any diagnosis step or measurement.
Likely follow-up: How would you find a slow database query behind a page?
5. Design the database schema for a web application that lets users create accounts and post content with comments.
What they're testing
Data modeling ability for the application layer web developers actually own.
A strong answer
Lay out the tables, keys, and relationships out loud, note where you'd index, and explain how you'd handle deletion, timestamps, and moderation states. Mention normalization choices and where you'd deliberately denormalize for read performance. Ask clarifying questions about scale and access patterns first.
Common failure mode: Producing a schema with no keys or indexes, or ignoring how the application will actually query the data.
Likely follow-up: How would you paginate the comment list efficiently?
6. Tell me about a time you had to fix a bug you didn't create, in code you hadn't seen before.
What they're testing
Reading comprehension of unfamiliar code and disciplined debugging.
A strong answer
Describe how you reproduced the bug first, then narrowed the surface — logs, version history, bisecting, adding instrumentation. Explain what the root cause was and why the original code went wrong. Mention what you did to prevent a recurrence, like a test or a comment explaining the constraint.
Common failure mode: Blaming the previous developer, or describing a fix that treated the symptom without identifying the cause.
Likely follow-up: How did you verify your fix didn't break anything adjacent?
7. How do you handle backups of site files and databases, and what's your rollback plan for a bad deploy?
What they're testing
Operational maturity — whether you protect the site, not just build it.
A strong answer
Describe backing up files and database state on a schedule and before any significant release, storing copies where a server failure won't take them out, and — critically — periodically testing a restore. Explain your rollback: version-controlled deploys, a previous release you can switch back to, and how you handle migrations that aren't reversible.
Common failure mode: Assuming the host handles backups, or having a backup plan that's never been tested with an actual restore.
Likely follow-up: Have you ever had to restore from a backup? What happened?
8. A stakeholder describes what they want the site to do in non-technical terms. How do you turn that into technical requirements?
What they're testing
Active listening and requirements analysis with non-technical users.
A strong answer
Explain that you dig for the underlying goal and the users behind the request rather than implementing the literal ask. Describe asking about volumes, edge cases, who maintains content afterward, and what happens when things go wrong. Mention playing the requirements back — as a written summary, wireframe, or quick prototype — and getting confirmation before building.
Common failure mode: Taking the request at face value and building exactly what was said, then discovering the mismatch at review.
Likely follow-up: Give an example where the stated request wasn't the real need.
9. How do you evaluate whether code is valid, well structured, and meets industry standards?
What they're testing
Code quality standards and whether you have an actual review practice.
A strong answer
Cover both automated and human layers: linters, formatters, markup validation, accessibility checks, and automated tests in the pipeline, plus code review for structure, naming, and duplication. Explain the structural things you look for — separation of concerns, sensible module boundaries, no logic buried in templates — and how you give review feedback.
Common failure mode: Equating code quality with formatting, or describing standards you follow personally with no way to enforce them across a team.
Likely follow-up: What do you look for first when reviewing someone else's pull request?
10. Walk me through building an interactive feature on the front end — how you structure the JavaScript and the state behind it.
What they're testing
Front-end engineering depth beyond wiring up a library.
A strong answer
Pick a real feature and describe the component or module breakdown, where state lives, how you handle asynchronous requests and their loading and error states, and how you keep the DOM and the data in sync. Mention accessibility and keyboard behavior as part of the feature, not an afterthought.
Common failure mode: Describing only the visual result, or hand-waving state management and error handling.
Likely follow-up: How do you handle a failed network request mid-interaction?
11. The site is down. Walk me through your first thirty minutes.
What they're testing
Incident response, prioritization under pressure, and communication.
A strong answer
Confirm the outage and its scope first, then check the most recent change, then work down the stack — application errors, server, database, DNS, certificate, hosting provider status. Say explicitly that you notify stakeholders early with a status, restore service before doing full root-cause work, and write up what happened afterward.
Common failure mode: Diving into code immediately with no scoping step, and never mentioning telling anyone what's going on.
Likely follow-up: What if the last deploy was three weeks ago?
12. How do you keep current with web technologies and decide what's worth learning?
What they're testing
Active learning and whether the interest is real and filtered.
A strong answer
Name your actual sources — specification and release notes, technical writing, community groups, conferences or workshops — and describe what you learned most recently and where you applied it. Explain your filter: whether it solves a problem you actually have, how mature it is, and what maintaining it would cost.
Common failure mode: Vague claims about reading blogs, with no specific recent example, or chasing every new framework indiscriminately.
Likely follow-up: What's something you learned recently that changed how you work?
13. Tell me about a disagreement with a designer or another developer about implementation.
What they're testing
Collaboration and whether you can argue technically without making it personal.
A strong answer
Describe the substance of the disagreement — a design that was expensive to build responsively, an architecture choice, a deadline tradeoff. Explain how you made your case with evidence, what the other side's reasoning was, and how it resolved. Include a case where you changed your mind.
Common failure mode: Framing it as a story where you were right and eventually proved it, with no genuine consideration of the other view.
Likely follow-up: What did you concede?
14. How do you handle user inquiries and support requests that come in about the site?
What they're testing
Customer service orientation and whether you turn support load into product fixes.
A strong answer
Describe triaging by impact, reproducing the issue before responding, and replying in plain language without jargon. Explain setting up automated acknowledgments or self-service documentation for common questions, and — importantly — tracking recurring inquiries as signals that something in the interface or flow needs to be fixed.
Common failure mode: Treating support as an interruption below the job, or answering with an automated system as the whole solution.
Likely follow-up: How do you tell a user their request isn't a bug?
15. How do you approach securing a web application you're building?
What they're testing
Baseline security awareness for the layers a web developer controls.
A strong answer
Cover input validation and output escaping, parameterized queries, authentication and session handling, permission checks on every server-side endpoint rather than hiding UI, HTTPS and secure cookies, and keeping dependencies patched. Mention that client-side validation is for user experience, not enforcement.
Common failure mode: Naming attack types without describing defenses, or relying on the framework to be secure by default with no verification.
Likely follow-up: How do you store user credentials?
16. Describe how you plan and execute a scheduled site update or content migration without disrupting users.
What they're testing
Planning and organizing work — the release side of the job.
A strong answer
Explain scoping the change, testing on a staging environment that mirrors production, taking backups first, scheduling for a low-traffic window, and sequencing so schema and code changes stay compatible. Add how you verify after release and what your abort criteria are.
Common failure mode: Describing an unstaged deploy straight to production, or having no verification step after the update.
Likely follow-up: How do you handle a migration that takes hours on a large table?
17. You have more requested changes than time before a launch. How do you prioritize?
What they're testing
Judgment about tradeoffs and ability to negotiate scope with stakeholders.
A strong answer
Separate what blocks launch — broken flows, security, data loss, accessibility barriers — from what can ship after. Explain how you present the options and their costs to stakeholders rather than deciding silently, and how you make sure the deferred items are recorded instead of forgotten.
Common failure mode: Saying you'd work longer hours and do it all, or silently cutting scope without telling anyone.
Likely follow-up: How do you handle a stakeholder who says everything is critical?
18. Tell me about a technical decision you made that turned out to be wrong.
What they're testing
Self-awareness and how you handle the cost of your own mistakes.
A strong answer
Name a real decision — a dependency that became unmaintained, a data model that didn't survive a new requirement, an over-engineered abstraction. Explain the reasoning at the time, how you noticed it was wrong, what unwinding it cost, and what you now check for before similar choices.
Common failure mode: Choosing a trivial mistake, or a disguised strength like "I built it too well."
Likely follow-up: How long did it take you to admit it?
19. How do you handle the domain, DNS, and hosting side of a site you're responsible for?
What they're testing
Whether you cover the infrastructure and administrative duties, not just the code.
A strong answer
Describe tracking domain registration and certificate expiry with reminders or automated renewal, documenting where DNS is managed and who has access, and understanding record types well enough to diagnose propagation issues. Mention that this belongs in written documentation so it doesn't live only in one person's head.
Common failure mode: Treating it as someone else's job, or having no answer for what happens when a registration or certificate lapses.
Likely follow-up: A certificate expired overnight — what do you do?
20. How do you make sure a site works for users with disabilities?
What they're testing
Accessibility knowledge as part of the build, tied to design and standards.
A strong answer
Talk about semantic markup, keyboard operability, focus management, color contrast, labeled form controls, and meaningful alternative text. Describe combining automated checks with manual keyboard and screen-reader passes, since automation catches only part of the problem. Give a specific fix you've shipped.
Common failure mode: Naming an automated scanner as the entire strategy, or treating accessibility as a compliance task done at the end.
Likely follow-up: How do you make a custom interactive component accessible?
21. Why this role, and what kind of web work do you want to be doing?
What they're testing
Motivation and fit with the team's actual mix of front-end, back-end, and maintenance work.
A strong answer
Be specific about the work you want — heavier back-end and data, interface and interaction work, or full ownership of small sites — and connect it to what this role actually involves. Reference something concrete about the team's product or stack. Be honest about what you'd need to learn.
Common failure mode: Generic enthusiasm for coding that would apply to any employer, or ignoring the maintenance and support portion of the job.
Likely follow-up: Which part of the job description least appeals to you?