Hiring senior React/Next.js engineers: interviews and take-home tasks

Great senior React/Next.js hires elevate product velocity, Core Web Vitals, and SEO-impacting architecture. This guide gives high-signal interview questions and a practical take-home that simulates enterprise realities-data, scale, security, and cross-team collaboration-so you can hire confidently without guesswork.

What “senior” really means

• Designs resilient systems across client, server, and infra, not just components.
• Understands trade-offs: speed vs maintainability, DX vs TCO, caching vs staleness.
• Makes performance and accessibility first-class requirements, not afterthoughts.
• Communicates in PRs and RFCs; aligns with product, marketing, and SEO goals.
• Guides full-cycle product engineering, from discovery to post-launch observability.

High-signal interview questions (with what to listen for)

• Explain how you choose between server components and client components in Next.js. – Look for understanding of hydration costs, interactivity boundaries, and streaming.
• How do you make SSR pages fast under load? – Expect answers about caching strategies (ISR, stale-while-revalidate), CDN headers, and critical CSS.
• Describe a time you restructured a React state model to remove an entire class of bugs. – Seek normalized state, reducer patterns, and XState or event-driven reasoning.
• What is your strategy for data fetching in Next.js 14 route handlers vs RSC? – Listen for colocation, idempotent handlers, and cache tags for revalidation.
• How do you protect API routes against abuse? – Rate limiting, circuit breakers, input validation with Zod, and OWASP-aware threat modeling.
• Tell me how you’d debug a hydration mismatch in production. – Repro with minimal fixture, console markers, React Profiler, and build-time diffs.
• Discuss SEO for internationalized sites on Next.js. – Dynamic metadata, canonical tags, hreflang, sitemaps, edge redirects, and structured data.
• Which metrics prove UI performance is healthy? – LCP, INP, CLS, TTFB, plus tracing to specific components and queries.
• How do you structure a design system to prevent prop explosion? – Composition, controlled vs uncontrolled, headless primitives, and accessibility contracts.
• Walk through migrating from REST to GraphQL or tRPC. – Strong typing, batching, caching, error envelopes, and observability.
• Describe a failure post-mortem you led. – Blameless analysis, action items, rollback plan, and monitoring improvements.
• How do PostgreSQL and MySQL development choices affect Next.js architecture? – Transaction patterns, pagination, search, and read/write splitting.

Systems thinking with PostgreSQL and MySQL development

Senior engineers must reason about data under product constraints. Probe modeling decisions that impact UX, cost, and analytics. Ask for specific indexing, migration, and consistency strategies aligned with feature velocity.

• Given a high-traffic product catalog, design pagination with stable ordering, composite indexes, and cursor-based APIs; compare approaches in PostgreSQL vs MySQL.
• Explain eventual consistency strategies for counters and likes; weigh materialized views, triggers, and background jobs; justify when to use read replicas.
• Detail schema evolution: zero-downtime migrations, backfills, feature flags, and shared contracts with TypeScript/Prisma.

Take-home task: build a production-grade feature

Scope a 4-6 hour challenge that mirrors real work. Provide a lightweight Figma, API outline, and analytics goals. The aim is judgment under constraints, not pixel-perfection.

• Feature: “Campaign Landing Manager” in Next.js. Create, preview, and publish landing pages with markdown content, image assets, and SEO settings.
• Requirements:
  • Next.js 14 app router with RSC for read paths; client components for editor.
  • Data: PostgreSQL or MySQL via Prisma. Model Campaign, Variant, Asset. Include a migration.
  • Publishing: ISR for public pages with cache tags; manual revalidation on publish.
  • Auth: Email magic link or OAuth; role-based access for editors vs viewers.
  • Analytics: Capture LCP and INP on published pages; expose a simple dashboard.
  • Quality: TypeScript strict, Zod validation, tests (unit + one Playwright flow), basic a11y.
  • Ops: Dockerfile, seed script, .env.example, and minimal README with runbook.

Acceptance criteria and scoring rubric

• Architecture (30%): Clear RSC boundaries, predictable data flow, defensible caching. Trade-offs documented.
• Data correctness (20%): Sound schema, indexes, safe migrations, transactional integrity for publish.
• Performance (15%): Sensible prefetching, image optimization, stable ISR cadence, no obvious hydration thrash.
• Security (10%): AuthZ checks on all mutations, input validation, secret handling, rate limiting hints.
• DX and tests (15%): Readable code, scripts, Jest/Playwright coverage of core path, smoke a11y checks.
• Product polish (10%): Editor ergonomics, SEO metadata, shareable preview links, helpful empty states.

Advanced variants and red flags

• Variants: Add AB testing with sticky assignments; implement cursor pagination on analytics; introduce full-text search with Postgres trigram or MySQL InnoDB FTS.
• Scale twist: Edge cache for public pages with surrogate keys; demonstrate cache busting on variant edits.
• Red flags: Overuse of client components, global mutable state, ad-hoc SQL without indices, missing rollback, no thought about Core Web Vitals.

Process, partners, and fair offers

Run a crisp process: one technical screen, the focused take-home, a systems review, then a team loop with product and marketing. Share decision criteria upfront and keep Fair and transparent engineering rates aligned with market data. For surge needs or fractional leadership, consider slashdev.io-excellent remote engineers and software agency expertise that plug into your roadmap. Whether scaling a greenfield app or modernizing a platform, insist on full-cycle product engineering that connects discovery, delivery, and measurable outcomes.