4) Technical and professional questions (the ones that decide the offer)
Here’s the truth: US interviewers rarely care if you can recite every WordPress function. They care if you can make good engineering calls under real constraints—traffic, SEO, editors, security, and deadlines.
Q: How do you decide between building a custom block vs using ACF blocks vs a page builder?
Why they ask it: They’re testing Gutenberg maturity and maintainability thinking.
Answer framework: Decision matrix (editor UX, performance, portability, long-term maintenance).
Example answer: “If the content team needs flexible layouts but we still want clean markup and performance, I prefer native custom blocks with block.json and server-side rendering when needed. If the team is small and needs speed, ACF blocks can be a pragmatic middle ground—still structured, but faster to build. I avoid page builders for core templates when performance and portability matter, unless the business explicitly accepts the tradeoff and we isolate it to specific landing pages.”
Common mistake: Treating it as a religious debate instead of a context decision.
Q: Walk me through how you’d build a custom post type and expose it via the REST API.
Why they ask it: They want to see if you can build structured content for modern front-ends.
Answer framework: Build steps + security check (register, capabilities, fields, permissions).
Example answer: “I’d register the CPT with clear labels, supports, and rewrite rules, and I’d define capabilities so we don’t give editors more power than needed. Then I’d set show_in_rest to true and define a REST base if we want clean endpoints. For custom fields, I’d register meta with register_post_meta and set show_in_rest with proper schema and sanitization. Finally, I’d confirm permissions callbacks so private data doesn’t leak through the API.”
Common mistake: Exposing everything in REST without capability checks or sanitization.
Q: As a WordPress Theme Developer, how do you structure a theme for performance and maintainability?
Why they ask it: They’re checking whether you can build themes that survive multiple hands.
Answer framework: “Separation + pipeline” (templates, components, assets, standards).
Example answer: “I keep templates thin and push logic into reusable template parts or helper functions. I use a predictable naming convention, enqueue assets properly, and avoid loading global scripts on every page. I also set up a build pipeline for CSS/JS, linting, and formatting so the theme doesn’t degrade over time. And I document editor-facing patterns—block styles, reusable blocks, and what not to do—because editors are part of the system.”
Common mistake: Hardcoding everything in page templates and calling it ‘custom.’
Q: As a WordPress Plugin Developer, how do you avoid conflicts with other plugins and themes?
Why they ask it: They’re testing whether your code will behave in the messy real world.
Answer framework: Namespacing + hooks + defensive coding.
Example answer: “I namespace everything, prefix options and meta keys, and avoid global function names. I hook into WordPress actions/filters instead of editing core behavior directly, and I keep plugin responsibilities narrow. I also validate dependencies—like required PHP versions—and fail gracefully with admin notices. When I need to integrate with another plugin, I check for its functions/classes and version before calling anything.”
Common mistake: Writing ‘quick’ plugin code that pollutes globals and breaks other sites.
Q: How do you handle WordPress security hardening on a production site?
Why they ask it: In the US, WordPress is a common target; they want risk ownership.
Answer framework: Layers (updates, least privilege, input/output, infrastructure).
Example answer: “I start with boring basics: timely updates, remove unused plugins/themes, and enforce least-privilege roles. In code, I use nonces, capability checks, and proper sanitization/escaping. On the infrastructure side, I want WAF/CDN where appropriate, rate limiting for login, and backups with tested restores. I also like to log security-relevant events and keep secrets out of the repo via environment config.”
Common mistake: Thinking security equals ‘install a security plugin’ and stop there.
Q: What’s your approach to performance tuning for WordPress (Core Web Vitals)?
Why they ask it: US companies tie performance to SEO and conversion—this is revenue.
Answer framework: Measure–Hypothesize–Change–Verify.
Example answer: “I start with field data if we have it—CrUX or RUM—then use Lighthouse to reproduce. Common wins are caching strategy, reducing render-blocking assets, optimizing images, and limiting third-party scripts. On WordPress specifically, I look at query counts, slow plugins, autoloaded options bloat, and whether we’re using object caching like Redis. Then I verify improvements with the same pages and track Web Vitals over time.”
Common mistake: Chasing a Lighthouse score without checking real-user metrics.
Q: Explain your Git workflow for WordPress work—branches, reviews, and deployments.
Why they ask it: They’re testing whether you can work like an engineer in a team, not a solo freelancer.
Answer framework: “Branch → PR → checks → deploy” narrative.
Example answer: “I work in feature branches with small, reviewable commits. PRs include screenshots or short videos for UI changes and clear testing steps. I like automated checks—linting, unit tests where we have them, and at least a build step for assets. Deployments go through staging first, and I prefer tagged releases so we can roll back cleanly if something goes sideways.”
Common mistake: Treating production like a shared FTP folder.
Q: How do you handle WooCommerce customization without making updates painful?
Why they ask it: WooCommerce sites are common in the US market and easy to break.
Answer framework: Extension points first (hooks/filters), overrides last.
Example answer: “I try hooks and filters before template overrides, because overrides become a maintenance tax. If we must override templates, I keep them minimal and track WooCommerce version changes so we review overrides after updates. For checkout changes, I’m careful about performance and compatibility with payment gateways. And I document what we changed and why, so the next developer doesn’t ‘fix’ it back to default.”
Common mistake: Copying entire WooCommerce templates into the theme and never revisiting them.
Q: What US accessibility standard do you build toward, and how do you test it?
Why they ask it: US employers increasingly expect accessibility literacy due to legal and brand risk.
Answer framework: Standard + practical testing stack.
Example answer: “I aim for WCAG 2.1 AA as a baseline, which aligns with common expectations in the US market. I test with automated tools like axe and Lighthouse, but I don’t stop there—I do keyboard-only navigation checks and quick screen reader spot checks for key flows. In WordPress, I also watch for editor-generated markup and ensure our blocks and components produce accessible HTML by default.”
Common mistake: Claiming ‘we’re accessible’ because an overlay widget was installed.
Q: What would you do if a WordPress update breaks the site right before a campaign launch?
Why they ask it: They’re testing incident response under pressure.
Answer framework: Contain–Rollback–Diagnose–Communicate.
Example answer: “First I’d contain impact: maintenance mode if needed and stop further changes. If we have a safe rollback path—release tags, backups, or a previous container image—I’d roll back to restore service fast. Then I’d reproduce on staging, isolate whether it’s core, a plugin, or PHP compatibility, and apply a targeted fix. Throughout, I’d communicate in plain language to marketing: what happened, what’s live now, and when we’ll safely reattempt the update.”
Common mistake: Debugging directly on production while stakeholders refresh the page and panic.