Frontend Engineer Interview Prep: Questions and a Mock Test

Performance questions in a frontend loop almost always route through Core Web Vitals, and the metric set changed recently enough that a lot of preparation material is wrong.

There are three. Largest Contentful Paint should occur within 2.5 seconds. Interaction to Next Paint should be 200 milliseconds or less. Cumulative Layout Shift should be 0.1 or less. All three are assessed at "the 75th percentile of page loads, segmented across mobile and desktop devices", which is worth saying out loud, because it means your median user's experience is not what is being measured.

The important currency detail: Interaction to Next Paint replaced First Input Delay. INP "was promoted in 2023 from experimental to pending status with the intent to eventually retire FID" and "became a stable Core Web Vital metric in 2024". Naming FID as a current Core Web Vital is a clean dating signal, and the difference is substantive rather than cosmetic. FID measured only the delay before the first interaction began processing, which flattered pages badly: an app could score well while every interaction after the first was slow. INP considers interactions across the whole page visit and includes the time to render the next frame, so it measures what the user actually feels.

The practical consequences follow. LCP is usually fixed by prioritising the hero resource, preloading it, avoiding lazy-loading it, and cutting render-blocking work. CLS is fixed by reserving space: explicit dimensions on media, space for anything injected late, and avoiding inserting content above what someone is already reading. INP is fixed by getting long tasks off the main thread, breaking up work, and not doing expensive rendering synchronously inside an event handler.

Almost every JavaScript round contains a question that reduces to the event loop, because it explains both correctness and performance.

The model to be able to state: JavaScript runs on one thread with a call stack. When the stack empties, the runtime drains the microtask queue completely, then takes one task from the macrotask queue, then repeats. Promise callbacks are microtasks; setTimeout callbacks, and events, are tasks. That ordering is what makes a promise resolved with no delay run before a setTimeout with zero delay, and it is why an endlessly self-scheduling microtask starves the page while an endlessly self-scheduling timeout does not.

The performance consequence is the one interviewers care about. Rendering happens between tasks, so any synchronous work longer than a frame budget blocks painting and delays interaction response. That is the mechanism behind a poor INP score, and it is why the standard advice is to break long tasks up, yield to the main thread, and move genuinely heavy computation to a worker.

Expect the closure and scoping questions too, because they still separate people. A var declaration inside a loop shares one binding, which is the classic reason a set of callbacks all see the final value, while let creates a fresh binding per iteration. And expect this: arrow functions take this lexically from where they are defined, ordinary functions take it from how they are called, which is why a method extracted from an object and passed as a callback loses its receiver.

Framework rounds test whether you can explain why something rendered, not whether you can recite an API.

The general model: a change to state produces a new description of the UI, the framework compares it against the previous description, and applies the minimum set of real DOM operations. Keys exist so that comparison can match elements across renders. Using an array index as a key is the classic bug, because inserting at the front shifts every index, so the framework matches the wrong old element to each new one and component state ends up attached to the wrong row. A stable identifier from the data is the fix.

Re-render questions follow. A component re-renders when its own state changes, when its parent re-renders, or when a context it consumes changes. It does not re-render because a variable it closes over changed, which is a common source of confusion. Memoisation helps only when the comparison is cheaper than the render, and passing a freshly created object or inline function as a prop defeats it, since a new reference fails the shallow comparison every time.

Accessibility belongs in this section rather than as an afterthought, because in a strong loop it is examined alongside markup. The current standard is WCAG 2.2, published in October 2023, organised around four principles, perceivable, operable, understandable and robust, with success criteria at three conformance levels, A, AA and AAA. WCAG 3 exists only as an early draft. In practice the interview questions are concrete: use semantic elements rather than a div with a click handler, ensure keyboard operability and visible focus, label form controls, and reach for ARIA only when no native element expresses the semantics.

Data fetching rounds are where interviewers find out whether you have shipped something real, because the failure modes are so specific.

The first is the incomplete state machine. Every fetch has at least four states, idle, loading, success and error, and a great many interfaces only implement two. Empty is a fifth that is distinct from loading and usually needs its own treatment, because a successful response with zero results is not an error and should not look like one.

The second is the race. Two requests fired for different queries can return out of order, so the slower earlier request overwrites the newer result. The answers are an abort controller cancelling the superseded request, or tracking the latest request identifier and discarding responses that are not current. Any candidate who has built a search-as-you-type interface will have met this.

The third is caching. A client cache needs a key that captures every input to the request, a staleness policy, and a story for invalidation after a mutation. Optimistic updates are the follow-up: applying the change locally before the server confirms makes the interface feel instant, and requires a rollback path when the request fails, which is the half candidates omit.

Beyond that, expect debouncing versus throttling as a distinction, retry with backoff for transient failures, and pagination, where cursor-based approaches avoid the duplicate and skipped rows that offset pagination produces when the underlying data changes between pages.

Security questions in a frontend loop concentrate on the boundaries the browser enforces and the ones it does not.

The same-origin policy is the foundation: scripts from one origin cannot read responses from another, where origin means scheme, host and port together. Cross-Origin Resource Sharing is the server opting to relax that, which is why CORS errors are so often misdiagnosed as client bugs when the fix is always on the server.

Cross-site scripting remains the most commonly examined class, and the correct framing is contextual output encoding rather than input sanitisation, because the same string is safe in an HTML body and dangerous in a JavaScript context or a URL. Content Security Policy is defence in depth on top, and dangerously setting inner HTML from user content is the direct route to the vulnerability.

Token storage is a favourite because there is no clean answer. Local storage is readable by any script on the page, so an XSS becomes a token theft. A cookie with HttpOnly is not readable by script, which removes that path, but cookies are attached automatically and therefore need SameSite and CSRF protection. The strong answer states the tradeoff rather than pretending one option is simply correct.

Worth knowing that in OWASP's 2025 Top 10, broken access control remains first and injection has moved to fifth, and that neither of those is a browser-side fix. A frontend that hides a button is not enforcing anything, because the client is under the user's control and every check that matters happens on the server.