You’ve got three portfolios open in three tabs, all with clean layouts and a similar list of past clients. None of that tells you who can actually build your site without breaking it in six months. A polished portfolio is marketing; an interview is where competence shows up — if you know what to listen for.
You don’t need to write PHP to vet a WordPress developer. You need the right questions and a way to tell a real answer from a rehearsed one. This is the question bank: grouped by fundamentals, themes and plugins, security, performance, and process, each with what a competent answer sounds like and the red flag that should end the conversation.
Why Do You Need Technical Questions If You’re Not Technical?
Because vague answers are the tell, not the technical vocabulary. A developer who knows their craft explains it in plain language with specifics — what tool, what step, what happened last time. A developer who’s guessing reaches for buzzwords and generalities because there’s nothing concrete behind them.
Your job in the interview isn’t to judge the code. It’s to judge the shape of the answer: specific and confident versus vague and confident. Both sound confident. Only one holds up when you ask a follow-up question.
What Fundamentals Should Every WordPress Developer Know?
Start here regardless of the role — a maintenance hire and a full custom build both need this baseline. If a candidate stumbles on these, nothing downstream matters.
| Question | Good Answer Sounds Like | Red Flag |
|---|---|---|
| “Walk me through how you’d set up a new WordPress project, start to finish.” | Local or staging environment first, version control (Git) from day one, then a live/production deploy step with a checklist. | Building and testing changes directly on the live site because “it’s faster.” |
| “What’s the difference between editing a theme and building a plugin, and how do you decide which to use?” | Explains that theme edits affect presentation and plugins add functionality that should survive a theme change — and gives an example of choosing one over the other. | Can’t articulate the distinction, or says they always just “edit the theme files directly” for everything. |
| “How do you keep your changes from disappearing when WordPress or the theme updates?” | Child themes for theme-level changes, custom plugins for functionality, never editing core or parent-theme files directly. | Doesn’t know what a child theme is, or edits core WordPress files to make things work. |
| “Show me a live site you built and tell me one hard problem you solved on it.” | Names a specific technical constraint (a plugin conflict, a performance bottleneck, a tricky integration) and walks through the fix. | Only offers generic praise (“it turned out great”) with no technical specifics, or can’t recall any site by name. |
What this tells you: the first row is the single highest-signal question in this whole list. Editing live production directly is the fastest way to turn a small change into unplanned downtime, and it’s disturbingly common among developers who never learned a proper workflow.
What Should You Ask About Themes and Plugin Development?
This is where “custom-built” and “held together with plugins” diverge. Ask these before committing to any build that isn’t a simple brochure site.
- “When would you build a custom plugin instead of installing one from the WordPress repository?” A good answer weighs maintenance burden, security surface, and whether an off-the-shelf plugin actually fits the requirement versus forcing your site to adapt to the plugin’s assumptions. A red-flag answer defaults to “there’s a plugin for everything” regardless of fit — a habit that stacks up into the 30-plugin bloat that slows sites down and multiplies your attack surface.
- “Who owns the code once the project is done?” You should get a straight answer — you do, in writing, as part of the contract. Hesitation or vague licensing talk here is a business risk, not a technical one: it can leave you unable to move the site to another developer later.
- “How do you test for plugin and theme conflicts before launch?” Competent developers describe a staging environment, deactivating plugins individually to isolate conflicts, and browser/device testing before go-live. A red flag is “I just check that it looks fine” with no mention of a repeatable process.
- “If a page builder is involved, why that one — and what happens if we want to move off it later?” Good developers are honest about page-builder lock-in and portability trade-offs. Evasive answers here often mean the builder was chosen for the developer’s convenience, not your site’s long-term flexibility.
For scoped comparisons of what full custom development buys you over a templated build, our dedicated WordPress team vs. freelancers vs. in-house breakdown covers the trade-offs by engagement model, not just by skillset.
What Security Questions Reveal a Developer’s Competence?
“We take security seriously” is a sentence with no content. Push for specifics — a developer who’s actually done this work has concrete habits, not a slogan.
| Question | Good Answer Sounds Like | Red Flag |
|---|---|---|
| “How do you handle WordPress core, theme, and plugin updates?” | Staging test first, then scheduled production updates, with a backup taken immediately before. | “I turn on auto-updates and don’t think about it” or “I update whenever I remember.” |
| “What’s your backup strategy?” | Automated, off-site backups on a defined schedule, with a described (and tested) restore process. | Backups exist “somewhere” but they’ve never actually restored one to confirm it works. |
| “How do you handle user roles and admin access?” | Principle of least privilege — clients and staff get the lowest role that does the job, not blanket admin access. | Everyone gets Administrator “to keep it simple.” |
| “What would you do if this site got hacked or flagged with malware?” | A described incident-response sequence: isolate, identify the entry point, clean, patch the vulnerability, restore from a clean backup if needed. | No process — “that’s never happened to me” offered as if it settles the question. |
A developer who answers all four with specifics is one you can trust with credentials. For the fuller list of what a hardened WordPress install actually includes, see our WordPress security checklist.
What Performance and Optimization Questions Should You Ask?
A site that looks right in the demo but loads slowly for real visitors is a business cost you won’t notice until traffic reports come in. These questions surface whether performance was ever part of the developer’s process, not an afterthought.
- “How do you approach image optimization and page speed on a new build?” Look for concrete mention of image compression/format choice, caching, and minimizing plugin bloat — not a one-word “yeah, I optimize images.”
- “What’s your plan if Core Web Vitals scores come back poor after launch?” A competent developer names a diagnostic approach (lab data vs. field data, isolating the slowest asset) rather than a single blanket fix. Our guide to page speed optimization covers exactly this kind of fix-by-fix breakdown if you want to sanity-check their answer afterward.
- “What hosting do you recommend for this project, and why?” Good developers match hosting recommendations to your actual traffic and stack — they don’t push one host reflexively regardless of fit.
What Process and Communication Questions Matter Most?
Technical skill without a workable process is how good developers still deliver late, over-scoped, unmaintainable projects. These questions surface whether they can actually run a project, not just write code.
- “Walk me through your workflow from kickoff to launch.” Expect distinct stages — discovery, staging build, review/revision rounds, QA, launch, handoff — not “I just start building.”
- “How do you handle scope changes mid-project?” A clear process (documented change requests, updated timeline/cost) beats “we’ll figure it out as we go,” which is how budgets quietly double.
- “What do I get after launch — documentation, training, or ongoing support?” Good developers hand off logins, a basic site guide, and clarity on what maintenance costs going forward. Silence here often means you’re on your own the day after launch.
- “Can I talk to two past clients, and can I see the live sites?” A confident developer supplies both immediately. Reluctance, outdated portfolio links, or “the client asked me not to share their site” for every reference is worth pressing on.
If you’re weighing whether this project needs a single freelancer or a coordinated team, our how to hire WordPress experts and hiring WordPress developers guides cover the sourcing decision in more depth than this interview-question list does on its own.
How Do You Score the Interview Without Being a Developer Yourself?
Run a simple tally instead of trying to judge technical merit directly:
- Count specific answers vs. vague ones across the questions above. Specificity is the single best proxy for real experience when you can’t evaluate code yourself.
- Flag any single hard red flag as disqualifying — live-site editing, no backup strategy, or reluctance to share references are each, on their own, reason enough to pass.
- Weight security and process higher than technical trivia. A developer who’s slightly weaker on obscure WordPress internals but rock-solid on backups, staging, and communication will cause you far fewer problems than the reverse.
- Verify at least one claim. Call one reference or actually load one portfolio site on your phone and run it through a free speed test. Claims that don’t survive five minutes of verification aren’t claims worth trusting.
What Are the Biggest Red Flags When Vetting a WordPress Developer?
If you only remember five things from this list, remember these — each one has derailed real projects:
- Editing live production directly, with no staging environment in the workflow.
- No documented backup and restore process — or one they’ve never actually tested.
- Vague code ownership — unclear on whether you’ll own the finished code and credentials outright.
- Everyone gets admin access because managing roles “is extra work.”
- No specifics under follow-up questions — impressive-sounding first answers that don’t hold up when you ask “how, exactly?”
Frequently Asked Questions
What should I ask a WordPress developer before hiring them?
Cover five areas: fundamentals (workflow, child themes, version control), themes/plugins (custom vs. off-the-shelf, code ownership), security (updates, backups, user roles), performance (image optimization, hosting fit), and process (timeline, scope changes, references). A developer who gives specific, confident answers across all five is a safer hire than one who’s only strong in one area.
How do I vet a WordPress developer if I’m not technical myself?
Judge specificity, not vocabulary. A competent developer answers with concrete tools, steps, and examples from past work; a weak one leans on buzzwords and generalities. Ask one follow-up question per topic — real experience holds up under a follow-up, a rehearsed answer usually doesn’t.
What are red flags when interviewing a WordPress developer?
The biggest ones: editing live sites directly with no staging step, no tested backup strategy, vague or evasive answers about code ownership, giving every user admin access by default, and reluctance to share references or live portfolio sites.
Should I ask coding questions if I’m hiring a WordPress developer for a business project, not an engineering role?
Light technical questions still help — even a non-technical buyer can judge whether an answer is specific or vague. But weight process and security questions more heavily than deep code trivia; those are the areas most likely to cause real damage to your site and business if handled poorly.
How many WordPress developers should I interview before deciding?
Three is usually enough to compare answer quality and spot patterns — fewer and you have no baseline for what a strong answer looks like; many more and you’re spending time better used on reference checks and a paid trial task.
Is a paid test project a good way to vet a WordPress developer?
Yes, for any engagement above a small fix. A small, paid, well-scoped test task (a single component build or a bug fix) shows you real work quality and process in a way no interview answer can fully substitute for, and it’s standard practice for vetting freelance or agency talent.
You Might Also Find Useful
- How to hire WordPress experts — the sourcing decision this interview process feeds into
- Hiring WordPress developers — a broader look at where to find qualified candidates
- Dedicated WordPress team vs. freelancers vs. in-house — choosing the right engagement model before you interview anyone
- WordPress outsourcing rates by country — what you should expect to pay once you’ve vetted candidates
- Hire a dedicated development team — a pre-vetted alternative to running this process solo
