Senior Frontend Engineer Guide for Tech Companies (2026)

What senior frontend engineers actually do

The day-to-day at a FAANG-tier or SaaS-tier senior frontend role:

• 40-50% feature delivery (still). Senior engineers ship code daily — but the code is typically the load-bearing piece of a multi-engineer feature: the framework migration scaffolding, the design-system primitive every team uses, the perf-critical hot path. Pull-request review is heavier than at mid because you're now the architecture-level reviewer for your team.
• 20-30% architecture and RFCs. You're the engineer who writes the RFC when a major change is proposed (App Router migration, design-system v2, the React 19 upgrade). You read RFCs from peer teams and contribute substantive feedback. The RFC craft compounds — Lee Robinson's writing at leerob.io is the public exemplar.
• 15-20% mentoring. 1:1s with juniors on your team (informal, weekly or biweekly). Code review is a teaching surface, not a gatekeeping surface. You explicitly identify a mid-level engineer to invest in for senior promotion, and a junior to invest in for mid promotion, and structure your feedback around their growth areas.
• 10-15% cross-functional. You're the frontend voice in PRD reviews, design-review meetings, and platform-level conversations about Core Web Vitals, accessibility, and frontend infrastructure. You don't ask permission to push back on a spec that will tank performance — you state the trade-off in PM-readable language and propose alternatives.

Five concrete capabilities that show up at senior+ in production:

1. Architecture-level decisions for a feature area. You can defend Server Components vs client components, RSC vs API-routes-with-TanStack-Query, server-rendered vs CSR-with-skeleton in front of staff engineers without faltering.
2. Core Web Vitals ownership. Your surfaces have named LCP / INP / CLS budgets. You can profile and fix regressions in production using Performance Observer / web-vitals / RUM data.
3. Accessibility leadership. Your team ships zero axe-core violations on PR. Your custom components have correct ARIA. You can talk to a screen-reader user (or run NVDA / VoiceOver yourself) and improve the experience.
4. TypeScript advanced patterns. Mapped types, conditional types, the satisfies operator, generic constraints with infer, branded types. You write libraries with strong type ergonomics, not just consume them.
5. Staff-promotion-trajectory artifacts. A published RFC, a multi-team migration completed under your leadership, a measurable platform-level win.

Real worked scenario: senior frontend migrates a SaaS app from Pages Router to App Router over a quarter

A worked example — a senior frontend engineer at a SaaS-tier company drives the migration of a 200,000-line Next.js codebase from the Pages Router (legacy) to the App Router (modern, with Server Components by default) over Q2 2026. The PRD framing: 'cut p75 LCP on the dashboard route from 4.2s to under 2.5s; cut bundle size by 30%; improve INP on heavy interactivity surfaces.'

