How to hire PHP developers: vetting and Laravel guide

If you want to hire PHP developers, start by reading "five years of PHP" with suspicion. It can mean five years of Laravel on a current release, or five years of patching code that was written for PHP 5.6 and never upgraded. The resume looks identical either way. This guide is part of our series Hire developers by tech stack: rates, vetting and interview guides, and it covers only what's specific to PHP: versions, frameworks, legacy work and the WordPress split.

Most bad PHP hires are decided before the first interview, by a job spec that doesn't say which of three roles it's for or which version the codebase runs.

Why "PHP developer" hides three different hires

A PHP job post usually describes one of three people.

The first is the application engineer, who builds products in Laravel or Symfony. They think in routes, queues, migrations, tests and deployment. This is usually the hire a product company means when it says "PHP developer".

The second is the WordPress or WooCommerce developer, who builds themes and plugins. That's a CMS skill set. It overlaps with framework engineering at the language level and very little beyond it, and a strong WordPress developer can be a poor fit for a Laravel API, and the reverse is true too.

The third is the legacy maintainer or upgrader. They know how to read an old codebase with no tests, find what's safe to change and move it forward one version at a time. It's a distinct and valuable skill, and it's harder to judge from a resume than the other two.

The decision rule is short. If you're building or extending a product with its own data model and business logic, hire the application engineer. If your site is content or commerce on WordPress and the work is themes, plugins and editing workflows, hire the WordPress developer. If the app already exists, runs an old PHP version and has few tests, hire the upgrader first, then bring in application engineers once the codebase can support them. Many teams need the upgrader and the application engineer in sequence, and a fixed-scope upgrade project often fits better than a permanent seat.

Which PHP and Laravel versions to write in the job spec

Pin versions in the spec. PHP's support model is two years of active support followed by two years of security-only fixes, and the PHP supported versions page lists what that means today. Laravel's policy, quoted from its Laravel 13 release notes, is that "bug fixes are provided for 18 months and security fixes are provided for 2 years".

Here's the picture as of 2 October 2026.

Four things follow from the tables. PHP 8.2 loses security support on 31 December 2026, so a spec that says "PHP 8.2" is advertising a version with three months left. Laravel 13 requires PHP 8.3 at minimum, so a Laravel 13 project can't run on 8.2. Laravel 11 is already past its security fixes. And Laravel 12 is now security-only until 24 February 2027, which makes it a version to upgrade from, not start on.

For a new build, write "PHP 8.4 or 8.5 and Laravel 13". For an existing product, write the version you actually run and add "experience upgrading between major versions". Then ask every candidate which version they upgraded from and to. That one question separates people who've done the work from people who've read about it.

Don't take competitor guides as a reference here. Remote Crew's PHP hiring guide, published 12 February 2026, still tells you to ask for "Laravel 10+", a version that stopped getting security fixes in February 2025. CoderPad's 2024 hiring guide was modified in April 2026 but its salary figures are 2023 US data and it names no PHP version at all.

How common PHP is, and what that means for the talent pool

PHP is used by 69.8% of the websites whose server-side language W3Techs can identify, according to its programming language usage overview from 2 October 2026. That's a large installed base, and it means candidates exist. You won't struggle to find people who list PHP.

The version split is the useful part. On the same date, W3Techs' PHP version breakdown put PHP 8 at 64.4% of those sites, PHP 7 at 27.8% and PHP 5 at 7.8%. W3Techs reports major versions only, so it can't tell you how many of the 8.x sites run a supported minor.

Read that as a screening problem. More than a third of identified PHP sites run a major version that's long out of support, so a large share of the people with "years of PHP" built their experience there. Legacy candidates are plentiful. Candidates with modern habits (strict typing, automated tests, dependency management, current framework versions) exist but need to be found by testing, not by keyword.

Laravel, Symfony or WordPress: which skill set does the project need?

Choose the framework before the person, because the three skill sets don't transfer evenly.

Laravel's current release is moving quickly. The Laravel 13 feature list includes a first-party Laravel AI SDK, JSON:API resources, vector and semantic search, and expanded PHP attributes. If your roadmap touches any of those, make them screening topics. If it doesn't, don't filter on them. A candidate who has never touched the AI SDK but can explain queues, caching and testing is a better hire for most products than one who has read the release notes only.

