Be honest about trade-offs: "Headless gives me a modern frontend stack and great performance. But I lose the block editor preview, most plugin frontends, and I now manage two deployments. I only recommend it when the frontend requirements genuinely outgrow PHP templating."
Headless WordPress uses WordPress as a CMS backend (via REST API or WPGraphQL) with a separate frontend framework (Next.js, Nuxt, Astro). Benefits: modern frontend tooling, better performance with static generation, freedom from PHP templating, and separation of concerns. Trade-offs: lose the block editor preview, lose plugin frontend features (forms, SEO plugins, page builders), increased complexity with two deployments, and higher development cost. Strong candidates discuss: when headless is justified (performance-critical sites, multi-channel content, team expertise in React/Vue) and when traditional WordPress is better (content-heavy sites relying on plugin ecosystems, smaller budgets, editorial UX).
Tests whether candidates follow trends thoughtfully. Those who push headless for every project are ignoring the cost. Those who dismiss it entirely are not keeping up. Best answers match the architecture to the project requirements and team capabilities.