Web Developer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Tell me about a feature you built that had a tight deadline.

   What they're really asking: Can you ship something real under pressure without leaving a mess behind?

   Answer outline (STAR)

   • SituationA client-facing form needed to launch in three days for a product announcement.
   • TaskDeliver something working and stable, not just something that compiled.
   • ActionScoped the minimum viable version, reused an existing validation library, and tested on real devices rather than just desktop Chrome.
   • ResultThe form launched on time with no critical bugs, and you documented the shortcuts taken for cleanup later.

   Full sample answer (fictional example)

   Marketing needed a signup form live in three days ahead of a product launch announcement. I scoped it down to the fields we actually needed, reused a validation library the team already had instead of writing custom logic, and tested on real phones rather than just resizing a desktop browser. I flagged two shortcuts I'd taken, like skipping client-side formatting for phone numbers, in a comment and a follow-up ticket. The form launched on time with no critical bugs reported, and we cleaned up the flagged items the following week without rushing.

2. 2.Describe a time you had to fix a bug you didn't fully understand at first.

   What they're really asking: Can you debug systematically instead of guessing randomly?

   Answer outline (STAR)

   • SituationA production page that crashed intermittently only for some users.
   • TaskFind the actual cause, not just a workaround.
   • ActionReproduced it with specific browser and screen-size combinations, added logging, and traced it to a race condition in an async data fetch.
   • ResultFixed the root cause, and added a test that would catch the same timing issue again.

   Full sample answer (fictional example)

   A production page crashed intermittently, but only for some users, which made it hard to reproduce. I started by checking the error logs for patterns and noticed it clustered around a specific browser and screen width combination. I added temporary logging around the suspect component and found a race condition: an async data fetch sometimes resolved after the component had already unmounted, and the state update then threw. I fixed it by canceling the fetch on unmount and added a test that simulated the same timing to catch a regression. The crash rate dropped to zero in the following week's monitoring.

3. 3.Tell me about a time you disagreed with a designer or product manager about an implementation detail.

   What they're really asking: Can you push back with technical reasoning while staying collaborative?

   Answer outline (STAR)

   • SituationA design called for an animation that would hurt performance on low-end devices.
   • TaskFind something that satisfied the design intent without the performance cost.
   • ActionExplained the trade-off with real numbers, then prototyped a lighter version of the animation to show it still looked good.
   • ResultThe designer approved the lighter version, and the page kept its load-time target.

   Full sample answer (fictional example)

   A design called for a full-screen parallax animation on page load, but I knew from past profiling that similar animations tanked performance on lower-end Android devices, which made up a meaningful share of our traffic. Instead of just saying no, I pulled load-time numbers from a similar past feature and built a quick prototype of a lighter version using CSS transforms instead of JavaScript-driven scroll listeners. It looked nearly identical but ran smoothly on the test devices I checked. The designer approved the lighter version, and we kept our page load target without giving up the visual effect they wanted.

4. 4.Tell me about a time you inherited someone else's messy code.

   What they're really asking: Can you work productively in an imperfect codebase instead of just complaining about it?

   Answer outline (STAR)

   • SituationA legacy module with no tests and inconsistent naming that you needed to extend.
   • TaskAdd the feature safely without a full rewrite.
   • ActionWrote characterization tests around the existing behavior first, then made the smallest change that satisfied the new requirement.
   • ResultThe feature shipped without regressions, and the tests you added caught an unrelated bug a month later.

   Full sample answer (fictional example)

   I took over a legacy checkout module with inconsistent naming, no tests and logic spread across several files with unclear responsibilities. Rather than rewrite it, which felt risky given it handled real payments, I wrote characterization tests that captured its existing behavior for the main flows. Then I made the smallest change that satisfied the new requirement, a discount code field, without touching anything else. The feature shipped without regressions, and about a month later, one of the tests I'd added caught an unrelated bug introduced by a different change before it reached production.

5. 5.Tell me about a time you had to learn a new framework or library quickly for a project.

   What they're really asking: How fast can you become productive with unfamiliar tools?

   Answer outline (STAR)

   • SituationA project switch from a framework you knew well to one you'd never used.
   • TaskGet a working feature shipped within the first couple of weeks.
   • ActionRebuilt a small existing component in the new framework to learn its patterns, read the official docs closely, and asked a teammate to review your first real pull request.
   • ResultYou shipped the feature on schedule, and became the person others asked about that framework within two months.

6. 6.Tell me about a time you had to optimize a slow page.

   What they're really asking: Do you diagnose performance with data instead of guessing?

   Answer outline (STAR)

   • SituationA product page with a load time users complained about.
   • TaskBring the load time down without breaking functionality.
   • ActionProfiled with browser dev tools, found an oversized unoptimized image and a render-blocking script, and fixed both.
   • ResultLoad time dropped substantially, and you added an image size check to the build pipeline to prevent regressions.