Symfony is a separate framework with its own conventions. Hire for Symfony when your codebase is Symfony. Don't hire a Laravel specialist and hope the experience transfers.

WordPress is its own market. If the work is plugins, themes or WooCommerce, test for that directly: hooks, the template hierarchy, plugin security. Don't expect those skills to show up in a Laravel interview, and don't expect a Laravel engineer to enjoy a plugin backlog.

If the product pairs a PHP backend with a Vue frontend, often through Inertia, you're hiring a cross-stack profile, and our hiring guide for Vue.js developers covers the frontend half of that interview.

How to hire a PHP developer: step by step

1. Decide the profile and engagement model

Pick one of the three profiles from earlier, then pick the engagement. A permanent hire suits a product with a long roadmap. Contract or staff augmentation suits a bounded build or a gap in the team. A fixed-scope project suits an upgrade, because a version migration has a clear start and a clear end. Writing this down first stops you advertising a permanent Laravel role when what you need is a three-month upgrade from PHP 7.4.

2. Write a spec that pins versions and framework

Name the PHP version, the framework and its major version, and the test tooling you use. State whether the codebase is greenfield, mid-life or legacy. Ask for evidence of version upgrades. Use the tables above so the spec doesn't ask for a version that's about to lose security support.

3. Source where PHP application engineers actually are

Match the channel to the profile. A generalist job board will return every kind of PHP resume, so look for places where the specific framework or CMS community gathers: the open-source repositories and issue trackers of Laravel or Symfony packages for application engineers, and the plugin and theme directories for WordPress work. For upgrade work ask for references from previous migrations, since a portfolio of new apps says little about it. We haven't verified any PHP-specific job board for this article, so we aren't listing one.

4. Screen with a code-review exercise

Replace the resume screen with a written review. Send a short piece of code with planted problems, give the candidate an hour, and read the result before any call. The next section describes four exercises. In our view, a written review is harder to fake than a live quiz, and it takes the candidate less time than a take-home project.

5. Run a version-and-upgrade conversation

Ask which PHP and framework versions they've run in production, what they upgraded from and to, what broke, and how they found out. Then ask what they would do about a Laravel 12 app today, given the dates in the tables. A good candidate gives a sequence: tests first, dependency audit, one major version at a time. A weak one says "just update Composer".

6. Check references and run a paid trial task

References matter most for the legacy and upgrade profile. Call someone who worked with the candidate on a migration and ask what the candidate changed and what they left alone. Finish with a paid, small, real task of a few days. Pay for it. It tells you more about code review habits, commit discipline and communication than another interview does.

PHP vetting exercises

Four exercises cover the PHP-specific ground. For generic backend seniority, system design and production ownership, use our guide to hiring backend developers, which handles those across languages. Give the candidate the code and ask for a written review.

Controller review

Give them a controller that loads a list of records and then queries a related table inside the loop, accepts every request field straight into a model, and has no input validation. The three bugs are an N+1 query problem, a mass-assignment risk and missing validation.

A strong candidate finds all three and proposes fixes: load related records up front rather than per row, whitelist the writable fields, and validate input before it reaches the model. The red flag is a review that talks about code style and misses the queries entirely.

Strict types and modern PHP

Give them a function with loosely typed arguments and ask them to modernise it. Look for strict typing, declared return types, and a preference for enums over strings that stand for a fixed set of values. Read-only properties and attributes are also fair to ask about.

A strong candidate explains what each change prevents, not just what it looks like. The red flag is code that could have been written in the PHP 5 era with new syntax pasted on top.

Testing with PHPUnit or Pest

Ask how they'd test the controller from exercise one. Either PHPUnit or Pest is a good answer. What you're listening for is whether they test behaviour (what the endpoint returns, what lands in the database) or implementation. Ask what they do when a test is flaky.

The red flag is "we didn't have time for tests". That may be true of where they worked, but it means they haven't built the habit you're hiring for.

Security review

Show them a snippet that builds a SQL string from user input, prints user content without escaping and saves an uploaded file under its original name. The strong answer names SQL injection, cross-site scripting and unsafe file handling, and proposes parameterised queries, output escaping, and validating the file type and storing it under a generated name outside the public path.

The red flag is trusting the framework to handle everything. Frameworks help, but raw queries and manual output bypass the protection.

