Frontend Developer Interview Questions & Answers

Sample Answer

The design team delivered mockups for a data table with infinite scroll, real-time sorting, inline editing, and animated row transitions — all on a dataset of 100K+ rows. I prototyped it and found that DOM rendering plus animation for that many rows tanked performance below 10fps on mid-range devices. Instead of just saying 'it's impossible,' I built two alternatives: one using virtualized rendering (react-window) that kept smooth scrolling but simplified the animations, and another with pagination that preserved all the visual effects. I demoed both to the designer with performance metrics. We chose the virtualized approach with simplified row transitions. The designer appreciated seeing the tradeoff visually rather than hearing 'no' abstractly. The final implementation handled 100K rows at 60fps with all core functionality intact.

Sample Answer

Our e-commerce homepage had a Largest Contentful Paint of 4.2 seconds, and conversion data showed a 7% drop in purchases for every additional second of load time. I identified three bottlenecks: a 2MB hero image, 800KB of synchronous JavaScript, and a render-blocking CSS file importing unused stylesheets. I converted the hero image to WebP with responsive srcset, code-split the JavaScript bundle using dynamic imports (reducing initial load by 65%), and inlined critical CSS while loading the rest asynchronously. LCP dropped to 1.1 seconds. Over the next month, conversion rate increased by 9% and bounce rate decreased by 15%. The total engineering effort was 4 days — one of the highest-ROI projects I've worked on.

Sample Answer

I built a shared React component library for a company with 4 product teams that were each implementing their own buttons, modals, and forms. I started by auditing existing components across all products — we had 12 different button variants. I consolidated them into 4 (primary, secondary, ghost, danger) with consistent sizing and spacing. I used TypeScript for strict prop typing, Storybook for documentation and visual testing, and Chromatic for visual regression testing. I versioned the library with semantic versioning and published it to a private npm registry. Adoption was the harder part — I ran weekly office hours, created a migration guide for each product, and submitted PRs to show teams how to replace their custom components. After 4 months, all teams were using the shared library, design consistency improved visually, and new feature development time decreased because developers stopped rebuilding common components.

Sample Answer

We received bug reports that our form validation wasn't working on Safari iOS. The issue: we were using the Constraint Validation API's reportValidity() method, which Safari supported but handled differently — it showed the error tooltip but didn't prevent form submission on iOS. I traced the bug to a WebKit rendering issue where the tooltip appeared behind the virtual keyboard. My fix had three parts: replaced native validation tooltips with custom inline error messages (better UX anyway), added a JavaScript validation layer as a fallback, and set up BrowserStack cross-browser testing in our CI pipeline to catch Safari-specific issues early. I also created a compatibility testing checklist for the team covering Safari iOS, Chrome Android, Firefox, and Edge. The fix resolved 40+ open Safari-related bug reports at once.

Sample Answer

The Virtual DOM is a lightweight JavaScript representation of the actual DOM. When state changes, React creates a new virtual DOM tree and diffs it against the previous one — this is reconciliation. React uses a heuristic O(n) algorithm: it compares trees level by level, assumes elements of different types produce different trees (and tears them down completely), and uses 'key' props to identify which children in a list have changed, moved, or been removed. When diffing finds a difference, React batches the minimal set of actual DOM operations needed. This is faster than manipulating the real DOM directly because DOM operations are expensive (they trigger layout recalculation, paint, and composite), while JavaScript object comparison is cheap. The key practical implication: always use stable, unique keys for list items (not array indices), avoid creating new object/function references in render (they defeat memoization), and use React.memo, useMemo, and useCallback when profiling shows unnecessary re-renders.

Sample Answer

Flexbox is one-dimensional — it handles layout in either a row or a column. Grid is two-dimensional — it handles rows and columns simultaneously. I use Flexbox for component-level layout: aligning items in a navbar, spacing buttons in a toolbar, centering content vertically and horizontally. Flexbox excels when the content size should determine the layout. I use Grid for page-level layout: defining the overall page structure, creating complex card grids, building dashboard layouts with multiple regions. Grid excels when you want the layout to define the content placement. In practice, I combine both: Grid for the macro layout (header, sidebar, main content, footer) and Flexbox for micro layout within each grid cell. The common mistake is reaching for Grid for a simple row of items or using Flexbox hacks (negative margins, pseudo-elements) when Grid would be cleaner.

Sample Answer

