What a front-end design question is really asking
Not which framework. State ownership, data fetching, transport, rendering strategy and what happens on a bad connection.
A front-end system design question is a distributed systems question where one of the nodes is a phone on a train. The axes are always the same: where state lives and who may change it, how data is fetched and how stale it may be, what transport carries updates, how and where things render, and what the experience is when the network is slow, flaky or absent.
Framework choice is the least interesting part and candidates spend the most time on it. Nobody is asking whether you know Redux. They are asking whether you noticed that two components need the same data at different freshnesses, that a mutation can fail after the UI has already moved on, and that a user can open the same document in two tabs.
A structure that fits in forty-five minutes: clarify the requirements and get one number out of them, sketch the data flow, choose the transport and justify it, then spend the remaining time on the two hardest states, the empty one and the failed one. Finishing the happy path and running out of time is the most common way to fail an interview you knew the material for.
You should now be able to
- Name the five axes a front-end design answer must cover
- Explain why the network is the interesting part of a client design
- Structure an answer under time pressure
Loading…