4) Technical and Professional Questions
This is where you win the interview. US teams usually don’t want you to recite WordPress internals—they want to see if you can build maintainable solutions as a WordPress Theme Developer or WordPress Plugin Developer, keep sites secure, and ship without breaking production.
Q: Explain how you’d build a block-first theme today. When do you use theme.json vs PHP templates?
Why they ask it: They’re checking whether you understand modern WordPress theming and editor-first workflows.
Answer framework: Architecture rationale — “default to X, use Y when Z,” plus one concrete example.
Example answer: “I default to theme.json for global styles, spacing, typography, and editor settings so design tokens stay consistent. I use templates and template parts to define page structure, and patterns for reusable sections. I still use PHP where it adds real value—dynamic data, conditional logic, or performance-sensitive rendering. For example, a dynamic ‘Related Posts’ block might be server-rendered in PHP, while the rest of the layout stays in block templates.”
Common mistake: Treating Gutenberg as ‘just a page builder’ and ignoring theme.json and patterns.
Q: What’s your approach to building custom blocks—ACF blocks, native block API, or something else?
Why they ask it: They want to know if you can choose the right complexity level and maintain it.
Answer framework: Decision matrix — editor UX needs, long-term maintenance, team skill set.
Example answer: “If the team needs structured content quickly and the block UI is straightforward, ACF blocks can be a pragmatic choice. If we need richer editor interactions, reusable components, or alignment with core blocks, I’ll use the native block API with React and build tooling. I also think about portability—if ACF is a hard dependency, I document it and keep field groups versioned. The key is: the editor experience should be predictable for content teams.”
Common mistake: Always choosing the most complex option to sound ‘senior.’
Q: How do you prevent plugin conflicts and ‘white screen’ incidents in production?
Why they ask it: They’re testing operational maturity—WordPress breaks are common and expensive.
Answer framework: Layered defense — staging parity, update policy, monitoring, rollback.
Example answer: “I prevent conflicts by keeping a staging environment that mirrors production caching and PHP versions, and by treating plugin updates like releases—tested, then deployed. I use error monitoring and logs to catch fatals early, and I keep a rollback plan: backups, version control for custom code, and a way to disable a plugin quickly (WP-CLI or hosting panel). I also reduce the plugin surface area—fewer plugins, better-vetted plugins, and clear ownership.”
Common mistake: Saying “I just update carefully” without describing a repeatable process.
Q: Walk me through how you secure a WordPress site beyond ‘use strong passwords.’
Why they ask it: Security is a top US hiring concern, especially for ecommerce and lead-gen sites.
Answer framework: Threat model → controls — admin surface, code, infrastructure, data.
Example answer: “I start with the admin surface: least-privilege roles, MFA if possible, and limiting login attack vectors. Then code-level controls: sanitize input, escape output, nonces for actions, and careful capability checks. On infrastructure, I want WAF/CDN rules, regular updates, and backups with restore drills. Finally, I pay attention to third-party plugins—review reputation, update cadence, and whether we can replace risky plugins with small custom code.”
Common mistake: Focusing only on login security and ignoring plugin risk and code hygiene.
Q: How do you handle performance for a content-heavy WordPress site—what do you measure and what do you change first?
Why they ask it: They want someone who can improve Core Web Vitals, not just install a cache plugin.
Answer framework: Measure → biggest bottleneck → verify — pick metrics, prioritize, retest.
Example answer: “I start with measurement: Lighthouse plus real-user monitoring if available, focusing on LCP, INP, and CLS. Then I look for the biggest bottleneck—render-blocking CSS/JS, unoptimized images, slow TTFB from PHP/database, or third-party scripts. I’ll tackle low-risk wins first: image formats, critical CSS, script deferral, and caching strategy. After changes, I retest and watch real-user metrics to confirm we didn’t just ‘game’ Lighthouse.”
Common mistake: Optimizing blindly without baseline metrics or regression checks.
Q: Describe your Git workflow for WordPress work. How do you handle deployments?
Why they ask it: US teams expect professional software practices even for CMS work.
Answer framework: Branching + environments — how code moves from local to prod.
Example answer: “I keep custom themes/plugins in Git with feature branches and PR reviews. I prefer separate environments—local, staging, production—with config handled via environment variables and wp-config constants. Deployments are ideally automated via CI/CD, but even manual deploys should be repeatable: tagged releases, database migration steps documented, and a rollback path. For content/config, I’m careful—code in Git, content in WordPress, and settings managed with a clear approach.”
Common mistake: Treating WordPress as ‘FTP to production’ in 2026.
Q: What’s your approach to WooCommerce customization without creating upgrade pain?
Why they ask it: WooCommerce sites are common in the US and easy to break with heavy overrides.
Answer framework: Minimal override principle — hooks/filters first, templates last.
Example answer: “I try to customize via hooks and filters before overriding templates, because template overrides can drift across WooCommerce updates. If I must override, I keep it minimal and track the WooCommerce template version changes during upgrades. For checkout changes, I’m extra cautious—performance and conversion matter, and third-party payment plugins add complexity. I document customizations so future updates aren’t a guessing game.”
Common mistake: Copying whole template files into a theme and forgetting them for two years.
Q: How do you build accessible WordPress components, and what standards do you follow?
Why they ask it: Accessibility is increasingly enforced in the US; teams want fewer legal and brand risks.
Answer framework: Standard + practice — name the standard, then describe how you implement and test.
Example answer: “I aim for WCAG 2.2 AA alignment, especially for navigation, forms, and interactive blocks. Practically, that means semantic HTML, keyboard support, visible focus states, and correct ARIA only when needed. I test with a keyboard, screen reader spot checks, and automated tooling like axe. In WordPress, I also think about editor accessibility—making sure custom blocks are usable for content creators.”
Common mistake: Treating accessibility as a ‘final QA step’ instead of a build constraint.
Q: In the US, how do you think about privacy/compliance on WordPress sites (cookies, tracking, forms)?
Why they ask it: They want you to understand real compliance pressure (especially for multi-state audiences).
Answer framework: Risk-based compliance — identify data flows, then implement controls.
Example answer: “I’m not a lawyer, but I treat privacy as an engineering requirement. I map what data we collect—analytics, ad pixels, form submissions—and ensure we have consent controls where needed, especially for marketing scripts. For forms, I minimize stored PII, secure transport, and define retention. If the business targets California residents, I flag CCPA/CPRA considerations early so we don’t bolt on consent at the end.”
Common mistake: Assuming privacy is only a ‘banner plugin’ problem.
Q: What would you do if WP-Admin is down during a critical launch and you can’t log in?
Why they ask it: They’re testing incident response and whether you can operate without the UI.
Answer framework: Triage–Stabilize–Recover — restore service first, then root cause.
Example answer: “First I’d confirm scope—front-end down too or just admin—and check hosting status, error logs, and recent deploys. If it’s a fatal error from a plugin/theme update, I’d disable the offending plugin via WP-CLI or by renaming the plugin directory, then restore from backup if needed. Once stable, I’d reproduce on staging, identify the root cause, and add a safeguard—like update gating, health checks, or better monitoring—so it doesn’t happen again.”
Common mistake: Spending 30 minutes debugging while the site stays down.