PHP interview questions that show real seniority

1. How do you avoid N+1 queries in Eloquent?

Tests whether they've shipped Laravel against a real database. A good answer covers eager loading, spotting the problem with query logging or a debug tool, and knowing when a join is better. Red flag: "I haven't seen that."

2. A queued job keeps failing. What do you do?

Tests operational thinking. Listen for retries with backoff, a failed-jobs table, idempotent job design and alerting. Red flag: wrapping the job in a try/catch that swallows the error.

3. How would you upgrade a PHP 7.4 application to 8.x?

Tests whether they've done it. A strong answer starts with tests and static analysis, audits dependencies for compatibility, upgrades one minor or major at a time and deploys each step. Red flag: "change the version in the Dockerfile and see what breaks."

4. Explain dependency injection and the service container

Tests understanding of how a Laravel or Symfony app is wired together. They should explain constructor injection, binding an interface to an implementation and why that helps testing. Red flag: describing it as "facades".

5. What does a Composer lockfile do, and who should commit it?

Tests dependency discipline. The lockfile pins exact versions so every environment installs the same set, and an application should commit it. Red flag: deleting the lockfile to fix a conflict.

6. How do you secure file uploads?

Tests the same ground as the security exercise from a design angle: validate type and size, don't trust the client's filename or MIME type, store outside the web root, and serve through a controlled route. Red flag: only checking the file extension.

7. When would you not use PHP?

Tests honesty about tradeoffs. A good answer names a real case, such as a team with deep skills in another language, heavy real-time or CPU-bound workloads, or a data-science-heavy product where our Django hiring guide is the closer match. Red flag: "always PHP".

Cost and rates

We aren't printing a PHP rate table. We didn't find a primary, dated source for PHP rates, and the vendor-published figures vary widely and come without a methodology. A number you can't trace is worse than none.

What moves the price is more useful. The profile matters most: a Laravel engineer who owns architecture prices differently from a WordPress theme developer. Upgrade experience on large legacy codebases can change the price, because the work carries more risk. Seniority moves it, as does whether the person can run a project or only implement tickets, and the engagement model changes the structure of the price again: permanent, contract and fixed-scope cost differently.

Where PHP talent sits and engagement models

PHP developers work in every region, so geography is a second-order decision. Pick the engagement model first. Permanent hires suit a long roadmap and shared ownership of the codebase. Staff augmentation suits a team that needs two or three extra engineers for a release. A fixed-scope project suits an upgrade or a rebuild of one module, because the deliverable is defined and the team doesn't have to be kept afterward.

If you consider a hire from European countries, check time-zone overlap with your team and the legal setup (employment or contractor) before you compare anything else. A candidate you can't get in a room for the hours that matter will cost you more than a rate difference.

FAQ

How much does a PHP developer cost?

We don't publish a PHP rate because we couldn't find a primary dated source for one. Price depends on the profile (Laravel, WordPress or legacy upgrader), seniority, upgrade experience and the engagement model. If a vendor quotes a figure, ask where it comes from and which country it covers.

Is PHP still worth hiring for in 2026?

Yes. W3Techs shows PHP on 69.8% of sites with a known server-side language, and both PHP and Laravel are actively maintained: PHP 8.5 came out in November 2025 and Laravel 13 in March 2026. The caution is about versions. More than a third of the PHP websites W3Techs tracks still run PHP 7 or older (2 October 2026), so the skill you're buying is working on current ones.

Laravel or Symfony developer?

Match the codebase you have. For an existing Symfony application, hire Symfony experience, and for an existing Laravel one, hire Laravel experience. For a new product, pick the framework your team can maintain and review, then hire for it. The Laravel 13 features are worth testing only if your roadmap needs them.

Which PHP version should a new hire know?

PHP 8.3 at minimum, and ideally 8.4 or 8.5. Laravel 13 requires 8.3, and PHP 8.2 stops receiving security fixes on 31 December 2026. For a legacy role, add experience upgrading from older versions, and ask for the upgrade story.

Should I hire a WordPress developer or a PHP developer?

Hire a WordPress developer for themes, plugins and WooCommerce. Hire a PHP application engineer for a custom product built on Laravel or Symfony. They share a language and little else, so test for the work the job actually involves.