Hiring WordPress developers: test what a page request costs
Most WordPress interviews test recall. The skill that actually predicts a good hire is knowing what a page request costs. Five probes and the answers to listen for.
Contents
- The short answer
- The admin page that takes four seconds
- The three layers a WordPress developer works across
- The template layer
- The extension layer
- The cost layer
- Five probes, and what the answers sound like
- The one non-technical thing worth testing
- What this buys you
- Frequently asked questions
- Should I hire a WordPress developer or a PHP developer?
- How do I test these things if I am not technical myself?
The short answer
What separates a strong WordPress developer from a competent one is not theme building. It is knowing what a single page request costs, and being willing to solve a problem without adding a plugin. You can test both in about fifteen minutes.
Most WordPress interviews test recall: name the hooks, describe the template hierarchy, list the plugins you have used. All three are learnable in a weekend, and none of them predicts what happens when the site gets slow.
The admin page that takes four seconds
You have inherited a site. It looks fine. Then you open the posts list in wp-admin and wait four seconds, every time, on a server that is not busy. The front end is cached so nobody complained, and the editors have been quietly hating their jobs for a year.
There are usually two or three causes, and they are almost never the theme.
The first is the wp_options table. Every WordPress request loads every option marked as autoloaded, before anything else happens. A plugin that parks a serialised cache in an autoloaded row adds that payload to every request on the site, including admin pages and AJAX calls. Deactivating the plugin does not always remove the row.
The second is an unbounded query. Somewhere a developer wrote posts_per_page => -1 because there were forty posts at the time. There are eleven thousand now, and that call is loading all of them into memory to count them.
The third is a remote call with no cache and no timeout, sitting inside a hook that fires on every page load. When the third party is slow, your site is slow, and the logs blame WordPress.
None of that is exotic. All of it is invisible to an interview about theme building.
The three layers a WordPress developer works across
It helps to be explicit about which one you are hiring for, because they need different people and most job descriptions blend all three into one.
The template layer
Theme files, blocks, the hierarchy, styling. This is the layer everybody interviews for. It is real work, and it is the most quickly learned of the three. A weak hire here produces a site that looks right and behaves oddly at the edges.
The extension layer
Hooks and filters, custom post types, the REST API, the block editor's data layer. This is where you find out whether somebody extends WordPress or fights it. The signal to listen for: do they reach for a filter, or do they copy a core template and edit it? The second choice works until the next update.
The cost layer
Queries, caching, autoloaded options, transients, the object cache, what the database is actually doing on each request. Almost nobody interviews for this, and it is the layer that decides whether the site is still pleasant to use in three years.
Five probes, and what the answers sound like
These are the questions worth your fifteen minutes. Each has a weak, competent and strong answer that is easy to tell apart even if you are not a WordPress developer yourself.
| What you ask | Weak answer | Competent answer | Strong answer |
|---|---|---|---|
| This admin page takes four seconds. Where do you look first? | Suggests a caching plugin | Opens Query Monitor and reads the slow queries | Asks about autoloaded option size before touching anything else, because it is the cheapest thing to rule out |
| The client needs a field on every product that they can edit themselves. How? | Installs a custom-fields plugin without asking anything else | Registers a meta field and a block or metabox for it | Asks who edits it, how often, and whether it needs to be queryable, then picks meta or a taxonomy on that basis |
| They want a feature. There is a plugin that does it. | Installs the plugin | Checks the plugin's update history and support before installing | Asks what happens if the plugin is abandoned, and whether the feature is fifty lines they would rather own |
| How do you output a value a user submitted? | Echoes it | Escapes on output with the right function for the context | Escapes on output, sanitises on input, and raises nonces for the write path without being prompted |
| The homepage needs the ten most recent posts from three categories. | Queries all posts and filters them in PHP | Writes a bounded WP_Query with the categories in the arguments | Writes the bounded query, caches the result in a transient, and says how the cache gets invalidated |
The pattern down the right-hand column is the same every time: the strong answer asks a question before it reaches for a tool, and it says how the change gets undone. That is the whole signal.
The one non-technical thing worth testing
Ask a candidate about a plugin they chose not to install, and what they built instead.
The answer tells you more than any code sample. WordPress makes adding a dependency almost free at the moment of the decision and expensive for years afterwards, and a developer who has never declined one has not been around long enough to pay that bill. A good answer is specific and unglamorous: a fifty-line snippet instead of a plugin with a settings page, an admin column instead of a dashboard, a cron job instead of a service.
A developer who has never turned down a plugin has never maintained a site through three years of updates.
What this buys you
Interviewing at the cost layer changes who you hire, and it changes what the site is like to own. Fewer plugins, smaller queries, and editors who do not dread the admin. None of that shows up in a portfolio screenshot, which is exactly why it is worth testing for on purpose.
If you would rather not run this process yourself, our WordPress developer hiring page describes how we screen for it, and the vetting scorecard sets out the stages in full.
Frequently asked questions
Should I hire a WordPress developer or a PHP developer?
If the work is themes, blocks and the plugin ecosystem, hire for WordPress: the platform's conventions are most of the job. If the work is a custom application that happens to sit behind WordPress, a strong PHP developer who learns the platform is usually the better bet, because the cost layer above is really just application engineering.
How do I test these things if I am not technical myself?
Use the table above and listen for shape rather than content. You are checking whether the candidate asks a clarifying question before proposing a tool, and whether they mention how a change gets reversed. Both are audible without knowing any PHP.
Is Query Monitor a fair thing to expect someone to know?
Yes. It is free, it is the standard diagnostic for the platform, and a developer who has debugged a slow WordPress site has almost certainly used it or an equivalent. Not knowing the name is fine. Not having a method for finding a slow query is not.
How many plugins is too many?
There is no number, and anyone who gives you one is guessing. The useful question is how many you could remove this quarter without the site changing, and whether anyone knows the answer. A site with forty maintained plugins and a named owner is healthier than one with twelve that nobody has looked at since launch.
Do these skills matter if we use a page builder?
More, not less. Page builders move work into the database, so the cost layer gets bigger and less visible. The slow admin page in the scenario above is more common on builder sites, not less.
Articles from the Code Elevator team, the engineers and specialists who vet developers, ship client work, and write up what they learn along the way.
More from CodeFour clients, on camera.
Why he brought his development work to Code Elevator.
One useful piece a month, no more than that.
What we learned building and hiring for this work. No newsletter filler.
Reading about it is step one. Building it is step two.
Hire a pre-vetted engineer who has shipped work like this before. Matched within 48 hours.
We reply within an hour during our working day in India and the UAE.