Why pre-screen WordPress developers before the technical interview
Two people describe themselves the same way here. One writes themes and plugins and can debug a fatal error at three in the morning; the other installs a page builder and thirty plugins and hopes. The second is cheaper right up to the point where the site is slow, insecure and impossible to change. A short screen asks what they built rather than installed, which separates them in one answer.
What actually matters when screening WordPress Developer candidates
- 01
Technical proficiency
Check depth in PHP, custom theme and plugin work, hooks and filters, WP_Query, the REST API, and Gutenberg block development with React and block.json.
- 02
Systems and trade-offs
Probe decisions on multisite versus separate installs, ACF versus custom meta tables, object caching, WooCommerce scaling, and when to avoid another plugin dependency.
- 03
Evidence and rigour
Test how they diagnose slow sites and fatal errors: Query Monitor, New Relic, debug.log, Core Web Vitals scores, and rollback plans after failed updates.
- 04
Collaboration and communication
Assess handoff to clients and designers: staging workflows, Git plus WP Migrate or WP-CLI deploys, documentation, and translating Figma files into theme templates.
Pre-screening questions to ask WordPress Developer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Built not assembled
3 questions01Can you provide examples of plugins you have developed?
Listen forPlugins they wrote with what problem each solved, and how they handled updates and compatibility.
Plugins configured rather than written, or no code they can point to.
02Do you have experience with custom theme development?
Listen forThemes built from scratch or from a starter, with template hierarchy understood properly.
Themes purchased and modified only through a builder, or no template work at all.
03Can you describe your experience with commerce platforms on this stack?
Listen forReal commerce work including checkout customisation, tax handling and payment gateway integration.
Commerce experience limited to installing and styling, or no checkout work.
Code and conventions
4 questions04What is your proficiency with the underlying language and database?
Listen forComfort writing queries and reasoning about the data model, not just using framework helpers.
No direct database work, or queries written without regard to indexing or scale.
05How familiar are you with the platform's coding standards and conventions?
Listen forHooks and filters used properly, with an understanding of why modifying core is unacceptable.
Core files edited, or customisation achieved by overriding rather than hooking.
06Can you explain your experience integrating external services?
Listen forIntegrations with error handling, credentials kept out of code and failures handled gracefully.
Keys committed in code, or integrations that break the site when a service is down.
07Are you familiar with building and consuming the platform's own interfaces?
Listen forCustom endpoints they built themselves, with authentication and permission checks applied correctly throughout.
Endpoints exposed without permission checks, or interfaces used only for reading.
Security and speed
2 questions08What security measures do you implement when building a site?
Listen forInput sanitised and output escaped as a habit, with a plan for keeping plugins updated.
Security answered as installing a plugin, or user input trusted anywhere.
09How do you handle website performance optimisation?
Listen forSlow queries and plugin overhead investigated with profiling, not just caching added on top.
Performance addressed by a caching plugin alone, or no measurement before and after.
Version controlled
3 questions10Can you explain your process for testing and fixing bugs in your code?
Listen forA staging environment used, with debugging enabled properly rather than changes made on production.
Changes made directly on live sites, or debugging done by commenting code out.
11Do you have experience with version control systems?
Listen forVersion control used for themes and plugins as normal practice, with deployments repeatable.
Files edited over a file transfer connection, or no version history for custom code.
12How do you manage your workflow and prioritise tasks?
Listen forClear communication about progress and about blockers, with realistic estimates given upfront.
Silence between updates, or estimates that consistently need extending.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names specific hooks, custom post type and taxonomy work, and shows custom blocks or plugins built without relying on page builders.
Systems and trade-offs
25%5Explains trade-offs with reasons: plugin bloat, database query cost, upgrade risk, and hosting constraints on specific past sites.
Evidence and rigour
25%5Walks through a real diagnosis with measured before and after numbers, such as TTFB or LCP improvements on a named site.
Collaboration and communication
15%5Describes clear client handover, version-controlled deploys, and pushing back on requests that would break maintainability or security.
One writes themes and debugs a fatal error; the other installs thirty plugins and hopes. A one-way video screen tells them apart.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish what they built, test their command of the platform, and check security and workflow practice.
Should I ask for site links?
Yes, and ask what part of each was theirs. A finished site tells you nothing about whether they built the theme or configured a template someone else made.
Evaluating answers
What is the strongest signal when screening this role?
Custom code they wrote. Developers name a plugin or theme and what it does. Anyone whose answer is a list of plugins they use is an integrator, which may be fine but is a different hire.
How do I judge their security practice?
Ask what they do about input handling and plugin updates. Real answers cover sanitising, escaping and a review process. Anyone whose answer is a security plugin has not thought about it.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
