Walk me through the tech stack you know best and why you chose it.

My primary stack is React on the front end with TypeScript, paired with Node.js and Express on the back end, and PostgreSQL for the database. I gravitated toward React because the component model maps cleanly to how I think about UI: isolated pieces with defined inputs and outputs. TypeScript caught several classes of bugs before they reached production, so I stopped seeing the type annotations as overhead and started seeing them as documentation that the compiler enforces. I added Node on the back end to keep the mental context switch small between layers. PostgreSQL suits the relational data I work with most often, and its JSON support handles the occasional semi-structured case. I am not dogmatic about this stack: I pick tools that fit the problem, and I have shipped projects in Vue and Python/Django when the team or the requirements called for it.

How do you stay current with changes in web development?

I follow a small number of high-signal sources rather than trying to read everything. The MDN Web Docs changelog and the React and TypeScript release notes go directly into my RSS reader. I subscribe to a couple of newsletters (bytes.dev and JavaScript Weekly) and skim them weekly. When something catches my attention, I open a small side project or a CodeSandbox to try it in isolation before using it in production code. I also review pull requests from colleagues who have different specialisms from mine: code review is one of the fastest ways to absorb patterns you have not encountered before. I do not adopt every new framework or library on release. I wait to see if they solve a real problem I have, and I read the issues tracker before committing to anything new in a production codebase.

How do you handle a situation where requirements are unclear or keep changing?

I treat unclear requirements as a discovery problem, not a blocker. My first step is to write down what I know, what I am assuming, and what I genuinely do not know, then take that list to whoever owns the requirement. That conversation usually resolves 80% of the ambiguity in 15 minutes. For genuinely fluid requirements, I break work into the smallest pieces that could ship independently and confirm each piece before building the next. I also get explicit agreement on what done means before I start: a clear acceptance criterion is far more useful than a long description. If requirements change mid-build, I flag the cost of the change in terms of time and any rework needed, not as a complaint but as information the team needs to make a good decision. I have found that surfacing the cost early prevents a lot of late-stage surprises.

Tell me about a time you had to work closely with a designer and the collaboration was difficult.

On one project the designer and I had a recurring conflict over component spacing. They would hand off Figma files with pixel-perfect margins that did not map to our 8-point grid, and I kept having to choose between matching the design exactly or keeping the system consistent. After the third round of this I asked for a 30-minute meeting to show them the design token system we were using and explain why arbitrary values created maintenance problems. I walked through a specific example: two buttons that looked the same to a user but had different margin values in code, which meant two tickets to update instead of one. That conversation changed how we worked. We agreed I would flag grid deviations during design review before any file reached development. The last three months of the project had almost no rework from design inconsistencies.

Describe a time you had to debug a problem under pressure with a deadline looming.

We had a production deploy on a Friday afternoon that broke checkout for users on Safari. Orders were failing silently and we only found out because a customer called. I reproduced it locally within 10 minutes using Safari's developer tools. The root cause was a CSS grid property that Chrome handled fine but Safari did not: a subgrid feature I had used without checking the Safari compatibility table first. I fixed it with a fallback flexbox layout, wrote a regression test, and deployed within 45 minutes. The harder part was the communication: I sent a clear update to the product owner every 15 minutes with status, estimated resolution time, and any change to that estimate. That kept the wider team calm and stopped me from being interrupted while I worked. After the incident I added a browser compatibility check to our code review checklist.

Give an example of a time you pushed back on taking on technical debt.

Midway through a project the team proposed copying a large block of legacy spaghetti code into the new codebase to hit a sprint deadline. I argued against it not on principle but with specifics: that block had three open bugs in the backlog, no tests, and would touch six components we were planning to refactor the following quarter. I estimated the rework cost at around two sprint days, which was more than the time we would save by copying it now. I proposed an alternative: a thinner implementation that was clean and testable, which I estimated at a day and a half. The team lead agreed. We shipped on time with the clean version, and we did not pay the rework cost later. I have also been in situations where I agreed to take on debt deliberately: the key is making the trade-off explicit and logging it in the backlog with a remediation ticket so it does not disappear.

How do you approach performance optimisation for a slow web page?