7. 7.Tell me about a time you had to give or receive difficult code review feedback.

   What they're really asking: Can you handle technical disagreement professionally?

   Answer outline (STAR)

   • SituationA reviewer flagged a pattern you'd used throughout a large pull request.
   • TaskResolve it without the review turning into a standoff.
   • ActionAsked for their reasoning, found their concern was valid for part of the code, and revised that part while keeping the rest.
   • ResultThe pull request merged with a better structure, and the exchange stayed collegial.

8. 8.Tell me about a time you worked closely with a backend or API team as a frontend developer, or vice versa.

   What they're really asking: Can you collaborate across the stack boundary effectively?

   Answer outline (STAR)

   • SituationAn API response shape that didn't match what the frontend needed.
   • TaskAlign on a contract both sides could build against.
   • ActionProposed a shape with examples, confirmed edge cases like empty states, and agreed on versioning before either side wrote code.
   • ResultBoth sides built in parallel with no late integration surprises.

9. 9.Tell me about a time you had to refactor code without breaking existing functionality.

   What they're really asking: Can you improve a codebase safely, not just rewrite it?

   Answer outline (STAR)

   • SituationA tangled component that had become hard to extend safely.
   • TaskMake it maintainable without a risky big-bang rewrite.
   • ActionBroke the refactor into small, independently testable steps, verified behavior after each one, and kept pull requests reviewable.
   • ResultThe component became easier to extend, and no regressions were reported.

10. 10.Tell me about a side project or something you built outside of work.

    What they're really asking: Does your interest in the craft extend beyond what's assigned?

    Answer outline (STAR)

    • SituationAn idea you wanted to build just to learn a new tool or solve a personal problem.
    • TaskShip something working, even if small.
    • ActionScoped it down to a manageable version, built it in evenings and weekends, and deployed it publicly.
    • ResultIt's still running, and you learned a technology you later used at work.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.What's the difference between `==` and `===` in JavaScript, and why does it matter?

   What they're really asking: A fundamentals check that reveals how carefully you think about types.

   Answer outline

   • `==` compares after type coercion, so `'5' == 5` is true; `===` compares value and type without coercion.
   • Coercion rules in JavaScript are full of surprising edge cases, like `[] == false`.

   Full sample answer (fictional example)

   `==` compares two values after converting them to a common type if they differ, so `'5' == 5` evaluates to true because the string gets converted to a number. `===` compares both the value and the type directly, so the same comparison would be false. The coercion rules behind `==` have some genuinely surprising edge cases, like empty array loosely equaling false, which can introduce bugs that are hard to spot in review. I default to `===` everywhere unless I have a specific, deliberate reason to allow coercion, and even then I'll usually write the conversion explicitly instead.

2. 12.Explain the difference between `let`, `const` and `var`.

   What they're really asking: Scoping and hoisting basics that affect real bugs.

   Answer outline

   • `var` is function-scoped and hoisted with an undefined value; `let` and `const` are block-scoped.
   • `const` prevents reassignment of the binding, not mutation of an object it points to.

   Full sample answer (fictional example)

   `var` is function-scoped and gets hoisted to the top of its function with an initial value of undefined, which means you can reference it before its declaration line without an error, just an unexpected value. `let` and `const` are block-scoped instead, so they only exist within the nearest enclosing braces, and accessing them before their declaration throws a reference error, which catches bugs earlier. `const` specifically prevents reassigning the variable itself, but it doesn't make an object or array it points to immutable; you can still push to a const array. A classic bug `var` causes is a closure inside a loop capturing the same variable for every iteration, which `let` fixes by giving each iteration its own binding. In my own code I default to const, switch to let only when a value truly changes, and haven't written var in years.

3. 13.How does the CSS box model work, and what's the difference between `box-sizing: content-box` and `border-box`?

   What they're really asking: Layout fundamentals that still trip people up.

   Answer outline

   • The box model is content, padding, border, then margin, added outward from the content.
   • `content-box` (the default) sizes width/height to content only; `border-box` includes padding and border in that size.

   Full sample answer (fictional example)

   The box model describes an element as nested boxes: content in the center, then padding, then border, then margin, each added outward. With the default `content-box`, the width and height you set apply only to the content area, so padding and border add extra size on top of that, which can make layout math confusing. With `border-box`, the width and height include padding and border, so a 200-pixel-wide box stays 200 pixels wide regardless of how much padding you add. I set `border-box` globally in a reset stylesheet on most projects because it makes sizing predictable, and I only reach for `content-box` behavior in rare specific cases.

