Frontend & React Interview Questions

In development, React's Strict Mode intentionally invokes your function component twice per render cycle. This is not a bug; it is designed to surface side effects hidden inside the render phase. If double-invoking changes the output, your component has impure render logic. The second invocation is discarded before the DOM updates, so you never see it in production. Outside of Strict Mode, a component re-renders any time its state or props change, its parent re-renders, or a context value it subscribes to is updated. A re-render is just React calling your function again and comparing the new output against the previous render tree through reconciliation. The DOM only changes where the output differs. Understanding this distinction between a React re-render and a DOM update is what separates developers who write performant components from those who guess.

I reach for useState when a value needs to drive a re-render: form inputs, toggle flags, fetched data. I reach for useRef when I need to persist a value across renders without triggering one: storing a timer ID, capturing a previous prop for comparison, or holding a DOM node. The critical distinction is that mutating ref.current is invisible to React, so it never schedules a paint. The mistake I see most is using a ref to hold something the UI depends on, then wondering why the screen does not update. My rule: if the display changes when the value changes, that is state. If it is bookkeeping the component needs but the user never sees, that is a ref.

My default rule is one dimension versus two. I use Flexbox when I am arranging items along a single axis, like a navigation bar or a row of cards that wraps. I use CSS Grid when the layout depends on both rows and columns simultaneously, like a dashboard, a photo gallery, or any design that requires explicit tracks. The confusion arises because Flexbox can fake two-dimensional alignment in many situations, so developers never bother learning Grid. The tell is when I find myself fighting flex-wrap and manually sized flex-basis values to approximate a grid layout. That friction is Grid telling me it belongs. I pick the tool that matches the mental model of the layout, not the one I happen to know better.

My first move is to separate perception from measurement. I open Chrome DevTools Performance panel and record a cold load, then check Lighthouse for a lab baseline across LCP, CLS, and TBT (the lab proxy for INP; INP itself needs field data or a DevTools timespan recording). At the same time I look at real-user monitoring data if it exists, because lab scores and field scores diverge constantly. I check the Network tab for render-blocking resources, oversized images, and slow third-party scripts. Then I look at the main-thread flame chart for long tasks over 50ms. Only after I have data in front of me do I form a hypothesis. Gut instinct is a starting point, not a diagnostic.

My default question is: does this page change per user or per request? Static site generation wins for marketing pages and docs because build-time rendering is free CDN cache. Server-side rendering earns its complexity when content is personalized or must be fresh on every load, like a dashboard or checkout page. Client-side rendering is fine for highly interactive apps behind a login where SEO does not matter. Most real products land in the middle, so I reach for a hybrid: statically generate the shell, stream server-rendered data into it, and hydrate interactivity on the client. The mistake I see is defaulting to CSR everywhere because it is familiar, then retrofitting SSR at scale to fix Core Web Vitals scores that product suddenly cares about.

My first step is to gather environment details: browser version, OS, screen size, network conditions, and the exact sequence of clicks. I ask the user to record a short video or share a console screenshot. Then I check our error monitoring tool for exceptions logged around the time of the report. If nothing surfaces, I audit feature flags and A/B variants, because the user may be in a cohort I have not tested myself. I also look for race conditions tied to slow connections. If the bug still does not reproduce, I add targeted logging to the suspected code path and ask the user to trigger it again. Reproducing the exact environment is the job; guessing without it wastes everyone's time.