Lesson 1 of 8 · 55 min

What production FE ownership means

Reframe from ticket-shipper to surface owner: eight production dimensions, ownership receipt, failure at 100k users, interview format map, staff archetypes, and the senior scoring rubric for the whole track.

Ticket-shipper → surface owner

Shipping a ticket is not the job. Owning a surface area is: rendering model, state design, data contracts, performance budgets, accessibility, design-system health, client observability, and release safety. Mid–senior product FE loops grade you on whether you think like an owner of a product surface — not like a component implementer. This lesson is the map for the whole track.
Product companies (Stripe, Airbnb, Meta product FE, Pinterest, strong startups) run a predictable loop: live UI coding · JS/TS fundamentals · React/Next depth · frontend system design · machine coding / take-home · behavioural ownership. This track trains the craft rounds. L1 locks the ownership lens you carry into every later lesson.
A junior asks: “Does the feature work?” A senior asks: “What fails at 100k sessions, on a mid-range Android, with a screen reader, after a flaky deploy, when the API returns 503?” That second question is the bar. Interviewers listen for it in the first five minutes of system design and take-homes.

Ownership vs authorship

Authorship means you wrote the code. Ownership means you ship it safely, observe it in production, and can roll it back. Will Larson’s staff archetypes (staffeng.com) map cleanly: Tech Lead owns the project path and finishing; Architect owns the tech radar and patterns; Solver owns the hard incident; Right Hand owns executive leverage. Senior product FE often mixes Tech Lead + Architect on a surface: you set the contract and you land the runway.
  1. 01Code I own — I merge, I watch RUM, I get paged (or own the flag).
  2. 02Code I share — design-system primitives, shared hooks; I review and depreciate carefully.
  3. 03Code I observe — adjacent surfaces whose regressions hit my users; senior signal is moving into this circle before you are asked.

The production stack — eight dimensions

Every surface you own has eight dimensions. Treat them as a checklist you narrate out loud in interviews, not as a post-ship audit. When a system-design prompt lands, sketch these boxes before APIs.
  1. 01Rendering model — CSR / SSR / SSG / ISR / RSC / streaming / PPR: what ships HTML, what hydrates, where the client boundary is.
  2. 02State design — server cache · URL · local component · global UI. One source of truth per concern.
  3. 03Data contracts — fetch, cache keys, invalidation, optimistic updates, error/empty/loading UX.
  4. 04Performance — LCP / INP / CLS budgets at the 75th percentile of real users, not just lab Lighthouse.
  5. 05Accessibility — keyboard, focus, semantics, WCAG 2.2 AA as architecture, not a late checklist.
  6. 06Design system — tokens, composition primitives, deprecation, Storybook + visual/a11y gates.
  7. 07Observability — RUM (web-vitals), client errors, feature flags, FE error budget.
  8. 08Release — canary, rollback, on-call runbook, who owns the incident at 2am.

Definition of done — rewrite the PR checklist

In interviews, when they ask “how do you know this is ready to ship?”, answer with a concrete definition of done. Soft answers (“tests pass, PM signed off”) lose senior signal. The ownership receipt is the contract: risk on the left, observability on the right, one engineer who owns both.
text
1SURFACE DONE CHECKLIST (say this out loud)23[ ] Happy path + empty + loading + error + offline sketched4[ ] State bucket map: which data is server/URL/local/global5[ ] Perf: LCP element named; INP hot path known; CLS sources listed6[ ] A11y: keyboard path, focus order, SR labels, target size ≥24px7[ ] Observability: error boundary + RUM mark + flag kill-switch8[ ] Release: flag default, canary plan, rollback owner9[ ] Docs: Storybook or design-system note if pattern is reusable1011### Ownership receipt (PR template)12Risk surface: user-visible? bundle delta? new dep? hydration/a11y risk?13Observability: metric page_view vs LCP p75; alert error_rate >1% 5m14Rollback: revert commit / set FLAG_X=false15Tech debt created: TODO(issue#): ...

Production failure modes (what seniors prevent)