4. 14.What happens between typing a URL and seeing a rendered page?

   What they're really asking: Do you understand the pipeline you're optimizing when you talk about performance?

   Answer outline

   • DNS lookup, TCP/TLS connection, the server returns HTML, then the browser parses it into the DOM.
   • The browser requests CSS and JS, builds the render tree, computes layout, then paints.

5. 15.How would you design a REST API endpoint for creating and listing comments on a blog post?

   What they're really asking: Can you make reasonable, conventional API decisions under light ambiguity?

   Answer outline

   • `POST /posts/:id/comments` to create, `GET /posts/:id/comments` to list, using plural nouns and nesting.
   • Return 201 with the created resource on success, and proper 4xx codes with a clear error body on failure.

6. 16.What's the difference between synchronous and asynchronous code in JavaScript, and how do Promises help?

   What they're really asking: Do you actually understand the event loop, not just the Promise syntax?

   Answer outline

   • JavaScript runs on a single thread; async operations don't block it and complete later via callbacks.
   • A Promise represents a value that may not exist yet, with states pending, fulfilled or rejected.

7. 17.How do you approach making a page accessible to keyboard and screen reader users?

   What they're really asking: Accessibility judgment, not just a buzzword answer.

   Answer outline

   • Use semantic HTML elements first, since they carry built-in keyboard and screen reader behavior.
   • Ensure every interactive element is reachable by keyboard with a visible focus state.

8. 18.What's the difference between a local state and global state in a frontend application, and when would you reach for each?

   What they're really asking: Do you have judgment about state management, not just familiarity with a library?

   Answer outline

   • Local state suits data only one component and its children need.
   • Global state (context, a store) suits data shared across unrelated parts of the app.

9. 19.How would you prevent a SQL injection or XSS vulnerability in a web application?

   What they're really asking: Basic security hygiene every web developer should know.

   Answer outline

   • For SQL injection, use parameterized queries or an ORM, never string-concatenated SQL.
   • For XSS, escape or sanitize any user-generated content before rendering it as HTML.

10. 20.What's the difference between CSS Grid and Flexbox, and when would you use each?

    What they're really asking: Layout judgment beyond just knowing the syntax.

    Answer outline

    • Flexbox suits one-dimensional layouts, like a row of nav items or a toolbar.
    • Grid suits two-dimensional layouts, like a page structure with rows and columns.

11. 21.How do you handle responsive design across different screen sizes?

    What they're really asking: Can you build for real devices, not just a resized desktop browser window?

    Answer outline

    • Use relative units and a mobile-first approach with min-width media queries.
    • Test on actual breakpoints that matter for the product's real audience, not arbitrary round numbers.

12. 22.What's your approach to caching in a web application, at the browser and API level?

    What they're really asking: Can you reason about caching trade-offs rather than treating it as magic?

    Answer outline

    • Browser caching uses headers like `Cache-Control` and `ETag` to avoid refetching unchanged assets.
    • API caching might use an in-memory store or CDN layer for expensive or frequently requested data.

Take-home or live exercise: tips

Web developer interviews commonly include a live coding exercise, a small take-home project, or a pairing session fixing or extending an existing codebase.

• Narrate your thinking as you code; interviewers are often weighing your reasoning as much as the final result.
• Clarify requirements and edge cases before writing code, rather than assuming and restarting halfway through.
• In a take-home, write a short README explaining decisions and trade-offs you made under time constraints.

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.You push a change and the production site breaks for some users but not others. What do you do?

   What they're really asking: Can you triage a live incident calmly?

   Answer outline

   • Check recent deploys first, and roll back if the cause isn't immediately obvious.
   • Narrow down what's different about affected users: browser, region, cache state, feature flag.

   Full sample answer (fictional example)

   First I'd check whether anything else deployed around the same time, since recent changes are the most likely cause, and I'd roll back quickly if the cause isn't obvious within a few minutes. While investigating, I'd try to narrow down what's different about affected users, like their browser, region, cached assets or a feature flag they're in. I'd post a short status update to the team rather than going quiet, even if it's just 'investigating, will update in 15 minutes.' Once I find the cause, I'd fix it, verify with the same affected conditions, and write a short note on what happened for the next person who hits something similar.

2. 24.You're asked to add a feature to code with no tests and a deadline in two days. What's your approach?

   What they're really asking: Will you cut corners responsibly or recklessly?

   Answer outline

   • Decide where tests would actually catch risk, and add a few targeted ones rather than none or a full suite.
   • Keep the change small and isolated so it's easy to review and revert.

   Full sample answer (fictional example)

   I'd look at where the real risk is in the change, like a calculation or a data transformation, and add a few targeted tests around just that rather than trying to build full coverage for the whole file in two days. I'd keep the actual feature change small and isolated so it's easy to review quickly and easy to revert if something goes wrong. I'd also be upfront with my team that the surrounding code isn't covered, so nobody assumes it's safer than it is.

