Frontend Architecture Interview Questions for Frontend Development

Show answer

A single-page app loads once and renders views in the browser, giving app-like navigation but slower first load. A multi-page app renders each page on the server with full reloads. Server-side rendering generates HTML per request for fast content and SEO, then hydrates. Static site generation pre-builds HTML at build time and serves it from a CDN, which is fastest for content that changes rarely, like blogs.

How does client-side rendering affect SEO and social sharing?

Show answer

With pure client-side rendering, the initial HTML is mostly empty and content appears after JavaScript runs. Google can render JavaScript, but it happens later and less reliably, while many social media link previewers and some search engines do not run JavaScript at all, so titles and images are missing. Server rendering or prerendering important pages ensures content and meta tags are in the initial HTML.

At a high level, how does React's virtual DOM and reconciliation work?

Show answer

React components return a description of the UI as a tree of elements. When state changes, React renders a new tree and compares it with the previous one, a process called reconciliation, then applies only the minimal DOM changes needed. Keys help it match list items correctly. The React Compiler now adds automatic memoisation, reducing unnecessary re-renders without manual useMemo calls.

Where do you see yourself in five years as a frontend developer?

Show answer

In five years, I want to be a senior frontend engineer who owns complex features end to end and helps shape architecture decisions. I plan to deepen my skills in performance, accessibility and TypeScript, and contribute to a design system. I also want to mentor juniors, because teaching others is how I learned best. I hope to grow within a team where I can take on that responsibility.

What is the difference between local UI state, global state and server state?

Show answer

Local state belongs to one component, like whether a dropdown is open. Global client state is shared across the app, like theme or the logged-in user. Server state is data owned by the backend, such as orders, that must be fetched, cached, refreshed and kept in sync. Treating server state separately with tools like TanStack Query removes much of the code teams once wrote in global stores.

What does component-driven development mean?

Show answer

Component-driven development builds UIs from the bottom up as small, reusable, isolated components, such as buttons and inputs, composed into larger patterns like forms and pages. Each component has a clear API through props or attributes and is developed and documented in isolation, often in Storybook. Composition over configuration keeps components flexible. This approach enables design systems, parallel work and easier testing.

Write a minimal observable store in plain JavaScript.

Show answer

A store holds state and notifies subscribers: function createStore(initial) { let state = initial; const listeners = new Set(); return { get: () => state, set(update) { state = { ...state, ...update }; listeners.forEach(fn => fn(state)); }, subscribe(fn) { listeners.add(fn); return () => listeners.delete(fn); } }; } const cart = createStore({ items: 0 }); const stop = cart.subscribe(s => (badge.textContent = s.items)); cart.set({ items: 2 }); The returned unsubscribe function prevents memory leaks.

Implement simple feature flags on the frontend.

Show answer

Load flags once and check them where needed: let flags = {}; export async function loadFlags(userId) { const res = await fetch('/api/flags?user=' + encodeURIComponent(userId)); flags = res.ok ? await res.json() : {}; } export const isEnabled = (name) => flags[name] === true; // usage await loadFlags(currentUser.id); if (isEnabled('new-checkout')) renderNewCheckout(); else renderOldCheckout(); Defaulting to off when the request fails keeps the stable path. Flags enable gradual rollouts, but old flags must be removed to avoid clutter.

Write a React custom hook that fetches data and cancels on unmount.

Show answer

Use AbortController inside useEffect: import { useEffect, useState } from 'react'; export function useFetch(url) { const [state, setState] = useState({ data: null, error: null, loading: true }); useEffect(() => { const controller = new AbortController(); setState(s => ({ ...s, loading: true })); fetch(url, { signal: controller.signal }) .then(r => (r.ok ? r.json() : Promise.reject(new Error(r.status)))) .then(data => setState({ data, error: null, loading: false })) .catch(err => { if (err.name !== 'AbortError') setState({ data: null, error: err, loading: false }); }); return () => controller.abort(); }, [url]); return state; } In production apps, TanStack Query adds caching and retries.

State is passed through many component layers and global state has become chaotic. How do you restructure it?

Show answer

I would first classify state: server data moves to a data-fetching cache like TanStack Query, URL-worthy state such as filters moves to query parameters, and truly local state moves back into components. What remains global, like user session and theme, goes into a small, well-defined store or context split by concern. Composition patterns, passing components as children, also remove much prop drilling.

Your app needs to support Hindi and English. How do you design internationalisation?

Show answer

I would move all UI text into translation files keyed by message ids, use an i18n library that supports plurals and interpolation, and format numbers, dates and currency with Intl APIs for each locale, like en-IN and hi-IN. Layouts must handle longer text and Devanagari fonts with proper line height. The locale goes in the URL, such as /hi/, with hreflang tags for SEO and lang on html.

A dashboard must show live order updates. Would you use polling, Server-Sent Events or WebSockets?

Show answer

Polling is simplest and fine if updates every 30 seconds are acceptable. Server-Sent Events push one-way updates from server to browser over HTTP with automatic reconnection, ideal for live orders, notifications and stock tickers. WebSockets provide full two-way communication, needed for chat or collaborative editing, but require more infrastructure. For a one-way dashboard, I would choose SSE and reconnect gracefully on network changes.