I categorize state by its nature and choose tools accordingly. Local UI state (form inputs, toggle states, modal visibility): useState or useReducer. Keep it in the component that owns it, lift only when truly needed. Server state (data from APIs): React Query or SWR. These handle caching, refetching, optimistic updates, and loading/error states far better than manual Redux patterns. I never put server data in global state. Global client state (theme, auth, user preferences): React Context for low-frequency updates (theme, locale), or Zustand for state that changes often and needs selective subscription to avoid re-renders. URL state (filters, pagination, search params): React Router's useSearchParams. The state lives in the URL, enabling bookmarking and sharing. The anti-pattern I avoid: putting everything in a single global store. It creates coupling, makes testing harder, and usually means components re-render when unrelated state changes. Each category of state has the right tool; the art is choosing correctly.

Sample Answer

A closure is a function that retains access to variables from its outer scope even after the outer function has finished executing. The inner function 'closes over' the variables it references. A practical example: a debounce function. When you write debounce(fn, delay), the returned function has access to the timer variable defined in debounce's scope. Each time the returned function is called, it clears the previous timer and sets a new one. The timer variable persists across calls because of the closure — it's not garbage collected as long as the returned function exists. Another real-world use: React's useState hook. When you call setCount(count + 1), the count value comes from the closure created when the component rendered. This is why stale closures are a common React bug — if you use count inside a useEffect without including it in the dependency array, the effect closes over the initial value and never sees updates.

Sample Answer

First, I'd verify my understanding of both the design requirement and the API limitation. Sometimes what looks like a limitation is actually a different endpoint or query parameter I haven't found. I'd check the API documentation and talk to the backend developer. If the limitation is real, I'd evaluate three options. One: can the frontend derive the needed data from existing API responses? Sometimes a client-side computation or transformation solves it without backend changes. Two: is a backend API change feasible within the timeline? If it's a simple addition, I'd discuss it with the backend team and see if we can coordinate. Three: can we adjust the design to work with the available data without compromising user experience? I'd present the constraint and alternatives to the designer and PM with my recommendation. What I wouldn't do: hack around the limitation with multiple API calls, client-side joins, or caching tricks that create maintenance debt. If the right solution is a backend change, advocating for it is part of my job.

Sample Answer

I'd avoid technical jargon entirely. I'd use an analogy: 'It's like asking to add a door to a room — the door itself is simple, but it means moving electrical wiring and potentially adjusting the building's load-bearing wall.' Then I'd be specific about the timeline: 'The button itself is 30 minutes of work. But the data it needs doesn't exist in the system yet, and building the pipeline to get that data is about 2 weeks.' I'd also present options: 'We could ship a simpler version that uses existing data by next week, or the full version you're imagining in 3 weeks. Which would you prefer?' The key is being honest about complexity without making the stakeholder feel stupid for asking. They don't need to understand why it's complex — they need to understand the timeline and their options.

Sample Answer

I'd evaluate on five dimensions, not hype. First, team readiness: how much ramp-up time does the new framework require? If the team knows React and we're considering Svelte, that's 4-6 weeks of reduced productivity. Is the timeline flexible enough? Second, ecosystem maturity: are there libraries for routing, state management, form handling, and testing? Can we find answers on Stack Overflow? Third, hire-ability: can we find engineers who know this framework? React has a much larger talent pool than Solid or Qwik. Fourth, performance: does the new framework solve a real performance problem we have? If our React app is fast enough, switching for benchmarks is premature optimization. Fifth, longevity: is this backed by a stable organization or community? What's the commit frequency, contributor count, and corporate adoption? I'd prototype a representative feature in both the current and proposed framework, measure actual development speed and performance, and present the comparison to the team. The decision should be data-driven, not trend-driven.

Sample Answer

I'd address it proactively rather than waiting for it to become a problem. I'd compile a short list of specific accessibility issues I can see in the mockups: missing focus states, insufficient color contrast, icons without text labels, form fields without visible labels. Then I'd bring it up with the designer constructively: 'I noticed a few accessibility gaps we should address before development. Here are the specific items.' I'd propose solutions, not just problems: 'This button needs a focus ring — here's what it could look like. This text is 3.2:1 contrast but needs 4.5:1 — darkening it by two shades would fix it.' If the designer pushes back on timeline, I'd explain the legal and business risk: accessibility lawsuits are increasing, and fixing accessibility after development costs 3-5x more than building it in. I'd also set up automated accessibility checks (axe-core in CI) to prevent regression.