A design system declares breakpoints at 640px, 1024px and 1280px. Which viewport widths would you capture visual baselines at, and why is a width just either side of a breakpoint worth more than one in the middle of a range?
answer
- breakpoints are the only meaningful widths
- layout changes are discontinuous
- the middle of a range re-tests one branch
- capture the pair, not a nearby width
- min-width matches at exactly the value
basics
~20 sDerive the widths from the declared breakpoints: the narrowest supported width, then one just below and one at each boundary. Layout bugs cluster where the layout switches, so a width in the middle of a range only re-confirms a branch a neighbouring width already covered.
solid answer
~40 sI take the breakpoints as given and pick widths from them rather than from device names. That means the narrowest width we support, then boundary pairs — something like 639 and 640, 1023 and 1024 — and one width above the largest breakpoint. Boundaries are worth more because that is where the layout changes: the branch that only exists in a narrow band, the grid that wraps to an awkward orphan just before it collapses, the nav that overflows in the last few pixels before it becomes a menu. A width in the middle of a range renders the same branch as its neighbours, so it mostly reconfirms coverage you already have. The pair also pins the boundary semantics: a `min-width: 1024px` query applies at exactly 1024, and off-by-one breakpoint bugs are common.
go deeper
Be able to say that capture widths should come from the project's declared breakpoints rather than from device names, and name at least one boundary pair.
Explain why layout defects cluster at discontinuities, and show you know a min-width query matches at exactly its value so both branches can apply at once.
Show restraint about cost: boundary pairs double the width axis, so argue for applying them to a representative tier and one width per range elsewhere.
Make the capture-width set a shared, versioned artifact of the design system so every team's suite samples the same widths and a breakpoint change updates the matrix in one place.
## Start from the breakpoints, not from devices The design system has already decided where the layout changes. Those declared values — here 640, 1024 and 1280 — are the only widths in the whole continuum that mean anything to the CSS, so they are the natural source for the test matrix. Choosing widths from device names instead ("phone", "tablet", "laptop") samples the continuum arbitrarily: two device presets can land in the same range and cover the identical branch, while a branch that only exists between two of them goes uncovered and nobody notices, because the suite looks like it tests three sizes. ## Why boundaries carry the defects A responsive layout is piecewise. Inside a range, the rendering changes continuously — boxes get a little wider, whitespace grows — and continuous change rarely breaks. At a boundary the rendering changes discontinuously: rules switch on and off, a container's `display` flips, elements appear and disappear. Discontinuities are where the bugs are, and they are also where the layout is most stressed, because just below a breakpoint the wide branch is being squeezed into the least room it will ever have. The recurring defect classes are all boundary-shaped: - A horizontal nav that still fits at 700px but overflows at 645px, a few pixels before the mobile menu takes over. - A three-column grid whose last row has one orphan item at exactly one width band. - A branch that exists only between two breakpoints and that nobody has looked at since it was written. - An off-by-one in the breakpoint itself: `max-width: 640px` paired with `min-width: 640px` makes both branches apply at exactly 640, and `max-width: 639px` paired with `min-width: 640px` leaves fractional widths between them unhandled. A baseline captured at 800px cannot see any of that. It renders the same branch as 900px and 1000px, so it is a third confirmation of coverage you already had. ## A concrete selection For breakpoints at 640, 1024 and 1280, a defensible set is: - **320 or 360** — the narrowest width you claim to support. This is the tightest box the layout ever occupies, so text truncation, long unbreakable strings and horizontal overflow surface here first. - **639 and 640** — the last width of the small branch and the first width of the next one. - **1023 and 1024** — the same pair at the next boundary. - **1440 or similar** — one width comfortably above the largest breakpoint, to check the widest branch and, if the layout has no `max-width`, that it does not stretch into unreadable line lengths. That is six or seven widths, which is already a lot: recall that each one multiplies the whole suite. In practice most teams keep the boundary pairs only for a small tier of representative pages and run one width per range everywhere else. ## Boundary semantics are inclusive, and units matter `@media (min-width: 1024px)` matches at exactly 1024px, and `@media (max-width: 1024px)` also matches at exactly 1024px — writing both is a genuine bug you can only see by capturing at the boundary value itself, not one pixel away. That is the reason to capture the pair rather than a single "near the breakpoint" width. If the breakpoints are declared in `rem` or `em` rather than `px`, convert before choosing viewport widths: in a media query those units resolve against the browser's initial font size, not against the root element's `font-size`, so a breakpoint written as `40em` is 640px at a 16px default and moves if the user has changed their browser's default text size. Capture at the converted pixel width, and remember that the breakpoint is not at a fixed pixel value for every user. ## What this does not decide This is a rule for choosing which widths get a baseline, given breakpoints that already exist. It says nothing about whether those breakpoint values are the right ones, and it does not replace the judgement of which pages deserve the full set of widths at all — a page with no responsive behaviour needs one width, however many the system declares.
- If the design system's breakpoints are written in em rather than px, how do you pick the capture widths?Convert them first: in a media query, em and rem resolve against the browser's initial font size rather than the root element's font-size, so 40em is 640px at a 16px default. Capture at the converted pixel widths, and note that the boundary genuinely moves for a user who has raised their default text size — which is a coverage gap worth knowing about rather than pretending away.
- Do you capture boundary pairs for every page in the suite?No — the pairs roughly double the width axis, and the width axis multiplies everything else. I keep boundary pairs for a small tier of pages and components chosen because between them they exercise every layout branch, and give the long tail one width per range. That keeps the discontinuities covered without paying for them 40 times over.
saying these in an interview costs you the question
- Picks viewport widths from device names instead of declared breakpoints
- Captures only in the middle of each range, missing every discontinuity
- Assumes min-width and max-width at the same value cannot both apply
- Treats em-based breakpoints as fixed pixel widths
- Adds a width per breakpoint without accounting for the multiplied cost