Most job posts for this role say “React developer, e-commerce experience preferred.” That gets you a candidate who can build a product grid and has never watched a cache invalidation take down pricing on a Friday. The engineer you actually want owns a storefront where every 100ms of latency and every stale price has a dollar value attached, and hiring them requires a scorecard, not a vibe check.
TL;DR
- This is a revenue-owning role, not a UI role. Score candidates on caching, revalidation, and checkout correctness before you score them on component architecture.
- The single best interview signal is a migration scar story: App Router adoption, RSC boundaries, or a caching bug that shipped wrong prices to real customers.
- Ask for Core Web Vitals tied to conversion, not Lighthouse scores. LCP and INP on real-user data (CrUX/RUM), on mobile, on the product detail page.
- Run a paid live debugging exercise (3-4 hours, $300-$600) instead of a greenfield take-home. Broken storefronts separate senior from mid faster than any system design chat.
- Approximate 2026 market rates: US senior $95-$150/hr contract or $165k-$215k base; LATAM senior $50-$85/hr through a nearshore partner.
- Peak traffic readiness is a hiring criterion, not a Q4 project. Ask what they did the week before Black Friday last year.
What this role actually owns
A Next.js e-commerce engineer sits on top of a commerce backend and owns everything the customer touches: catalog rendering, search and filtering, product detail pages, cart, and the handoff into checkout. In most 2026 setups that means a headless architecture: Shopify Storefront API, commercetools, Medusa, or BigCommerce providing data, with Next.js owning presentation, caching, and session state.
The load-bearing part of the job is not JSX. It is deciding what gets cached, for how long, and who invalidates it. A price change in the PIM needs to reach the storefront in seconds. A category page with 4,000 SKUs needs to render fast without hammering the commerce API. A cart must never show a stale total. Those three constraints fight each other, and the resolution is what you are hiring for.
The second load-bearing part is failure behavior. When the Storefront API returns 429s during a flash sale, does the page degrade gracefully or blank out? When a webhook for on-demand revalidation is dropped, how long does the wrong price stay live, and who finds out first: your monitoring or your customers?
The technical scorecard
Score each area 1-4. A senior hire should be a 3+ on at least six of these, and a 4 on caching and checkout.
| Area | What “strong” looks like |
|---|---|
| App Router vs Pages Router | Has migrated a production app incrementally, can name what broke: getServerSideProps patterns, layout re-renders, middleware auth, third-party libs without "use client" support |
| React Server Components | Draws the client/server boundary deliberately; keeps cart state client-side, catalog server-side; knows the cost of a "use client" at the wrong level |
| Streaming and Suspense | Streams the above-the-fold PDP shell and defers reviews, recommendations, and inventory badges |
| ISR / on-demand revalidation | Uses revalidateTag wired to commerce webhooks for price and stock; time-based only for slow-moving content |
| Cart and checkout state | Handles abandoned carts, out-of-stock at checkout, currency and tax edge cases, guest-to-logged-in cart merge, double-submit protection |
| Core Web Vitals | Talks in field data and revenue, not Lighthouse: “we cut mobile LCP from 3.4s to 1.9s, conversion moved 6%” |
| Image and font optimization | next/image with correct sizes and priority on the LCP hero; self-hosted fonts with next/font; knows why third-party tag managers wreck INP |
| CDN and caching layers | Can explain the full chain: browser to CDN to Next data cache to commerce API, and where a stale response can hide |
| Peak traffic | Has load-tested a storefront, has a rate-limit and fallback plan, has run a code freeze |
| Observability | RUM for Vitals, error tracking with release tagging, alerts on add-to-cart and checkout-start conversion rate, not just 500s |
Headless stack: what their background actually tells you
Stack experience is not interchangeable. What a candidate has worked on tells you which problems they have already solved.
| Stack | Best fit | What the engineer has learned | Watch out for |
|---|---|---|---|
| Shopify Hydrogen / Storefront API | DTC brands, fast launch, Shopify already in place | Cart API semantics, checkout handoff, Oxygen or Vercel deploys | May lean on Shopify defaults and be weak on custom caching |
| commercetools | Enterprise, complex B2B pricing, multi-market | API-first modeling, price tiers, custom projections | Slower ramp; expect a strong backend collaborator, not a solo owner |
| Medusa | Teams that want to self-host and customize deeply | Owning the backend too, plugin work, infra tradeoffs | Verify they can operate at scale, not just prototype |
| BigCommerce | Mid-market migrating off a monolith | Catalog APIs, GraphQL storefront, hybrid pages | Often coming from templated themes; probe RSC depth |
Do not filter on exact stack match. An engineer who ran ISR and cart correctness on commercetools will be productive on Shopify in three weeks. An engineer who only assembled Shopify theme sections will not go the other way.
Core Web Vitals are a revenue conversation
Ask any candidate for their LCP and INP numbers on the last storefront they owned, measured on real users on mobile, and what those numbers were before their work. Candidates who answer with a Lighthouse score from their laptop are telling you they never had accountability for the metric.
The mechanics they should reach for without prompting: server-render the product detail page above the fold, priority on the hero image with correct sizes and AVIF/WebP, next/font to kill the layout shift, defer analytics and personalization scripts that block the main thread, and stream the slow modules. INP is usually the harder one in commerce, and the usual culprit is a pile of third-party tags plus an over-eager client bundle.
Then push into tradeoffs. The strongest answers acknowledge that the fastest page is not always the highest-converting page (killing a personalization widget can improve LCP and cost revenue), and they describe how they measured it with an A/B test rather than assuming.
The interview loop
Four stages, roughly 4.5 hours of candidate time, plus a paid exercise.
1. Screen (30 min). One question: “Walk me through how a price change in your commerce backend reaches a customer’s browser.” Strong answers trace webhook to revalidateTag to CDN purge to client, name the latency at each hop, and mention what happens if a step fails. Weak answers say “we revalidate every 60 seconds” and stop.
2. Architecture (60 min). “Design catalog rendering for 50,000 SKUs with prices that change hourly and inventory that changes by the second.” Strong: separates cache lifetimes by data volatility: static product copy, ISR pricing, client-fetched inventory. Weak: caches everything the same way or SSRs everything and calls it correct.
3. Debugging conversation (45 min). “Add-to-cart succeeds but the cart badge shows the wrong count for about 10% of users.” Strong candidates ask about server vs client state, cookie/session handling, cache scoping on a per-user response, and multi-tab behavior. Weak candidates start guessing at React state bugs immediately.
4. Incident and ownership (45 min). “Tell me about the worst thing that broke on a storefront you owned.” You are listening for real financial stakes, a specific root cause, and what they changed structurally afterward, not a story where the CDN vendor is the villain.
The paid exercise
Skip the greenfield take-home. Give candidates a deliberately broken Next.js storefront: 3-4 hours, paid at $300-$600, or run it live in 90 minutes with screen sharing.
Seed it with four bugs: a "use client" at the layout level that ships the whole catalog to the browser, a hero image without priority or sizes tanking LCP, an ISR route with a 3600-second revalidate serving stale prices, and a cart mutation that double-fires under fast clicks. Ask for a short written note on what they fixed and what they would fix next with another day.
What you learn: prioritization order (a strong candidate fixes the stale price bug first, because it costs money), whether they measure before and after, and whether they can explain the caching bug in language a PM could follow.
Rates and where to hire
Approximate 2026 US market ranges, not guarantees. They move with location, stack, and how badly you need the seat filled.
| Level | US contract (hourly) | US full-time base | LATAM via nearshore partner (hourly) |
|---|---|---|---|
| Mid (3-5 yrs) | $70-$100 | $125k-$160k | $35-$55 |
| Senior (5-8 yrs) | $95-$150 | $165k-$215k | $50-$85 |
| Lead / storefront owner | $140-$190 | $200k-$250k+ | $75-$105 |
LATAM fits this role for a practical reason: storefront work is collaborative and synchronous. Vitals regressions, pricing bugs, and peak-traffic war rooms need the engineer in the same hours as your merchandising, marketing, and design people. A Mexico City, Bogota, or Buenos Aires engineer overlaps your full US workday. Brazil and Argentina in particular have deep Next.js and Shopify agency ecosystems, which means candidates who have shipped for demanding brands rather than internal tools.
Frequently Asked Questions
Do I need someone with e-commerce experience specifically, or will a strong Next.js generalist work?
Commerce experience matters, but the reason is narrower than most job posts assume. The transferable part is caching under correctness pressure: knowing that a stale response can charge someone the wrong price. A generalist from a high-traffic media or SaaS product with real caching scars can ramp quickly; a generalist from an internal dashboard cannot.
Should I hire someone who only knows Pages Router?
It is a yellow flag in 2026, not a red one, if they have deep caching and performance experience. What matters is whether they understand why the App Router model exists and can reason about server/client boundaries. Someone who has never thought about RSC and dismisses it as hype will slow your roadmap.
How do I test Core Web Vitals knowledge without a whiteboard?
Give them your actual PDP URL and 20 minutes with CrUX or PageSpeed field data. Ask what they would do first and what they would expect it to be worth. The answer reveals whether they think in field data and business impact or in lab scores.
What is a realistic ramp time for this role?
Two to four weeks to first meaningful production change on a mature storefront, longer if your commerce backend is heavily customized. Shorten it by pairing them on a small pricing or caching change in week one. That forces them through your entire deploy and invalidation chain immediately.
How many of these engineers do I need?
Most mid-market storefronts run well with one senior owner plus one or two mid-level engineers, backed by a backend or platform engineer for the commerce API side. With less than one true owner, a storefront drifts into a state where nobody can explain the caching.
Is peak-season readiness worth screening for in a spring hire?
Yes. Someone hired in March is the person on call in November. Ask specifically what they did in the two weeks before their last Black Friday: load tests, code freezes, fallback pages, rate-limit handling. If they cannot answer, they were downstream of whoever could.
