Web Developer Interview Questions

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.

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.

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.

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.

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.

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.

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.

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.

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.