3. 25.A teammate's pull request works but has a design you disagree with. How do you handle the review?

   What they're really asking: Can you give useful feedback without being obstructive or precious?

   Answer outline

   • Separate 'this is wrong' from 'I would have done this differently' in your comments.
   • Ask questions about their reasoning before asserting your preferred approach.

   Full sample answer (fictional example)

   I try to separate what's actually wrong from what I would have just done differently, and I only block on the former. For a style or structure disagreement, I'll ask about their reasoning first, since there's often context I'm missing, like a constraint from an earlier decision. If after that conversation it's clearly just a preference difference and the code works and is maintainable, I'll approve with a comment noting my alternative as a suggestion, not a requirement. I've found that blocking reviews over preference rather than correctness slows teams down and erodes trust more than it improves code quality.

4. 26.You realize partway through a sprint that a feature will take much longer than estimated. What do you do?

   What they're really asking: Will you raise it early, or hope to catch up quietly?

   Answer outline

   • Flag it as soon as you're confident, with your reasoning, not at the deadline.
   • Propose options: cut scope, extend the deadline, or get help.

5. 27.A third-party API your app depends on goes down. How do you handle it?

   What they're really asking: Can you design and respond to dependency failures gracefully?

   Answer outline

   • Show a clear, non-broken fallback state in the UI rather than a blank screen or raw error.
   • Log the failure and retry with backoff if appropriate, rather than hammering the failing service.

6. 28.You're told to support Internet Explorer 11 for a new feature you were planning to build with modern JavaScript. What do you do?

   What they're really asking: Can you work within a real constraint instead of just resisting it?

   Answer outline

   • Check what the constraint actually requires, such as specific polyfills or a transpiler config.
   • Weigh the cost of supporting it against the actual user base still using it, and raise that trade-off.

7. 29.A designer hands you a mockup with no specification for loading, empty or error states. What do you do?

   What they're really asking: Will you fill real gaps, or just build the happy path?

   Answer outline

   • Ask the designer directly rather than guessing or skipping those states.
   • Propose a reasonable default based on patterns elsewhere in the product if they're unavailable.

8. 30.You inherit a project where the previous developer left no documentation and is no longer reachable. How do you get up to speed?

   What they're really asking: Can you reverse-engineer a system methodically?

   Answer outline

   • Run the app locally first, and trace a few key user flows through the code.
   • Check commit history and any tickets or pull requests for context on past decisions.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Jumping straight to code without clarifying the problem or edge cases.

   Ask a clarifying question or two and state your assumptions before writing anything.

2. Treating a framework's conventions as the only way to solve a problem.

   Explain the fundamentals underneath the framework and why the convention exists.

3. Dismissing accessibility or performance as someone else's job.

   Describe specific habits you use for both, even briefly, in your normal workflow.

4. Getting defensive when a reviewer or interviewer questions your code.

   Treat questions as a chance to explain your reasoning, not as an attack to resist.

How to prepare for a web developer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: Fundamentals review

   Go through JavaScript scope, closures, `this` and async/await with a few quick written exercises.

2. 2

   Day 2: Live coding practice

   Do two or three timed coding problems out loud, narrating your reasoning as you go.

3. 3

   Day 3: CSS and layout drill

   Rebuild a small multi-section page layout using both Flexbox and Grid to compare the fit for each section.

4. 4

   Day 4: System and API design

   Sketch a REST API for a small feature, covering endpoints, status codes, pagination and error shapes.

5. 5

   Day 5: Debugging practice

   Take a small buggy code sample and practice narrating your debugging process from symptom to root cause.

6. 6

   Day 6: Portfolio deep dive

   Prepare a five-minute walkthrough of one project: the architecture, a hard bug, and what you'd change now.

7. 7

   Day 7: Interview walk-through

   Run a mock covering one live coding problem, one system question and two behavioral questions. Then rest.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. What does the stack look like end to end, and how much of it would I touch day to day?
2. How is code reviewed, and how large do pull requests typically run?
3. How much of the work is new features versus maintaining existing code?
4. What does the testing and deployment pipeline look like?
5. What's a recent technical decision the team debated, and how was it resolved?

Preparation tips

• Practice explaining your reasoning out loud while coding; interviewers weigh process as much as the final answer.
• Review JavaScript fundamentals (scope, closures, `this`, async) even if you use a framework daily.
• Bring a project you can discuss in depth: the architecture, a hard bug, and a decision you'd make differently now.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.