Ownership shows up as preventing classes of bugs, not hero-fixing one. Walk these in behavioural stories with: context → decision → tradeoff → outcome → system change (budget, flag, lint, runbook).
  1. 01Silent a11y regression in modal — no focus return contract. Fix: trap + ESC + restore in DS Dialog; Chromatic a11y story.
  2. 02Bundle bloat after refactor — no size limit per route. Fix: next-bundle-analyzer in CI; fail PR at +5kb on critical routes.
  3. 03Hydration drift after deploy — Date/random in render tree. Fix: deterministic first paint; client-only island for live clocks.
  4. 04Works-on-my-machine flag mismatch — .env.local vs prod env. Fix: single env loader + staging parity on previews.
  5. 05Tribal CSS — no tokens. Fix: design tokens + stylelint; ban raw hex in features.

Failure at 100k users — think in modes

Scale changes which bugs matter. At 100k monthly sessions you see: long-tail devices, partial network, race conditions, memory pressure from virtualized lists, and “works on my MBP” lies. Interviewers often ask: “what breaks when this goes viral?”
  1. 01Network — retries double traffic; missing AbortController piles in-flight requests; optimistic UI desyncs.
  2. 02Performance — main-thread work that was fine in lab fails INP on mid-tier phones; images without size attributes destroy CLS.
  3. 03State — multi-tab cart drift; stale React Query keys; duplicate websocket connections per remount.
  4. 04A11y — custom widgets without keyboard trap users; live regions announce spam on every token stream.
  5. 05Ops — no RUM → you debug from screenshots; no flag → bad deploy stays up for hours.

Spec ambiguity ladder

Ambiguity is not always bad. Tag it: positive (you are early; explore), neutral (RFC time; write options), negative (you guessed in code). Senior engineers name which side they are on in the PR description. Guessing silently is how you ship the wrong product surface.

Demo shape: customer feedback widget

Imagine a tiny “Was this helpful?” widget. Juniors build two buttons and a POST. Seniors walk the dimensions while coding:
tsx
1// Ownership walkthrough while building FeedbackWidget2// 1. Components: button group + optional comment + toast3// 2. A11y: role=group, labelled buttons, focus after submit4// 3. State: local UI only; submit via mutation (server cache not needed)5// 4. Errors: ErrorBoundary around widget; toast on 5xx; don't crash page6// 5. Perf: dynamic-import the comment form (rarely opened)7// 6. RUM: mark 'feedback_submit' duration; count success/fail8// 7. Release: feature flag feedback_v2; kill-switch if spam spikes910function FeedbackWidget({ pageId }: { pageId: string }) {11	const [status, setStatus] = useState<'idle'|'sending'|'done'|'err'>('idle')12	// submit with AbortController + timeout; never leave buttons unlabelled13}
The interview signal is not the 40 lines of JSX — it is naming each dimension unprompted, then implementing the ones that matter for the prompt. That habit transfers to chat UIs, dashboards, and PDPs later in this track.

Interview format map (this track)

Know what each round grades so you allocate prep correctly. Product FE loops reuse four craft formats; behavioural is separate.
  1. 01Live UI coding (45–60m) — decompose, state, edge cases, polish. Drill in L3 + L8 machine-coding patterns.
  2. 02JS/TS + React/Next battery (30–45m) — mental model, hooks, RSC, App Router. Deep dive in L2.
  3. 03FE system design (45–60m) — chat, feed, autocomplete, dashboard, collab, PDP. L6–L7 full skeletons.
  4. 04Machine coding / take-home — working component with a11y + tests. Capstone in L8.
  5. 05Perf / a11y folded questions — increasingly standalone. L4–L5.

Five interview failure modes (red / green)

GreatFrontEnd and staff FE playbooks converge on the same red flags. Learn the green replacement as a reflex.
text
1RED  → jump into code before requirements / NFRs2GREEN → 2–3 min scope: goals, users, constraints, NFRs, out-of-scope34RED  → design API/DB first, UI last5GREEN → product surface → rendering/state → then API shape that serves UI67RED  → ignore perf, a11y, security, resilience8GREEN → name NFRs early; revisit at the end with a budget910RED  → Redux + microfrontends for a 5-screen CRUD11GREEN → simplest architecture that meets constraints; justify extras1213RED  → wait for interviewer to drive every step14GREEN → own the agenda: clarify → design → dive deep → tradeoffs → risks

Senior scoring rubric (carry this track-wide)

