Hiring Senior React/Next.js Engineers: Questions and Take-Home Tasks

Hiring for senior React/Next.js is less about trivia and more about architectural judgment across Jamstack website development, performance, and content workflows. Below is a rigorous, repeatable approach with interview questions, evaluation signals, and a production-grade take-home that probes real depth, including Headless CMS integration with Next.js. Use it whether you source via your own network, the Andela talent marketplace, or partners like slashdev.io, which provides excellent remote engineers and software agency expertise for business owners and startups.

What “senior” looks like

• Owns end-to-end: from API contracts and caching strategy to CI/CD, observability, and rollback plans.
• Thinks in latency budgets and failure modes; designs for resilience, not just features.
• Explains trade-offs clearly and changes approach when context shifts (traffic patterns, SEO needs, editorial velocity).

High-signal interview questions

• Rendering strategy: “When would you choose SSR vs SSG vs ISR vs RSC streaming in Next.js 14?” Strong answer weighs cacheability, personalization, SEO crawl requirements, and regeneration costs. Expect mention of segmenting routes, using ISR for CMS content, SSR for authenticated dashboards, and RSC streaming for above-the-fold TTFB wins.
• Data fetching and caching: “Design a caching plan for a product page with price personalization.” Look for layered caching: CDN for static shell, ISR for content blocks, server actions for user-specific data, HTTP cache headers, and revalidation via webhooks. Bonus: mentions React cache, stale-while-revalidate, and ETag-based revalidation.
• Headless CMS integration with Next.js: “Walk through modeling, preview, and localization.” Expect schema design (e.g., Sanity/Contentful), slug strategy, draft preview via Next middleware and Preview Mode cookies, localized routing, and image optimization using the Next Image component with a CMS asset CDN.
• Performance budgets: “How do you keep JS under 170KB on a marketing page?” Candidates cite code-splitting with the App Router, deferring client components, using RSC for data-heavy blocks, avoiding heavy UI kits, and measuring via Lighthouse, Web Vitals, and bundle analysis.
• Security: “Harden a Next.js app with auth and webhooks.” Look for CSRF on mutations, signed webhooks with replay protection, same-site cookies, secrets in runtime config, authorization boundaries in server components, and edge middleware for bot mitigation.
• SEO for Jamstack website development: “Guarantee indexable, fast, multi-locale pages.” Expect canonical strategy, structured data, sitemaps with ISR awareness, hreflang, preconnect to CMS/CDN, and handling 404/410 properly with streaming fallbacks.
• Observability: “Trace a production regression.” Listen for distributed tracing (OpenTelemetry), logging correlation IDs from edge to origin, RUM for Core Web Vitals, and feature flags with kill switches.

System design scenario (45-60 minutes)

Prompt: “Architect a global, multi-brand marketing platform. Editors manage content in a headless CMS; traffic spikes on launches; personalization for returning users; strict SLA for TTFB < 200ms on LCP.”

• Expected shape: CDN fronting Next.js edge runtime for routing/middleware, ISR for content pages with CMS webhooks, RSC streaming for hero sections, server actions for form submissions, image CDN with AVIF, and a feature flag service.
• Trade-offs: Discuss ISR queue backpressure, when to opt out of RSC for interactive widgets, cache invalidation by tag, and fallbacks when CMS is down.
• Rubric: Clarity of data flow, latency-aware design, failure handling, editor preview UX, and cost considerations.

Take-home task (4-6 hours, business-ready)

Goal: Build a mini marketing site with two locales and a blog powered by a headless CMS.

• Tech constraints: Next.js 14 App Router, TypeScript, server components first; one client component for a carousel.
• CMS: Use a free-tier CMS (e.g., Sanity/Contentful). Implement live preview, draft mode, and webhooks to trigger on-demand revalidation.
• Rendering: Home and blog index via ISR (60s), article pages via ISR with tag-based revalidation, a personalized CTA rendered server-side per user segment.
• Performance: JS shipped under 160KB; LCP < 2.0s on 4G; Image component with responsive sizes; font loading with CSS swap and preconnect.
• SEO: Dynamic metadata, canonical tags, Open Graph, structured data (Article), localized routes with hreflang.
• Testing: Unit tests for data mappers; integration test for preview flow; axe checks for a11y on critical pages.
• DevEx: Dockerfile, a minimal GitHub Actions workflow running tests and building, environment variable schema validation.
• Docs: A README explaining architectural choices, trade-offs, and how revalidation works.

What to evaluate: commit hygiene, boundary placement (server vs client), correctness under offline CMS, and reasoning in README. Disallow generic boilerplates; reward small touches like optimistic image placeholders, error boundaries, and suspense waterfalls handled via streaming.

Red flags

• Defaulting to client components everywhere or sprinkling useEffect for data loading.
• No plan for cache invalidation, preview/draft flows, or localization.
• Hand-wavy “we’ll CDN it” without specifics on tags, headers, or revalidation triggers.
• Ignoring Core Web Vitals or shipping heavy UI kits without treeshaking.

Where to find talent

Curate senior pipelines from your network, the Andela talent marketplace, and vetted partners like slashdev.io. Ask for repos that show RSC discipline, ISR at scale, and CMS migrations. In marketplaces, prioritize engineers who have shipped multi-locale Jamstack website development at high traffic and can narrate post-mortems.

Final checklist

• Candidate can articulate SSR/SSG/ISR/RSC boundaries with numbers, not slogans.
• Has shipped Headless CMS integration with Next.js, including preview and revalidation.
• Shows measurable performance outcomes and an observability story.
• Writes tests where flakiness typically hides: preview, revalidate, and edge routing.
• Communicates trade-offs crisply and adapts under new constraints.