I start by measuring, not guessing. I run the page through Lighthouse and the Chrome Performance tab to get a baseline. The first thing I check is the network waterfall: oversized images and uncompressed assets account for the majority of load-time problems in my experience. From there I look at render-blocking scripts, then at JavaScript bundle size using a tool like webpack-bundle-analyzer or the Next.js bundle analysis plugin. On the rendering side I check for layout shifts (CLS) and long tasks (TTI). If the page is React-based I look at unnecessary re-renders with the React DevTools profiler. Common fixes I reach for: lazy-loading images and below-the-fold components, code-splitting at the route level, moving large third-party scripts to load async or defer, and caching API responses. I always measure again after each change to confirm the improvement is real and has not introduced a regression elsewhere.

Explain how you would design a REST API endpoint for a feature you have built recently.

For a recent user notification feature I designed a GET /users/:id/notifications endpoint. I chose REST over GraphQL because the data shape was simple and the team was already familiar with REST conventions. I versioned the API at /v1/ from the start to avoid breaking changes later. The endpoint returns a paginated list using cursor-based pagination rather than offset, because the notifications feed updates frequently and offset pagination produces duplicate or missing items in those cases. I included filtering by read status as a query parameter (?unread=true) and kept the response envelope consistent with our other endpoints: a data array, a meta object with pagination cursors, and a standard error structure. I wrote an OpenAPI spec before implementation so the front end and back end teams could work in parallel. I also added rate limiting on that endpoint because notifications could be polled frequently.

What steps do you take to make a website accessible?

I treat accessibility as a build requirement, not an audit I do at the end. In practice that means: writing semantic HTML first and only reaching for div and span when no appropriate element exists; adding alt text to all meaningful images; ensuring every interactive element is reachable and operable by keyboard; using ARIA attributes only when native semantics are insufficient, because incorrect ARIA is worse than none. I run axe-core in the development environment as a linter so issues surface before code review. I also test with a screen reader periodically: VoiceOver on macOS covers a lot of real-world cases. On the CSS side I check colour contrast ratios against WCAG AA minimums (4.5:1 for normal text) and avoid conveying information through colour alone. For form validation I ensure error messages are programmatically associated with their fields using aria-describedby. I have found that fixing accessibility issues early costs a fraction of fixing them after launch.

Web Developer Interview Questions

Web Developer

Web Developer interviews test your technical foundations alongside your ability to collaborate, make architectural trade-offs, and ship working code in real teams. Interviewers want to see that you understand the full stack, care about user experience, and can talk through your decisions clearly. This guide covers the questions that come up most often and the answers that demonstrate genuine depth.

What Hiring Managers Look for in Web Developer Interviews

What hiring managers really look for in Web Developer candidates:

Concrete debugging stories. Anyone can say they are good at debugging. Candidates who walk through a real incident with the tools they used, the root cause they found, and the process change they made afterwards stand out immediately.
Genuine opinions about trade-offs. The best candidates do not just describe what they built, they explain why they chose one approach over another and what they would do differently next time.
Awareness of the full delivery cycle. Writing code is part of the job, not all of it. Look for candidates who think about testing, deployment, monitoring, and maintenance as naturally as they think about implementation.
Collaboration with non-engineers. Front-end developers especially need to work with designers and product managers. Listen for how a candidate describes those relationships: specificity and mutual respect are good signs.
Browser and accessibility knowledge beyond the basics. Many candidates know the headline features. Fewer know how Safari handles specific CSS properties or how to correctly implement keyboard navigation. Those who do are significantly more production-ready.

Questions to Ask Your Interviewer

→What does the deployment process look like, and how often does the team ship to production?

→How is front-end work reviewed here: is there a dedicated design QA step before code ships?

→What are the biggest technical challenges the team is working through right now?

→How does the team handle browser compatibility and accessibility requirements?

→What does onboarding look like for a new developer, and how long before someone is shipping independently?

Web Developer

Common Web Developer Interview Questions

Behavioral Interview Questions for Web Developer Roles

Technical Questions for Web Developer Candidates

What Hiring Managers Look for in Web Developer Interviews

Questions to Ask Your Interviewer

Practice These Questions Before Your Interview

Related Roles