Web Developers Interview Questions & Answers

Example answer

“At my last company, mobile users abandoned our subscription checkout at 38%, and session replay showed the address form was especially painful. I rebuilt the form in React with field-level validation, address autocomplete behind a debounced API call, and preserved form state when users returned from payment authentication. I added analytics events for validation errors, autocomplete selection, and each checkout step, then partnered with product to A/B test the change. Over four weeks, mobile checkout completion increased from 62% to 70%, while address-related validation errors fell 31%. I also reduced the JavaScript bundle for that route by 46 KB by lazy-loading the autocomplete provider.”

Example answer

“I inherited a customer portal where every React page fetched data through a different wrapper, and authentication failures were handled inconsistently. Before changing components, I traced requests in the browser network panel, reviewed our Node.js middleware, and cataloged the 23 API call patterns. I introduced a shared typed API client with centralized token refresh and normalized error objects, then migrated the billing route first because it generated the most support tickets. I wrote integration tests around expired sessions and used a feature flag so we could fall back during rollout. The migration cut duplicate request code by about 1,100 lines and reduced login-loop tickets from roughly 18 per week to three.”

Example answer

“A designer proposed an always-playing, full-screen video hero for our pricing page, while I was concerned about mobile performance and reduced-motion users. I built a small prototype and measured that the video added 2.4 MB and pushed mobile LCP above 4 seconds on a mid-tier Android profile. I also demonstrated that the original controls were not usable by keyboard. Instead of vetoing it, I proposed a static poster by default, a user-initiated play button, and a reduced-motion version. The designer kept the visual direction, and the released page held a 2.3-second mobile LCP while increasing demo requests 12%.”

Example answer

“Our error monitor alerted on a spike in failed profile saves shortly after a backend deployment. I correlated the Node.js logs with the request payloads and found that older clients were sending an optional phone field as an empty string, while the new MongoDB validation rule required either a valid number or no field. I patched the API to normalize empty optional fields to null and rolled it out behind a canary, which stopped the failures within 25 minutes. Then I added contract tests covering old and current client payloads and a dashboard alert for validation-error rates by API version. We had zero repeats of that issue over the next two release cycles.”

Example answer

“I would keep the filter query and selected record ID in the URL so refreshes and shared links preserve the view. The list data would be server state managed by a query library or a small fetch hook keyed by the normalized filter and page cursor, not copied into component state. When the filter changes, I would debounce the input, cancel or ignore obsolete requests, and render a clear loading state without erasing useful previous results. The details panel would fetch by selected ID only when opened, with an error boundary or inline retry path. If the dataset is large, I would use cursor pagination and ensure the Node.js endpoint accepts validated filter parameters rather than fetching everything into the browser.”

Example answer

“I would first reproduce the issue using a production-like account, throttled network, and a mid-range CPU profile rather than trusting my development laptop. In Chrome DevTools and our real-user monitoring data, I would compare API wait time, JavaScript execution, rendering, and Core Web Vitals by route. If the trace showed a 900 ms API call caused by an unindexed SQL filter, I would fix the query and add the appropriate index before optimizing React renders. If the bottleneck were a 700 KB charting bundle, I would lazy-load the chart route and defer noncritical data. I would release behind monitoring and verify p75 LCP, INP, API duration, and dashboard error rate rather than declaring success from a local Lighthouse run.”

Example answer

“I would expose a POST /orders endpoint that validates a versioned request body with a schema library and derives the customer identity from the verified session, not from a client-supplied userId. The server would load current product prices and availability, calculate totals itself, and reject stale or invalid cart lines. I would require an idempotency key so a retry after a timeout cannot create duplicate orders, storing the key and response with the order record. For a relational database, I would use a transaction for order rows and inventory reservation; payment-provider calls would be coordinated with explicit pending and failed states rather than pretending they are part of one database transaction. I would return stable error codes, log a request ID without leaking payment details, and track order creation latency and failure reasons.”

Example answer

“For a marketplace with orders, payments, refunds, inventory, and reporting, I would default to SQL because those entities need strong relationships, transactional updates, and reliable aggregate queries. I would model foreign keys, use constraints to prevent invalid states, and inspect query plans before adding indexes for common order-history and fulfillment queries. MongoDB can be a better fit for flexible, document-heavy content such as CMS pages with varying block structures or event payloads that are primarily read as whole documents. Even then, I would design indexes from actual queries and avoid unbounded arrays inside documents. The decision is not about which database is faster in general; it is about protecting the data invariants and serving the application’s read and write patterns predictably.”

Example answer

“I would tell product we can ship the banner by Monday, but I would not add an unreviewed third-party script directly to the production page. I would build the banner as a lightweight React component using the existing experiment or targeting data we already trust, with a generic fallback for users who do not qualify. I would measure its bundle impact, test keyboard and screen-reader behavior, and put the rollout behind a feature flag. In parallel, I would open the security and privacy review for the personalization vendor and provide the expected performance budget impact. That gets the campaign live without converting a marketing deadline into a persistent supply-chain and LCP problem.”

Example answer

“I would first check p95 latency and timeout rate by endpoint, release version, user cohort, and dependency to confirm whether the new code path is responsible. If the risky code is behind a feature flag or can be bypassed at the route level, I would disable that path for affected requests while preserving the unrelated feature. If it is a database issue, I might temporarily cap expensive filters, serve cached data where correctness allows, or route traffic to the prior query path. I would post a concise incident update with user impact, mitigation, and next checkpoint, then use traces and slow-query logs to identify the root cause. After recovery, I would add a release guard such as endpoint-level canary thresholds or a load test for the query shape that timed out.”

Example answer

“I would not start by polishing every ARIA attribute; I would first make the primary customer flow operable without a mouse. I would replace fake clickable divs with native buttons where possible, ensure dropdowns support keyboard selection and visible focus, and make the modal trap focus, announce its label, and return focus to its trigger on close. I would correct the heading hierarchy, connect form labels and validation errors to inputs, and fix contrast failures on the launch path. I would test the flow with keyboard-only navigation and a screen reader such as NVDA or VoiceOver, then log nonblocking issues with screenshots and acceptance criteria for the next sprint. That gives users a workable experience by launch rather than a superficial accessibility checklist.”

Example answer

“I would push back on implementing this as a synchronous browser download because a million-row response can exhaust server memory, hit gateway timeouts, and expose data without an auditable approval path. I would propose a POST endpoint that validates the requester’s export permission and filters, creates a background export job, and returns a job ID. A worker would stream paginated SQL or MongoDB reads to a CSV or encrypted archive in object storage, while the UI polls for status or receives a notification. The download link would be short-lived, scoped to the requesting account, and every export would be audit logged with row count and requester ID. For the immediate deadline, I could ship the request-and-notify flow for bounded exports and explicitly defer full historical exports until capacity limits and retention policies are approved.”