Use this as a self-score card after every mock. Weights match what product companies signal at senior IC:
  1. 01Architecture & state (20%) — right rendering model; four state buckets; clear contracts.
  2. 02Performance & CWV (15%) — diagnose LCP/INP/CLS; fix with numbers, not vibes.
  3. 03TypeScript rigor (10%) — domain types, discriminated unions, narrow at boundaries.
  4. 04Accessibility (15%) — WCAG 2.2 criteria by name; keyboard + SR semantics.
  5. 05Testing strategy (10%) — pyramid; know what not to test.
  6. 06Data fetching (10%) — cache keys, invalidation, optimistic + cancel.
  7. 07Observability & ownership (10%) — RUM, flags, rollback, on-call.
  8. 08Communication & product sense (10%) — clarify, drive, tradeoff out loud.

Behavioural ownership — one beat

When they ask about a hard FE incident, structure: context → your decision → tradeoff → outcome → what you changed in the system (budget, flag, test, runbook). “I fixed the bug” is junior. “I added a CLS budget gate and an image size lint so the class of bug cannot ship” is senior.
Interview line worth memorising: “I own this surface end-to-end — if LCP regresses or keyboard users cannot complete the flow, that is my incident, not a QA surprise.”

Senior signals checklist (cohort rubric)

  1. 01I can describe my surface’s failure modes before someone asks.
  2. 02My PR description contains risk, telemetry, rollback, follow-ups.
  3. 03I open the next PR that fixes one of those follow-ups within a sprint.
  4. 04I write the RFC before the spike PR when ambiguity is neutral/negative.
  5. 05I have at least one owner-only metric (a dashboard panel) that I watch.
  6. 06I reframe a feature request into a job-to-be-done before scoping.
  7. 07I name a SLO before naming a UI control when stakes are high.
  8. 08I push back on PM with a budgeted alternative, not a naked “no”.

How this track is sequenced

L2 is the React + Next interview battery — dense Q&A, not create-next-app. L3 locks component architecture and the four state buckets. L4–L5 are CWV and a11y/design systems. L6–L7 are full FE system-design skeletons. L8 is AI-in-the-UI + machine coding + capstone mock.
How To Take Ownership — Will LarsonWill Larson / conference talkdocsStaff Engineer — Staff Archetypes (Will Larson)staffeng.comdocsweb-vitals — Core Web Vitals overviewweb.devdocsWCAG 2.2 RecommendationW3CdocsReact — Thinking in Reactreact.devdocsArchitecture Decision Records (templates)GitHub

Checkpoint

An interviewer asks: “How do you know a UI feature is done?” Which answer scores senior?

AUnit tests pass and the designer approved the Figma match.BHappy path works, NFRs (LCP/INP/CLS, a11y keyboard path, error UX) are met under a stated budget, and there is a flag/rollback owner.CThe ticket is closed in Jira and QA signed off.
Sign up free to answer and see why

Checkpoint

You are designing a feedback widget for a high-traffic docs site. What is the strongest ownership move for release safety?

AShip behind a feature flag with a kill-switch and a RUM mark on submit success/fail.BAdd three more unit tests for button labels.CUse Redux so the rating is global state.
Sign up free to answer and see why

Checkpoint

In a FE system design round you jump into API schemas before discussing rendering or state. What failure mode is that?

AOver-engineering — too many services.BOver-indexing on backend — neglecting FE architecture first.CNot driving the conversation.
Sign up free to answer and see why

Checkpoint

At ~100k sessions, which class of issue most often surprises teams that only tested on desktop Chrome?

AINP regressions on mid-tier mobile from main-thread work that felt fine in lab.BTypeScript compile errors in production.CCSS grid support gaps in modern evergreen browsers.
Sign up free to answer and see why

Checkpoint

Which statement best captures the senior FE job vs mid-level?

ASeniors write more complex React patterns; mids write simpler ones.BSeniors own a surface area (perf, a11y, state, observability, release); mids primarily deliver scoped tickets inside that system.CSeniors only do system design; mids only do coding rounds.
Sign up free to answer and see why

Can you narrate the eight production dimensions and a definition of done without notes?

New to itGetting thereConfident

Takeaways

  • Senior FE = own a surface: rendering, state, data, perf, a11y, design system, observability, release.
  • Definition of done includes budgets, a11y path, error UX, RUM, and rollback — not just green tests.
  • Scale surfaces network races, INP on real devices, multi-tab state, and ops gaps lab hides.
  • Five red flags: code-first, backend-first, ignore NFRs, over-engineer, don't drive.
  • Self-score with the eight-dimension rubric after every mock this track.

Next: React + Next.js interview battery — the mental model and 40+ questions that actually show up.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with EnzoSign up free