Frontend developer interview questions

What they're checking

Whether you understand how asynchronous code actually runs, not just how to write it.

A strong answer covers

1. Explain that JavaScript runs one call stack, and that async work is handed off and queued for later.
2. Separate the queues, tasks such as setTimeout callbacks and microtasks such as promise callbacks.
3. Say that all pending microtasks run before the next task, so a resolved promise beats a setTimeout of zero.
4. Tie it to a real consequence, such as a long loop freezing the page because the stack never empties.

What they're checking

How well you understand loading and rendering, which is the basis of most performance work.

A strong answer covers

1. Cover the network steps briefly, DNS lookup, the connection and TLS handshake, then the HTTP request.
2. Explain parsing, the HTML into the DOM and the CSS into the CSSOM, and how they combine for layout and paint.
3. Point out what blocks rendering, such as scripts without defer or async and CSS in the head.
4. Finish with where caching and a CDN shorten the trip on the next visit.

What they're checking

Whether you can reason about rendering and avoid both wasted renders and premature optimisation.

A strong answer covers

1. Name the triggers, a change to the component's state, a re-render of its parent, or a change in a context it reads.
2. Explain that a re-render is not a DOM update, since React compares the result and changes only what differs.
3. Describe the tools for skipping work, memo, useMemo and useCallback, and the cost they add.
4. Say you would measure with the profiler before optimising, and give an example of a fix you made.

What they're checking

Whether you diagnose before fixing, and know the common causes of slow pages.

A strong answer covers

1. Measure first, with Lighthouse or the browser's performance panel, and decide which metric matters, such as load time or input delay.
2. Check the usual suspects, oversized images, large JavaScript bundles, render-blocking resources and slow API calls.
3. Fix the biggest cause first, for example by splitting code, lazy loading or caching responses.
4. Measure again to confirm the change helped, and add a check so the problem doesn't creep back.

What they're checking

Your judgement as much as your skill, and how you weigh users, design and technical constraints.

A strong answer covers

1. Describe what you built, who used it and the problem it solved.
2. Explain one hard part, such as complex state, accessibility or performance, and how you solved it.
3. Mention how you worked with design or backend to get it right.
4. Close with the result, ideally measured, such as faster completion times or fewer support tickets.