Senior Frontend Software Engineer

Senior Front End Software Engineer

When to Use

• Complex React/Next.js features, layouts, or design-system components
• Front-end architecture decisions (state, composition, RSC vs client)
• Performance work: bundle size, waterfalls, Core Web Vitals
• Accessibility fixes and WCAG-oriented implementation
• Senior front-end PR review (correctness, a11y, maintainability)

When NOT to Use

• End-to-end feature needing new API and schema → fullstack-software-engineer or senior-fullstack-developer
• Pure visual/design direction without code → design review workflows
• Infrastructure, deploy, or monitoring setup → devops
• Multi-service backend design → senior-software-engineer

Related skills

Core Workflows

1. Component and feature design

1. Map user flows to routes and layout boundaries 2. Split server (data fetch, static) vs client (interaction) deliberately 3. Define component API: props, slots, variants, controlled vs uncontrolled 4. Plan states: loading, empty, error, partial success 5. Align with design tokens; avoid one-off magic values

See `references/component_architecture.md` for composition patterns.

2. State and data fetching

Avoid prop drilling through deep trees—compose or use context at stable boundaries.

See `references/state_data_fetching.md` for waterfalls and cache invalidation.

3. Styling and design system

• Use design tokens (spacing, color, typography) from system
• Variants via cva or equivalent; document in Storybook if present
• Responsive and dark mode from tokens, not duplicated rules
• Do not fork components without team agreement

See `references/design_system.md` for extension rules.

4. Accessibility and quality

• Semantic HTML first; ARIA only when needed
• Keyboard: focus order, focus visible, escape to close
• Labels on every input; announce dynamic updates thoughtfully
• Target WCAG 2.1 AA for customer-facing flows

See `references/a11y_performance.md` for checklist and metrics.

5. Performance

• Measure before optimizing (Lighthouse, Web Vitals, bundle analyzer)
• Fix waterfalls: parallelize fetches, hoist server data
• Code-split routes and heavy widgets
• Images: dimensions, modern formats, priority for LCP

See `references/a11y_performance.md` for INP and CLS tactics.

6. Testing and review

PR review: a11y, edge states, unnecessary client boundaries, bundle impact, test gaps.

See `references/frontend_code_review.md` for review rubric.

When to load references

• Components and composition → references/component_architecture.md
• State and fetching → references/state_data_fetching.md
• Design system → references/design_system.md
• A11y and performance → references/a11y_performance.md
• Code review → references/frontend_code_review.md

Accessibility and performance

Table of contents

1. A11y checklist 2. Core Web Vitals

A11y checklist

• [ ] Heading hierarchy logical
• [ ] Interactive elements keyboard reachable
• [ ] Focus visible; no focus trap without escape
• [ ] Form inputs have associated labels
• [ ] Color contrast AA for text and controls
• [ ] Images have alt text (decorative: alt="")
• [ ] Live regions for toasts/async status when needed

Core Web Vitals

Run Lighthouse on representative pages before claiming done.

Component architecture

Table of contents

1. Composition 2. Server vs client 3. Anti-patterns

Composition

• Prefer compound components (Tabs, Tabs.List, Tabs.Panel) for flexible UIs
• Container/presentational split when data loading differs from display
• Extract after second duplication, not before

Server vs client

Mark client files with "use client" at top; keep boundary as low as possible.

Anti-patterns

• God components >300 lines without extraction plan
• useEffect for data that could load on server
• Copy-paste variants instead of props/variants
• Inline styles for design-system-covered tokens

Design system

Table of contents

1. Token usage 2. Extending components 3. Storybook

Token usage

• Colors, spacing, radius, font from CSS variables or theme
• No hardcoded hex in feature code unless token missing—add token first
• Dark mode via prefers-color-scheme or class strategy consistent with app

Extending components

1. Check if existing primitive supports variant 2. Propose token or variant in design system PR if reusable 3. Local wrapper only for one-off if approved

Storybook

Document: default, all variants, disabled, error, loading, keyboard focus story.

Front-end code review

Table of contents

1. Review rubric 2. Severity guide

Review rubric

Severity guide

State and data fetching

Table of contents

1. Waterfalls 2. Mutations 3. Cache invalidation

Waterfalls

Bad: layout fetches → page fetches → child fetches serially on client.

Better: parallel Promise.all on server; pass data as props; or single query with includes.

Mutations

• Prefer Server Actions for simple forms on Next.js
• Use API route + client mutation when complex client logic required
• Optimistic updates: snapshot previous state; rollback on error

Cache invalidation

After mutation:

• Invalidate query keys affected
• Or revalidatePath / revalidateTag for RSC caches
• Document which paths must refresh