Frontend Interview Questions: JavaScript, Rendering and Performance

The five buckets below, with a resume deep-dive layered on top and, depending on the company, live coding or a take-home review. The company's own process description decides which combination you will face, so read it before allocating practice time. The table is an editorial suggestion from Preterview, not a published rubric from any employer.

Attaching one case per type is a better use of time than lengthening the question list. A case gives you material for the follow-up 'why did you do it that way,' and a type with no case attached is your first item to fix. If TypeScript is in the posting, prepare generics and narrowing the same way, with an example from your own code.

Aim for three filled slots: a definition, the mechanism behind it, and a case you hit personally. For the event loop, start from why a single-threaded language can do asynchronous work, walk through the call stack, the task queue, and the microtask queue, and end on why setTimeout(fn, 0) and Promise.then() do not run in the order people expect.

A hypothetical answer for illustration: 'After a task finishes, the browser processes queued microtasks before moving on to another task and possible rendering. When a fulfilled Promise’s then handler and setTimeout(fn, 0) are scheduled in the same synchronous run, the then handler runs first. That does not mean an unresolved Promise always finishes before a timer.' Follow up by explaining when code after await resumes and how repeatedly adding microtasks can delay rendering.

Closures land better as usage than as definition. After the one-line definition (a function remembers the scope it was created in), explain why that keeps values alive, then describe a case you actually hit, such as an event handler that held a stale state value. Prepare this binding, the prototype chain, and shallow versus deep copies the same way. If a concept only lives in your head as a memorized line, test it against a follow-up first, such as whether let and const are hoisted.

Separate the browser's work from the framework's work. Explain DOM and CSSOM construction, layout, paint and compositing. Using transform rather than top or left can avoid layout work during an animation, and transform and opacity can be handled at compositing. Verify the actual rendering stages in DevTools rather than claiming these properties have no cost (web.dev guidance).

At the framework layer, React separates trigger, render, and commit. A component rendering does not mean the whole DOM is replaced, since only the changed parts are applied at commit, as the React documentation on render and commit explains. Reading that page once lets you answer 'is every re-render a performance problem' by separating the two layers.

For unnecessary renders, explain state placement, whether memoization helps, and how you measured the cost. Stable keys preserve list-item identity; they do not prevent re-renders by themselves. For state-library questions, connect the choice of library and the separation of server data from UI state to your own project.

Prepare both the metric definition and the conditions under which you measured it. LCP concerns the largest visible image or text block, INP measures interaction responsiveness, and CLS measures unexpected layout shifts. Check current definitions and thresholds in the Core Web Vitals guidance. Distinguish real-user data from lab measurements such as a Lighthouse run.

A hypothetical example for illustration: 'The LCP element on the product list page was the banner image. I preloaded it and switched to WebP, and Lighthouse on mobile showed LCP dropping from the four-second range to the two-second range. Preloading too many resources pushes others down the priority list, so I applied it only to the one image visible on first paint.' The structure is diagnosis, action, measurement, and what you gave up.

If you have no numbers, run Lighthouse or the DevTools Performance panel on your project this week. Even a clone project yields a before-and-after pair once you change font loading or an image format. Follow-ups usually arrive as trade-offs: what if code splitting sped up first paint but slowed navigation, or what breaks if every image is lazy-loaded. Prepare each fix as a pair of what it gained and what it cost.

Deep enough to explain why a layout resolves the way it does and how you would trace it when it does not. The recurring topics are the box model and box-sizing, what each position value is anchored to, stacking contexts, choosing between flex and grid, margin collapsing, and media queries versus container queries. Some teams add accessibility: semantic markup, focus order, color contrast.

For 'what do you do when z-index has no effect,' describing your check is more complete than raising the number: 'I look in DevTools for an ancestor that created a stacking context through transform, opacity, or filter.' The answer carries where you start looking when the screen does not match the intent.

On the browser side, prepare event bubbling and capturing, event delegation, and CORS. Do not stop CORS at 'the server did not send the right headers.' Continue to when a preflight request fires and, if you have actually done it, how you routed around it with a dev proxy. If the role is full-stack and questions may move into API design or databases, the backend developer interview guide covers those buckets.

The wording stays similar, but the expected focus tends to shift: fundamentals and reasons for entry level, problem-solving in production for one to three years, and design judgment plus what you gave up beyond that. Companies differ, so treat this as a tendency and let the posting's requirements set your emphasis.

At entry level, prepare why you chose each technology and how you got unstuck, rather than project scale. A clone project works if you can say what you implemented differently from the original and why. The developer resume writing guide helps make sure the cases you plan to tell match what the resume says.

One to three years in, prepare how you reproduced an incident and narrowed the cause, what you gave and received in code review, and the order in which you touched legacy code. Even when the team made the call, be able to explain how you understood it. Past four years, expect questions about how the state architecture was split, what criteria pulled something into a shared component, and how a performance budget was set, with the cost of each choice. At any level, code an AI tool produced still needs to be code you can explain.

Build answers in four slots: conclusion, mechanism, your case, trade-off. Then run each answer through the checklist below. It is an editorial suggestion from Preterview, not any company's scoring rubric.

• Did the first sentence state the conclusion, or did you start with background?
• Does the mechanism include at least one sentence on why it was designed that way?
• Is the case something you did yourself, and does it match your resume?
• If you gave a number, can you say which tool measured it and when?
• Did you name at least one cost alongside the gain?

Week one is for material. Pull five or six expected questions per type and fill a matching sheet with five columns: question, one-line conclusion, my case, likely follow-up, document to verify against. Rows that stay blank are your gaps. Measure performance numbers this week if you have none, and write a why-alternatives-result trio for every technology on your resume.

Week two is for speaking. Take one type per day and answer each question aloud several times. Concepts that felt solid on the page will stall out loud, and that is what you are looking for. Practicing alone means no follow-ups arrive, which is where Preterview's document-based mock interview and post-interview feedback let you repeat the same question and refine it. Check pricing and terms and a sample report for how it works, treat any AI's technical judgment as a reference, and verify facts against MDN and the framework docs. The developer mock interview guide has a fuller practice procedure.

The last two days are for polishing a handful of stalled answers, not for new concepts. Open the company's product in DevTools and note which framework it runs and how images load. Ten minutes there usually produces a question worth asking at the end.