Frontend Developer Interview Questions & Answers (with Model Answers)

Model Answer

I default to keeping state as local as possible because local state is easier to reason about and test. I lift state up only when multiple sibling components need it, and I reach for a global store when state is truly cross-cutting, like the authenticated user or a theme. I avoid putting server data in a global store directly and prefer a data-fetching layer with caching. This keeps the global store small and intentional.

Model Answer

Our dashboard had a Largest Contentful Paint of over four seconds on mobile. I profiled with Lighthouse and the Performance panel, found a giant unoptimised hero image and a render-blocking bundle. I introduced responsive images with modern formats, code-split the route, and deferred non-critical scripts. LCP dropped to under two seconds and bounce rate on that page fell noticeably.

Model Answer

I build on semantic HTML first because native elements give keyboard and screen-reader support for free. I test with keyboard-only navigation and a screen reader, and I use ARIA only when semantics fall short. I check colour contrast and ensure focus states are visible and logical. I also add accessibility checks into the CI pipeline so regressions are caught automatically.

Model Answer

I treat designers as partners and get involved early rather than receiving a finished mockup over the wall. I raise feasibility and edge cases like empty states and error states during design review. I build a shared component library so the implementation matches the design system consistently. When a pixel-perfect detail conflicts with performance or accessibility, I discuss the trade-off openly rather than silently changing it.

Model Answer

I follow a few trusted sources like browser release notes and the maintainers of the frameworks I use rather than chasing every new library. I evaluate new tools against real problems on my team instead of adopting them for novelty. I build small prototypes to form my own opinion before recommending anything. This keeps me current without churning the codebase on hype.

var is function-scoped and hoisted with an initial value of undefined, which causes subtle bugs. let and const are block-scoped and live in a temporal dead zone until declared. const additionally prevents reassignment of the binding, though the referenced object can still be mutated.

The virtual DOM is an in-memory representation of the UI that the framework diffs against the previous version to compute the minimal set of real DOM updates. Because direct DOM manipulation is expensive, batching and minimising those updates improves performance. It also lets developers write declarative code while the framework handles efficient reconciliation.

Event delegation attaches a single listener to a common ancestor and uses event bubbling to handle events from many child elements. It reduces memory use and works for dynamically added children without rebinding. You inspect event.target to determine which child triggered the event.

Debounce delays running a function until a pause in events, so it fires once after activity stops, which suits search-as-you-type. Throttle guarantees the function runs at most once per interval during continuous events, which suits scroll or resize handlers. Both limit how often expensive work runs in response to rapid events.

Specificity ranks selectors by inline styles, then IDs, then classes and attributes, then elements, with higher specificity winning. When specificity ties, the later rule in source order wins. Overusing IDs or !important creates brittle overrides, so favouring low-specificity class-based selectors keeps styles maintainable.

A client needed our app to work on a legacy browser used in their warehouses. I audited the features we relied on, added targeted polyfills, and used progressive enhancement so modern browsers still got the full experience. I set up a test matrix in BrowserStack to verify each release. The app shipped working across all required browsers without bloating the modern bundle.

A dependency upgrade silently changed a date format and broke our reporting screen. I rolled back the deploy immediately to restore the UI, then reproduced the issue in a branch. I pinned the dependency, added a visual regression test for that screen, and re-released. The postmortem led us to add automated screenshot diffs to CI.

A design used a tiny tap target on mobile that would frustrate users. I prototyped both versions and ran a quick test with five colleagues showing the larger target reduced mis-taps. I shared the data with the designer rather than asserting an opinion. We adopted the larger target and updated the design system guideline.

Our components were duplicated across three teams with slight differences. I proposed and led the extraction of a shared component library with documented props and Storybook examples. I migrated teams incrementally to avoid a risky big-bang change. Duplication dropped sharply and new features shipped faster afterward.