Frontend Architecture
Putting it together: multiple-choice review
Crux Cross-track multiple-choice synthesis: read a frontend symptom, locate the layer that actually owns the bug, and pick the fix that does not just mask it.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitEvery question here crosses two or three units. The skill the capstone tests is not recall of one layer — it is reading a symptom and naming the lowest layer that owns it, because that is where the durable fix lives.
Goal
Confirm you can trace a frontend symptom down the cascade — state shape, fetch graph, tokens, monorepo boundaries, splitting, pipeline — and reject fixes that optimise a layer above the real cause.
Quiz
Completed
A dashboard janks on every keystroke in its search box. A teammate files a ticket to code-split and lazy-load the charts. What is the senior read?
Heads-up Splitting decides what is in the initial bundle and when chunks arrive; it does not change which subscribers re-render. The chart still re-renders after its chunk loads, because the cause is where the keystroke state lives, not bundle size.
Heads-up Memoising one component can mute one symptom, but the global store still notifies every subscriber on every keystroke. You are patching a downstream node instead of fixing the state shape that set the blast radius.
Heads-up Build speed is unrelated to runtime re-renders. This optimises the cheapest layer (the pipeline) while the cause sits in the most expensive one (state shape).
Quiz
Completed
A product page renders a skeleton, then JS hydrates, then it fetches the user, then the cart, then recommendations — each waiting on the previous. LCP is 4.8 s. Which layer owns this, and what is the fix?
Heads-up A smaller bundle helps Time-to-Interactive, but it cannot remove serialised round-trips. Even with instant JS, three sequential client fetches still serialise; the waterfall, not the bundle, owns this LCP.
Heads-up A spinner changes perceived UX, not LCP, which measures the largest content paint. The cause is a sequential fetch graph on the critical path, and that is what must change.
Heads-up Normalisation shapes how data is stored and read, not when it arrives. The latency here is the sequential round-trips before any data exists; normalising afterwards changes nothing about LCP.
Quiz
Completed
Marketing asks for a rebrand: a new brand color plus a dark mode. The codebase has the brand hex hardcoded across ~300 components. What does this reveal, and what is the structural fix?
Heads-up Find-and-replace handles one rebrand and leaves you exactly as fragile for the next request and for dark mode, where the same hex means different things in different contexts. The point of a semantic layer is that meaning, not raw value, is referenced.
Heads-up Rewriting colors at build time still has no source of truth for what a color means; you cannot express text-danger versus surface-raised. The missing artifact is a semantic token layer, not a bundler transform.
Heads-up Per-page overrides multiply the inconsistency tokens are meant to remove and do not give dark mode a single switch. Centralised semantic tokens are the source of truth; scattered overrides are the anti-pattern.
Quiz
Completed
CI takes 15 minutes for a one-line change in one of 12 packages because everything imports one giant shared package. What attacks the root cause?
Heads-up Faster hardware rebuilds the whole dependency graph faster; it never stops rebuilding things that did not change. The 15 minutes come from a boundary problem — every leaf depends on the trunk — not from horsepower.
Heads-up Tree-shaking trims shipped bytes per bundle; it does not change which packages CI decides to rebuild. The build-time explosion is a dependency-graph problem upstream of any bundling step.
Heads-up Route chunks affect what the browser downloads at runtime, not what CI rebuilds. The cause is that the dependency graph forces a full rebuild on any change.
Quiz
Completed
You are handed a new frontend to review. In which order does a senior evaluate the layers, and why that order?
Heads-up Reading by file structure hides the dependency direction. You can finish admiring a clean folder tree and still miss that a state-shape decision is causing the jank — the layers cascade by failure cost, not by where files sit.
Heads-up The pipeline is the cheapest layer to fix later and the least likely to be the cause. Optimising bytes while the state shape is broken is waxing a car with a seized engine — the surface looks faster, the machine is not.
Heads-up Order is the whole lesson. A fix applied above the real cause is wasted work that also hides the bug, so reviewing in failure-cost order is what lets you fix the source instead of a symptom.
Quiz
Completed
A heavy charting library loads on first paint of every route even though most users never open the analytics tab, and a screen-reader user reports the date-picker inside it traps focus. Which two-layer fix is right?
Heads-up Deferring the load only delays when the buggy component mounts; the focus trap returns the moment a user opens the tab. Accessibility and code-splitting are orthogonal layers — each needs its own fix.
Heads-up Eager loading bloats the initial bundle for every user to no benefit, and it does nothing for the focus trap, which is a focus-management bug regardless of when the component loads.
Heads-up A package boundary changes build and ownership, not what ships to the browser on first paint or how focus behaves at runtime. You still need route-level splitting for the bundle and a focus fix for a11y.
Recap
The through-line across the track is one decision tree. Where state lives sets the re-render blast radius; the fetch graph owns LCP; tokens decide whether a rebrand is a value swap or a file hunt; monorepo boundaries are the build-time multiplier; splitting and the pipeline are the cheapest layers. Every question above is the same move — read the symptom, drop to the lowest layer that owns it, and reject any fix that optimises a layer above the cause.