• Weeks 1-2: Plan and RFC. Write the RFC. Three-stage migration plan: (1) move shared layouts and data-fetching primitives to App Router compatible patterns, (2) migrate routes one at a time starting with the highest-LCP routes, (3) delete the Pages Router. Identify risks: the existing global Redux store doesn't map cleanly to RSC; the third-party analytics script has a top-of-document requirement that conflicts with streaming. Get sign-off from staff frontend and the platform team. Lee Robinson's App Router Migration Guide at nextjs.org/docs/app/guides/migrating/app-router-migration is the reference.
• Weeks 3-5: Foundation. Set up shared layouts in app/. Migrate the auth flow to Server Components + Server Actions (huge win — the auth bundle drops by 40 KB on the client). Stand up a typed Server Actions wrapper using zod schemas and the satisfies operator. Two senior frontend engineers from peer teams pull-request review the foundation work; it lands clean.
• Weeks 6-8: First high-LCP route migration. The dashboard route (highest-traffic, highest-LCP). Move data fetching to Server Components with Suspense streaming. Identify and fix three blocking dependencies: a chart library that requires the window object (move to client island only on the chart card), a feature-flag check that was running on every render (move to a Server Component env-var read), a third-party tooltip library that ships 80 KB (replace with Radix UI Tooltip, 8 KB). p75 LCP drops from 4.2s to 2.1s in production.
• Weeks 9-11: Cross-team migration. Pair with three peer teams to migrate their dashboard sub-routes. Run a weekly office-hour to unblock other engineers. Two junior engineers ship their first App Router routes under your review. INP improves on heavy-interactivity routes from 240ms to 140ms p75 because you've moved heavy work into Server Components and used React 19's useDeferredValue on the remaining client-side filtering.
• Weeks 12-13: Cleanup and writeup. Delete the Pages Router. Bundle size drops 32% because shared client-only utilities are no longer pulled into every route. Write a public-facing engineering-blog post on the migration; the post becomes a hiring asset for the team. The migration retro names what would have failed without senior-level architecture: the Redux-to-Server-Components transition (would have stalled if you hadn't proposed the typed Server Actions wrapper instead of force-fitting Redux into RSC).

This is canonical staff-promotion-trajectory work: cross-team scope, measurable platform-level outcomes, mentorship on the way, public artifact at the end. The next promotion cycle reads this scenario and considers it strong staff-promotion evidence; the engineer's manager packages the evidence and routes it to the calibration committee.

Senior-level React: the patterns that separate seniors from mids

Three patterns that show up in senior frontend code and not in mid-level code:

1. Discriminated unions on async state with proper TypeScript typing. Mid-level code often has { data, loading, error } all optional; senior code uses discriminated unions so invalid states are unreachable:

type AsyncResult<T, E = Error> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; error: E };

function renderResult<T, E>(
  result: AsyncResult<T, E>,
  view: {
    idle: () => React.ReactNode;
    loading: () => React.ReactNode;
    success: (data: T) => React.ReactNode;
    error: (error: E) => React.ReactNode;
  },
): React.ReactNode {
  switch (result.status) {
    case "idle":
      return view.idle();
    case "loading":
      return view.loading();
    case "success":
      return view.success(result.data);
    case "error":
      return view.error(result.error);
  }
}

2. A custom hook that composes Suspense + use() correctly. Senior frontend code uses Suspense for in-render data fetching where the component lifecycle benefits, not as a wrapper over useEffect-with-fetch:

import { use, type Usable } from "react";

/**
 * Resource cache keyed by stable cache key. The promise itself is the
 * suspense thenable; React 19+ unwraps it via use() inside a Suspense
 * boundary. This works because we never recreate the promise for the
 * same key, so the component reads a stable Usable across renders.
 */
const resourceCache = new Map<string, Promise<unknown>>();

export function getResource<T>(
  key: string,
  loader: () => Promise<T>,
): Usable<T> {
  let promise = resourceCache.get(key) as Promise<T> | undefined;
  if (!promise) {
    promise = loader();
    resourceCache.set(key, promise);
  }
  return promise;
}

export function useResource<T>(
  key: string,
  loader: () => Promise<T>,
): T {
  return use(getResource(key, loader));
}

3. Bundle-size-aware code splitting. Senior frontend engineers know which imports are large and route-split them. next/dynamic with ssr: false for client-only chart libraries; React.lazy with Suspense fallback for heavy panels. They name bundle-size budgets in the team's success criteria: the new admin route must add no more than 15 KB gzipped to the dashboard bundle. Addy Osmani's JavaScript bundle audits writing at addyosmani.com is the reference.

Compensation: the real bands at senior

Total comp at senior FAANG-tier and SaaS-tier in 2026 (US, per levels.fyi):

SaaS-tier compensation has converged with FAANG at senior in 2026. Vercel's frontend roles specifically pay at the upper end given Next.js stewardship; Linear pays slightly below FAANG cash but offers high-quality private-company equity that has historically appreciated. AI-labs hiring frontend specialists (Anthropic, OpenAI) sit materially above FAANG on heavy private-company equity.