WordPress Developer interview questions

I keep WordPress core replaceable, put portable behavior in plugins, presentation in the theme, and business rules behind explicit domain services.

• Core is never patched because updates must remain vendor operations rather than merge projects.
• Plugins own post types, capabilities, APIs, and workflows that must survive a theme change.
• The theme consumes stable service interfaces and controls templates, styles, and editor presentation without becoming the data layer.

I treat hooks as adapters at the WordPress boundary and keep the actual use cases in ordinary PHP services.

• A small registrar wires named callbacks, while constructors do not silently register global behavior.
• Services accept typed inputs and return domain results, so PHPUnit tests do not need a full WordPress bootstrap.
• WordPress objects such as WP_Post are translated at the edge instead of leaking through every business rule.

I use an mu-plugin only for platform behavior that must load on every request and must not be disabled per site.

• Environment wiring, host integrations, and network-wide security controls fit that boundary better than optional product features.
• Because WordPress loads only top-level mu-plugin files, I use a tiny loader for namespaced Composer code.
• Mu-plugins bypass normal activation hooks and admin updates, so installation and schema work belongs in deployment tooling.

It turns WordPress core and third-party plugins into pinned dependencies and makes the repository describe a reproducible application.

• composer.lock is reviewed and deployed, while wp-content is separated into application code, managed packages, and writable uploads.
• Public web root isolation keeps configuration and vendor files outside the document root.
• Private or non-Composer plugins need an authenticated repository or artifact source, not a manual production upload.

I build one artifact and inject environment-specific configuration at runtime rather than branching application code by environment.

• Database credentials, salts, API keys, and host settings come from a secret manager or environment variables.
• wp-config.php composes immutable defaults with a small allowlist of environment overrides.
• Terraform or Kubernetes owns infrastructure values, while WordPress options remain content only when editors genuinely need to change them.

I make every web node disposable and move all request-shared state out of its local filesystem and memory.

• Nodes use the same immutable code artifact and connect to shared database, object-cache, and media services.
• Health checks avoid expensive WordPress rendering, and the load balancer terminates TLS with trusted proxy headers configured correctly.
• Sticky sessions are not the design because they hide state coupling and make failover uneven.

I store originals and generated sizes in shared object storage and serve them through a CDN.

• Upload interception must cover metadata generation, deletion, and regenerated image sizes, not just copy the original file.
• Local disks remain ephemeral caches, so no request depends on a file written by one pod.
• Private assets use authorization plus short-lived signed delivery URLs instead of a publicly readable uploads bucket.

No, I would first remove the need for affinity because WordPress authentication cookies can be validated by any node sharing the same salts and data stores.

• PHP sessions are avoided in plugins, or moved to Redis with explicit expiry if a legacy integration truly requires them.
• Nonces and user capabilities remain WordPress concerns and do not require load-balancer affinity.
• Eliminating stickiness gives predictable balancing and lets a node disappear without losing user state.

I disable request-driven WP-Cron and trigger due events from one controlled scheduler, then move heavy work to a durable queue.

• A Kubernetes CronJob or platform scheduler invokes WP-CLI on a fixed cadence without every web pod racing on traffic.
• Queue consumers claim jobs atomically and use idempotency keys because delivery can happen more than once.
• Scheduled callbacks remain short and record retryable work rather than processing a whole catalog inside one PHP request.

I choose per consumer contract: REST for stable resource operations and WPGraphQL when clients need flexible nested content graphs.

• REST has first-class core coverage, HTTP caching that is easy to reason about, and simpler write endpoints.
• WPGraphQL reduces over-fetching across posts, terms, and custom fields, but schema extensions and query-cost controls become platform responsibilities.
• I do not expose both casually because duplicate public contracts double authorization, caching, and compatibility work.

I model editorial meaning, not one front end's page markup, and publish that meaning through a versioned schema.

• Custom post types represent durable entities, taxonomies represent shared classification, and structured fields avoid opaque HTML blobs.
• Reusable blocks are acceptable when their attributes have a documented API shape and migration path.
• Presentation-specific choices stay optional so web, mobile, and syndication clients can render the same content differently.

I choose at route level based on freshness, personalization, and cacheability rather than declaring the whole site static or dynamic.

• Evergreen articles can use static generation with on-demand revalidation after publication.
• Highly personalized account pages use server rendering and bypass shared caches for user-specific data.
• Preview requests use draft credentials and a separate cache path so unpublished content never contaminates public output.

I use a short-lived signed preview handoff that establishes preview mode in the front end and fetches revisions as the current editor.

• WordPress verifies the editor's capability and signs the target post, revision, expiry, and return URL.
• The Next.js preview endpoint validates that signature before setting an HTTP-only preview cookie.
• Preview responses are private and uncached, and their API token cannot be reused for public browsing.

I match authentication to the client and keep authorization in WordPress capabilities at every data boundary.

• Same-origin editorial tools can use WordPress cookies and REST nonces because the browser already has a secure session.
• Server-to-server calls use a dedicated least-privilege user with a revocable application password, or scoped OAuth credentials stored only on the server.
• I avoid long-lived JWTs in browser storage because revocation, rotation, and cross-site scripting exposure become harder.

I invalidate by content dependency on committed publishing events, with TTL as a safety net rather than the primary mechanism.

• A post update purges its page, relevant archives, taxonomy pages, and API cache keys identified from a dependency map.
• WordPress sends a signed event after the write commits, and the front end deduplicates it before on-demand revalidation.
• Broad CDN purges are reserved for schema or navigation changes because they discard too much useful cache.

WordPress should own canonical content identity and editorial SEO data, while the front end owns their final HTML rendering.

• The API exposes canonical paths, robots directives, structured metadata, and redirect records as explicit fields.
• Next.js renders server-visible head tags and applies redirects at the edge before returning a page.
• A URL change creates a redirect from the old path and invalidates both paths so search engines never see conflicting canonicals.

They remove work at different layers, so I use all three with distinct ownership and invalidation rules.

• Redis or Memcached reuses database-derived objects but PHP and template rendering still run.
• Full-page cache skips WordPress for an anonymous HTML response, while the CDN serves that response near the visitor.
• A purge must target every affected layer because clearing Redis alone cannot refresh stale HTML at the edge.

I keep the public cache key small and explicit, then bypass shared HTML caching when content is truly user-specific.

• Locale, host, and a bounded device class may vary public pages when they change the response.
• Arbitrary cookies never enter the key because they destroy hit rate and can leak personalized output.
• Logged-in admin bars, carts, and account data use private fragments or uncached routes rather than one full-page variant per user.

I let one worker regenerate the value while other requests receive stale data or back off briefly.

• An atomic Redis lock has a short lease and a unique owner token so it cannot remain stuck or be released by another worker.
• Stale-while-revalidate keeps the page useful during regeneration instead of sending every miss to MySQL.
• Expirations receive jitter so related keys do not all become cold at the same second.

I use a custom table when the data has relational constraints or query patterns that the generic meta schema cannot serve predictably.

• Orders, reservations, or event logs often need typed columns, unique keys, and compound indexes.
• Posts and meta remain appropriate for editor-owned content that benefits from revisions, permissions, and core APIs.
• The custom table comes with a repository API, explicit schema versions, retention rules, and Multisite scope.