Frontend Interview Prep: The Three Rounds Nobody Practises

Frontend interview preparation has a specific trap: the loop is only partly made of algorithm questions, and the other part is not on any problem archive. You will be asked to build a component live, to explain how the browser got from a script tag to a painted pixel, and to reason about accessibility on a design nobody wrote a spec for.

What a frontend loop is actually made of

The column on the right is the whole article. Preparation is concentrated on the round with the smallest weight, and the two rounds that most often decide the outcome are the ones nobody rehearses.

The component round, done properly

You will be asked to build something small and interactive in thirty to forty minutes. What is actually assessed is not whether it works but which of the unglamorous concerns you reach for without prompting.

A typeahead that looks beautiful but drops the arrow keys, ignores a stale response arriving after a newer one, and has no empty state will lose to a plain one that handles all three. Say each of them out loud as you go, even if you run out of time to implement them. Stating "I would cancel the in-flight request here" earns most of the credit of doing it.

The fundamentals worth actually knowing

Frontend trivia is endless, so it helps to know which parts recur. These are the ones that come up repeatedly and reward real understanding rather than a memorised definition.

"There are only two hard things in Computer Science: cache invalidation and naming things."
- Phil Karlton, as popularised by Martin Fowler

Frontend engineering is largely those two things wearing different hats. Cache invalidation turns up as stale client state; naming turns up as component boundaries. Interviewers probe both, usually without calling them that.

Frontend system design, the round nobody prepares

"Design a news feed" as a frontend question is not about databases. It is about pagination strategy, optimistic updates, cache invalidation on the client, what you render on the server, how you handle a slow network, and what happens when the user has three tabs open.

Prepare it the same way as backend system design: pick four common products, and practise talking through the client architecture for each until the arc is comfortable. A feed, a chat client, a collaborative editor, and an analytics dashboard cover most of the space.

Where to practise each part

Use LeetCode for the algorithm round and stop there, because it does not cover the other three. Build the components in a real editor with a timer running. And do at least a few of them spoken, because narrating while writing JSX is harder than narrating while writing a function, and it is the exact skill the component round measures.