Frontend Developer Interview Questions

My workflow starts with understanding the requirements and any design specs before writing a single line of code. I break the UI into components early, thinking about which pieces hold state and which are purely presentational. I use TypeScript throughout, so type definitions come before implementation. For version control I work in short-lived feature branches, keep commits small and focused, and open pull requests for review before merging. I run the component in isolation using Storybook where the team uses it, write unit tests with Jest and React Testing Library as I build, and do a manual cross-browser check before marking something as ready. Code review is something I take seriously on both sides: I aim to leave comments that explain the why, not just flag problems.

I start by reproducing the issue reliably, noting exactly which browsers and versions are affected. Once I can reproduce it consistently, I use the browser's DevTools to inspect the DOM, check for CSS differences, and look at the console for errors. I isolate the failing component and strip it back to a minimal reproduction to rule out interactions with other code. For CSS bugs I check for properties with known compatibility gaps using MDN or Can I Use. For JavaScript issues I look for browser-specific APIs or event behaviour differences. I also check whether any polyfills are missing in the build config. Once I have identified the root cause, I fix it in a way that does not regress other browsers, then add a cross-browser test case to prevent recurrence.

When reviewing someone else's code I focus on correctness, maintainability, and performance rather than style preferences, which should be handled by a linter. I try to ask questions rather than make demands: "Have you considered X approach because of Y?" lands better than a blunt rejection. I always acknowledge what is working well before raising concerns. When receiving feedback I treat it as information rather than criticism. If I disagree with a comment I explain my reasoning once clearly and then defer to the reviewer or escalate to the team if it is genuinely unclear. I avoid arguing in the thread for the sake of it. The goal is to ship better code, not to be right. I also act on patterns I see repeatedly in my own reviews and adjust my approach before the next PR.

We had a React dashboard that was taking over four seconds to become interactive on mid-range devices. I started by profiling it in Chrome DevTools, which showed a large bundle size and a component tree that was re-rendering far more than necessary. The bundle analysis revealed we were importing an entire charting library for two chart types. I replaced it with a lighter alternative and used dynamic imports to split the charts into a separate chunk. For the re-renders I used React.memo and moved expensive calculations into useMemo with correct dependency arrays. After those changes the initial load dropped to under 1.5 seconds and the Largest Contentful Paint improved by 60%. I documented the findings in the team wiki so the patterns were reused on other parts of the product.

I try to get involved before the designs are finalised rather than receiving a completed spec to implement. Early involvement lets me flag technical constraints: for example, if an animation looks beautiful in Figma but would require a layout property that forces a full repaint on every frame, it is easier to adjust the design than to fight the browser later. During implementation I check in early with a rough build rather than waiting until I think it is perfect, because designers often spot things in the browser that they did not notice in the static mockup. I also ask about interaction states upfront: hover, focus, loading, error, and empty states are easy to miss in designs. When the finished work diverges from the spec for a legitimate technical reason, I explain why in writing so the designer understands the decision and can account for it in future work.

I separate signal from noise by focusing on browser standards and specifications first. New APIs like View Transitions or the Popover API represent real platform capability rather than framework opinion, so I prioritise understanding those. For frameworks, I follow release notes and RFCs for the tools I already use rather than chasing every new announcement. I keep a short reading list of trusted sources: MDN updates, the TC39 proposals repo, and a few engineers whose thinking I respect. When a new tool gains significant adoption I spend a few hours building something small with it to form my own view rather than relying on the hype cycle. I have declined to adopt several hyped tools that turned out not to fit our team's needs. Being selective about what you learn is as important as learning itself.

During a product launch we had a three-day window to build a feature that would normally take a week. I had a direct conversation with the team about what we were trading: we agreed to skip unit tests for the new components, use a simpler state approach that we knew would need refactoring later, and defer accessibility improvements beyond keyboard navigation. I created a technical debt ticket immediately with the specific items we deferred and estimated the cleanup cost so it did not get forgotten. We shipped on time. Two weeks after launch I picked up the debt ticket and completed the refactor, including full test coverage and ARIA improvements. The key for me is making the trade-off explicit and tracked, not invisible. Invisible shortcuts are what create unmaintainable codebases.

I start by measuring the current state with Lighthouse and the Chrome User Experience Report to understand which metrics are failing in real user sessions, not just in lab conditions. For Largest Contentful Paint I look at whether the hero image or heading is being loaded with the right priority: it should have fetchpriority="high" and not be lazy-loaded. For fonts I use font-display: swap and preload the critical subset. For Cumulative Layout Shift I audit any element whose size is determined by content loaded after the initial render, including images without explicit dimensions and dynamically injected banners. For Interaction to Next Paint I profile JavaScript execution on slow devices and look for long tasks to split with scheduler.yield or move to a web worker. I also check for render-blocking scripts and stylesheets that can be deferred.

Accessibility is something I build in from the start rather than audit at the end. I use semantic HTML as the foundation: a well-structured document with correct heading hierarchy, landmark regions, and native form elements handles a large proportion of accessibility requirements without any ARIA. When I do use ARIA I follow the first rule: do not use ARIA if a native element can do the job. For interactive components I check that all functionality is reachable by keyboard, that focus is managed correctly when modals or dynamic content appears, and that visible focus indicators meet WCAG contrast requirements. I test with a screen reader, primarily VoiceOver on Mac and NVDA on Windows, at least once per feature. I also run automated checks with axe-core as part of the test suite to catch regressions. Automated tools catch roughly 30 to 40% of issues, so manual testing is not optional.

I think about components in terms of their responsibility. Presentational components receive props and render UI, with no knowledge of where the data comes from. Container components handle data fetching and state management and pass data down. Shared UI primitives live in a design system folder and are kept generic. Feature-specific components live alongside the feature they belong to, not in a shared folder, because co-location makes it easier to understand scope and delete code safely. For state I keep it as close to where it is used as possible: local state first, then context for cross-component state, then a global store only when truly needed. I also think carefully about the API surface of each component, keeping props minimal and avoiding prop drilling past two levels by using composition patterns instead. A large application that is easy to navigate is the result of consistent decisions about where each kind of logic lives.