How would you choose a frontend framework for a new project?

Show answer

I would base it on project needs and team context rather than trends: team experience, hiring market in India, SEO and rendering requirements, ecosystem maturity, long-term support and performance on target devices. React has the largest ecosystem and talent pool, Angular suits large enterprise teams wanting an opinionated structure, Vue is approachable, and Svelte or Astro produce less JavaScript. A small proof of concept helps confirm the choice.

Users report errors you cannot reproduce. How do you set up frontend observability?

Show answer

I would add an error monitoring tool like Sentry with uploaded source maps, release tags and user context such as browser and route, without personal data. Real user monitoring tracks Web Vitals and slow API calls. Breadcrumbs of clicks and network requests before an error help reproduce issues, and session replay with privacy masking shows what users saw. Alerts on error spikes after a release enable quick rollbacks.

How do you estimate the time needed for a frontend feature?

Show answer

I break the feature into small parts: components, states such as loading, empty and error, API integration, responsive behaviour, accessibility and tests. I estimate each part, add time for reviews and unknowns, and flag dependencies like pending designs or APIs. For example, a filter panel I estimated at five days was delivered in five because I had listed edge cases upfront instead of discovering them late.

How do you balance technical debt against delivering new features?

Show answer

Situation: our team constantly added features while an outdated build setup slowed everyone. Task: I needed time for cleanup without stalling the roadmap. Action: I quantified the cost, about 30 minutes lost per developer daily, and proposed reserving roughly 15 percent of each sprint for debt, starting with the biggest pain points. Result: the product manager agreed, build times halved, and feature delivery actually sped up.

What are micro-frontends and when do they make sense?

Show answer

Micro-frontends split a large web app into independently developed and deployed pieces, each owned by a team, composed at runtime with Module Federation, web components or server-side composition. They help large organisations where many teams block each other on one release. The costs are duplicated dependencies, inconsistent UX, complex shared state and harder performance tuning. For most teams, a well-structured monorepo is simpler.

Where should a frontend store authentication tokens?

Show answer

Tokens in localStorage are readable by any script, so a single XSS exposes them. The safer pattern is an HttpOnly, Secure, SameSite cookie set by the server, invisible to JavaScript, paired with CSRF protection. When an access token must be held in JavaScript, keep it short-lived in memory and refresh it using an HttpOnly refresh cookie. A backend-for-frontend layer can keep tokens entirely off the browser.

Build an API client that refreshes an expired access token once and retries.

Show answer

Share one refresh promise so parallel requests do not refresh repeatedly: let refreshing = null; async function api(path, options = {}) { let res = await fetch(path, { ...options, credentials: 'include' }); if (res.status !== 401) return res; refreshing ??= fetch('/auth/refresh', { method: 'POST', credentials: 'include' }) .finally(() => (refreshing = null)); const refreshed = await refreshing; if (!refreshed.ok) { location.assign('/login'); throw new Error('Session expired'); } return fetch(path, { ...options, credentials: 'include' }); } Cookies carry the tokens, so JavaScript never reads them.

Which rendering strategy would you choose for a large e-commerce site?

Show answer

I would mix strategies by page type. Category and product pages need SEO and fast LCP, so I would use static generation with incremental revalidation or server rendering with CDN caching. Cart, checkout and account pages are personalised, so server rendering without shared caching or client rendering works. Prices and stock can be fetched fresh on the client. Frameworks like Next.js, Nuxt and Astro support this per-route choice.

Ten teams work on one large frontend and releases keep blocking each other. What would you propose?

Show answer

I would first try a modular monorepo with clear package boundaries, code owners, affected-only CI with Nx or Turborepo, and trunk-based development with feature flags, which removes most blocking at low cost. If teams truly need independent deployments, I would introduce micro-frontends along business domains, such as search, product and checkout, with a shared design system and strict performance budgets to control duplication.

How do you secure a modern frontend application beyond what the framework provides?

Show answer

Frameworks escape output by default, but risks remain: dangerouslySetInnerHTML or v-html with unsanitised data, javascript: URLs in links, and vulnerable npm packages. I would sanitise any HTML with DOMPurify, enforce a strict Content Security Policy with nonces, use Subresource Integrity for CDN scripts, keep tokens in HttpOnly cookies, run dependency audits in CI and never place secrets in frontend environment variables.

Design the frontend for a search box with autocomplete suggestions.

Show answer

I would debounce input by about 200 milliseconds, cancel outdated requests with AbortController and cache recent queries in a Map. Suggestions render in an accessible combobox pattern with aria-expanded, aria-activedescendant and arrow key navigation. I would highlight matched text safely, show loading and empty states, and limit results to around eight. Measuring latency and prefetching popular terms keep it feeling instant on slow networks.

Field agents need a form app that works in areas with no internet. How would you build it?

Show answer

I would build an offline-first PWA: a service worker caches the app shell, and submissions are saved in IndexedDB with a sync status. When connectivity returns, a background sync or online event uploads pending records with idempotency keys so retries never create duplicates. The UI clearly shows synced and pending items. Conflict rules, such as server timestamps winning, must be agreed with the backend team.

Tell me about a frontend architecture decision you led.