Frontend Developer Interview Questions and Answers

I start with field data rather than a lab score, because the largest element differs by page and device. On a recent listing page the hero image was the LCP element, and the trace showed three sources of delay: the image was discovered late because it sat behind a client-side fetch, the server response was slow under load, and a web font blocked text rendering. I ranked the fixes by effort and expected impact. I preloaded the hero image, moved the fetch to the server, set explicit dimensions to stop layout shift, and subset the font. Each change shipped separately so I could attribute the improvement, and the metric fell from four seconds to under two on the same throttled test devices.

My default is local state, because every piece of state you lift becomes a public API that other components depend on. I lift it when two components at different depths need the same value and the intermediate components would otherwise become pass-through props. I reserve a global store for genuinely cross-cutting concerns: the authenticated user, theme, feature flags and a small amount of server cache. The test I use is whether the value would still make sense if the feature were deleted. If the answer is no, it does not belong in a global store. I also watch for prop shape churn, because a prop that changes shape every sprint usually means the data is owned one level too high.

I would first question whether a native select or a disclosure pattern does the job, because native elements get keyboard and screen-reader behavior for free. If the design truly requires a custom listbox, I give the trigger a button role with aria-haspopup and aria-expanded, and the popup a listbox role with option children. Focus moves into the list on open and returns to the trigger on close; Escape closes without selecting; arrow keys move the active option; typing jumps to a matching option. I manage aria-activedescendant so the screen reader announces the highlighted option. Then I test with VoiceOver and NVDA, because automated tools catch missing labels but not a broken focus order.

First I make it reproducible, because a bug I cannot reproduce reliably is a bug I cannot fix confidently. I strip the page down until the smallest element still breaks, which usually removes half the candidates. Then I compare computed styles and box model numbers in each browser devtools, looking for a property that resolves differently. Common causes are a missing doctype that flips quirks mode, a flex item with min-width auto refusing to shrink, or a grid definition the browser parses with different defaults. Once I know the mechanism I fix the underlying markup or CSS rather than adding a browser-specific override. Finally I add a visual regression snapshot at the breakpoint that failed so the fix stays fixed.

A checkout redesign arrived as static frames with hover and disabled states missing, so I guessed at the error states and built them wrong. The rework cost about two days and delayed the release. Instead of blaming the designer, I showed the frames back with the states I had invented and asked which were acceptable. We agreed that every handoff would include interactive states, responsive breakpoints and edge cases like very long names. I also joined the design review one step earlier so I could flag technical constraints before the visuals were frozen. The next two features shipped with no state-related rework, and that checklist became part of the team definition of ready.

I profile first with the React DevTools profiler or the browser performance panel, because guessing which component re-renders is usually wrong. The most common cause I find is state that lives too high, so one keystroke re-renders a whole tree; moving that state down or splitting the component fixes it without any memoization. When a genuinely expensive subtree still re-renders, I wrap it in memo and make sure the props it receives are stable, since an inline object or arrow function defeats the comparison. I add useCallback and useMemo only where the profiler shows real cost, because blanket memoization adds complexity and its own overhead. Then I re-measure and stop optimizing components that never appear in the profile.

I split the problem. The validation rules themselves are pure functions, so I unit-test them with a table of inputs and expected messages, including the boundary values a product manager would forget. Then I test the form as a user experiences it using the testing library: type an invalid value, submit, assert that the message appears and focus moves to the field. That catches wiring bugs without a real browser. I keep one Playwright test for the full journey against a real API, because that is where serialization and server-side validation errors surface. The cases I make sure to cover are asynchronous: a username-availability check that returns after the user has moved on, and a double submit while the first request is still in flight.

I would first work out whether the slowness is network time or execution time, because the fixes are completely different. I look at real-user monitoring segmented by country and connection type rather than a single average, since an average hides the tail. If time to first byte is high only overseas, the origin is the problem and the answer is a CDN, edge caching or regional deployment. If the download is slow but the server is fast, the bundle is too large for that connection and needs splitting or better compression. If the page arrives quickly but paints slowly, the problem is client-side rendering on slower devices. Once I have a hypothesis I reproduce it under throttling from a matching region, ship the fix, and confirm it in the same segmented field data.

A shared data table was the repeated problem: four teams had each built their own, with different sorting and empty states. I designed one table with a small required prop set and slots for the parts that genuinely varied, keeping cell rendering and row actions composable. The hard decision was resisting a prop for every request; I said no to several and pointed teams at composition instead. I documented it in Storybook with usage examples and treated the prop names as a public API with a deprecation policy. Adoption reached four teams within two quarters. After feedback I added a controlled sort mode and renamed one prop, which was only safe because we had versioned it from the start.

Show it in the build: name the audit, the specific violations fixed and the assistive technology you tested with, rather than a generic accessible-design line.

Mention how data reaches the component: the API client, caching, optimistic updates and error states, because senior roles are screened for exactly that.

Translate it once, for example 'our internal component library, equivalent to a themed Material UI'; an ATS and a recruiter both read this line cold.