Frontend developer interviews test how well you know the building blocks of the web (HTML, CSS and JavaScript), a framework such as React, and how you keep an interface fast, accessible and easy to maintain. These questions go from the fundamentals asked of freshers to the architecture questions senior candidates face.
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
var is function-scoped, is hoisted and initialised to undefined, and can be redeclared. let and const are block-scoped and stay in the "temporal dead zone" until their declaration runs, so using them early throws an error. const cannot be reassigned, but an object or array it points to can still be changed. I use const by default, let when the value must change, and avoid var.
Every element is a box made of content, padding, border and margin, from the inside out. By default (box-sizing: content-box) width applies only to the content, so padding and border make the box bigger. With box-sizing: border-box, width includes padding and border, which makes layouts predictable, so most projects set it globally. Vertical margins between block elements can also collapse into one.
== compares after converting types, so "5" == 5 and null == undefined are both true. === compares value and type without conversion, so "5" === 5 is false. I use === everywhere to avoid surprises. The one common intentional use of == is value == null, which checks for both null and undefined at once.
Semantic elements such as header, nav, main, article, button and label describe what content means, not just how it looks. Screen readers use them to let users jump between regions, search engines understand the page better, and elements like button give keyboard focus and Enter/Space handling for free. A div with an onClick handler has none of that, so semantic HTML is the first step to accessibility.
Applied problems, trade-offs and questions about your own projects.
A closure is a function that remembers the variables from the scope where it was created, even after that outer function has returned. For example, a makeCounter function can return an increment function that keeps updating a private count variable. Closures are used for data privacy, callbacks, memoisation and React hooks. A common bug is a stale closure, where a setInterval or useEffect callback keeps reading an old state value.
JavaScript runs on a single call stack. Asynchronous callbacks wait in queues. When the stack is empty, the engine first runs all microtasks (promise callbacks, queueMicrotask), then takes one macrotask (setTimeout, I/O, user events), and the browser may then render. That is why Promise.resolve().then(...) runs before setTimeout(..., 0). Long synchronous work blocks everything, including rendering, so heavy tasks should be split up or moved to a Web Worker.
A component re-renders when its own state changes, when its parent re-renders, or when a context it reads changes. A prop change on its own is not the trigger; the parent re-rendering is. To avoid wasted renders I first measure with the React Profiler, then use React.memo for expensive children, useMemo and useCallback to keep props stable, move state closer to where it is used, and split large contexts.
useEffect runs after the browser has painted, so it does not block the screen; it is right for data fetching, subscriptions and logging. useLayoutEffect runs synchronously after DOM changes but before paint, so it is used to measure layout or adjust positions without a visible flicker. Overusing useLayoutEffect delays paint. Both run their cleanup before the next run and on unmount.
System design, deep internals, leadership and tough follow-ups.
I start by measuring: Lighthouse and Core Web Vitals (LCP, INP, CLS) for the page, and the React Profiler for rendering. Then I reduce JavaScript with code-splitting (lazy and dynamic imports) and by removing heavy dependencies; fix rendering with memoisation and virtualised long lists; and improve loading with optimised images, caching, preloading critical assets and server rendering for faster first paint. After each change I re-measure to confirm the gain.
With client-side rendering the browser downloads JavaScript and builds the page; hosting is simple but first paint is slower and SEO is weaker. Server-side rendering builds HTML on each request, giving fast first content and good SEO at the cost of server work. Static generation builds HTML at build time and serves it from a CDN, which is fastest but can be stale; incremental regeneration refreshes it. Frameworks like Next.js let me choose per page based on how often data changes and whether it is personalised.
I separate state by type. Local UI state stays in useState. Server data goes in a server-state library such as React Query or SWR, which handles caching, refetching and loading states. Shared client state uses context or a small store like Zustand or Redux. Filters and pagination live in the URL, and forms use a form library. The biggest improvement in most apps is moving server data out of a global store, and keeping every piece of state as close as possible to where it is used.
I start with semantic HTML and native controls, label every input, add alt text to meaningful images, and make everything usable by keyboard with a visible focus style. Modals must trap and return focus. Text contrast should meet WCAG AA (4.5:1 for body text), colour should never be the only signal, and dynamic updates are announced with live regions. ARIA is only for cases native HTML cannot cover. I test with a keyboard, a screen reader such as NVDA or VoiceOver, and tools like axe or Lighthouse.