Hire PHP developers

PHP runs a very large share of the web, and the gap between modern PHP and the PHP people remember is the main thing a hiring process has to detect.

What PHP actually is

PHP is a server-side language with an unusually large installed base, powering WordPress, a great deal of commerce, and a long tail of business applications. It is developed in the open with a predictable annual release and a clearly dated support window for each version. Its reputation among people who last used it fifteen years ago is worse than the language now deserves.

Modern PHP has strict types, proper namespaces, a mature dependency manager, a strong testing culture and frameworks that compare well with anything in other ecosystems. It is also fast in a way that surprises people, having gone through substantial engine work over the last decade. None of this changes the fact that a very large amount of old PHP is still running, and that much of the available work involves touching it.

That split is the whole hiring problem. Two candidates can both have a decade of PHP behind them: one has spent it writing typed, tested, framework-based code with a dependency manager, and the other has spent it maintaining files that mix SQL, HTML and business logic. Both are experienced. Only one of them will be comfortable in a modern codebase, and the CV will not tell you which.

The part that separates seniors from mid-levels

PHP's execution model is the thing that shapes everything else about it. Traditionally each request starts a fresh process state, runs, and throws everything away. There is no long-lived application memory between requests unless you arrange one. That makes PHP unusually forgiving of memory leaks and unusually dependent on external state for anything that has to persist, and it is why caching layers and queues are such a prominent part of any serious PHP architecture.

That model has been changing. Long-running worker approaches keep the application in memory across requests, which removes the startup cost and dramatically changes performance, while introducing exactly the class of bug the traditional model protected you from: state leaking between requests. A developer who has moved an application to a long-running model can tell you what they had to fix, usually static properties and container state that nobody had thought about in years.

The third area is types. PHP's type system has grown substantially and is genuinely useful, but it is opt-in per file and not enforced everywhere. A codebase can be strictly typed, loosely typed, or a mixture with no clear boundary. Candidates who work with static analysis tooling as a matter of course are describing a different daily experience from those who do not, and the difference shows up directly in defect rates.

Where PHP is used

The label “PHP developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Content management

WordPress, Drupal and similar systems, which together account for a very large share of all PHP in production.

E-commerce

Magento, WooCommerce and Shopware, where the platform is the constraint and PHP is how you work within it.

Custom business applications

Laravel and Symfony applications serving internal operations, often the system a company actually runs on.

APIs and back ends

Services behind mobile applications and single-page front ends, where PHP is the back end because it already was.

Legacy maintenance

Applications written before modern practice, still generating revenue, needing careful change rather than rewriting.

Integration work

Connecting content or commerce platforms to payment, fulfilment and enterprise systems.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which PHP versions are still supported

PHP publishes a fixed support window for each release, with active support followed by security-only support, so whether a version is safe to run is a matter of published record.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 4 are still maintained and 4 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for PHP alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Composer

Dependency management. Its presence and correct use is the fastest single indicator of whether a codebase is modern.

Laravel or Symfony

The two dominant frameworks. Laravel favours speed of delivery, Symfony favours explicitness and reuse.

PHPUnit or Pest

Testing. A PHP codebase with real test coverage is a meaningfully different proposition.

PHPStan or Psalm

Static analysis, which catches in PHP what a compiler catches elsewhere.

MySQL or PostgreSQL

The usual data stores, with MySQL dominant in the content and commerce world.

Redis

Caching, sessions and queues, which the request model makes essential rather than optional.

Xdebug or a profiler

Step debugging and profiling. Developers who use neither are guessing.

Docker

Local environments, which removed one of the historical pain points of PHP development.

Related skills that frequently appear on the same specification: Laravel, WordPress, JavaScript, MySQL, Magento and Adobe Commerce.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Which PHP they have written

The central question, given how wide the range of real-world PHP is.

• Strong answer: Describes typed, tested, framework-based work with a dependency manager, and is candid about legacy code they have maintained.
• Warning sign: Cannot describe their tooling, or has never used Composer in anger.

SQL injection and input handling

PHP's history makes this non-negotiable, and it is still the most common serious fault found in PHP codebases.

• Strong answer: Prepared statements always, validation at the boundary, output escaping appropriate to context, and can explain why concatenation is never acceptable.
• Warning sign: Mentions escaping functions as a defence, or treats framework use as sufficient protection.

Static analysis and types

The clearest marker of modern practice.

• Strong answer: Runs static analysis in continuous integration, declares strict types, and can describe raising the level on an existing codebase.
• Warning sign: Has not used static analysis and sees no need for it.

The request lifecycle and state

Determines whether they can reason about caching, sessions and long-running workers.

• Strong answer: Understands that state does not persist by default, and knows what changes under a long-running worker model.
• Warning sign: Assumes application state persists between requests, or cannot explain where sessions actually live.

Working in legacy code

A large share of PHP work, and the area that separates useful hires from frustrated ones.

• Strong answer: Writes characterisation tests before changing behaviour, works in small reversible steps, and can describe strangling an old module.
• Warning sign: Proposes a rewrite immediately, or has only worked in framework code.

Performance diagnosis

PHP performance problems are usually database problems, and people who have not profiled tend to guess wrong.

• Strong answer: Profiles, inspects queries, uses caching deliberately, and can quote a measured improvement.
• Warning sign: Proposes micro-optimisations with no measurement.

Version upgrades

Common work, and genuinely risky in older codebases.

• Strong answer: Has moved an application across major versions and can describe what broke and how they staged it.
• Warning sign: Has only worked on applications already on a current version.

Warning signs in a PHP codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

SQL built by string concatenation

• What you see: Query strings assembled from variables.
• What it costs: Injection, which remains the most common serious vulnerability in PHP applications.
• The fix: Prepared statements without exception. Treat any concatenated query as a defect regardless of where the input came from.

Business logic in template files

• What you see: Database queries and decision logic inside files that also emit HTML.
• What it costs: Nothing can be tested, nothing can be reused, and every change risks the output.
• The fix: Separate the layers. In legacy code, extract behind a tested function first rather than restructuring everything.

Suppressing errors

• What you see: The error suppression operator used to quiet warnings.
• What it costs: Real failures hidden, producing corrupt behaviour that is very hard to trace.
• The fix: Handle the condition. Where a warning is genuinely expected, check for it explicitly.

Ignoring the dependency manager

• What you see: Libraries copied into the repository by hand, or included from unmanaged paths.
• What it costs: No upgrade path, no security tracking, and no way to know what version is actually running.
• The fix: Bring everything under Composer, commit the lockfile, and audit regularly.

Global state and static everything

• What you see: Static properties and global variables holding application state.
• What it costs: Untestable code, and outright bugs when the application moves to a long-running worker model.
• The fix: Inject dependencies. This is also the prerequisite for any modern hosting approach.

Running an unsupported version

• What you see: Production on a PHP release past its security support date.
• What it costs: No security patches on one of the most attacked surfaces on the internet.
• The fix: Upgrade to a supported release. Static analysis and a test suite make this far less frightening than it sounds.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a PHP developer.

Junior

Implements features within an existing framework structure. Needs review on query safety and on separating logic from presentation.

Mid-level

Owns a feature area including its tests. Comfortable with the framework's conventions and can debug with a profiler rather than by guessing.

Senior

Owns application architecture, the caching and queue strategy, and can modernise a legacy codebase incrementally while it stays in service.

Staff

Owns the upgrade path, the static analysis and testing standard, and the decision about which legacy systems to modernise and which to replace.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New Laravel or Symfony application

• Usual team: One to two developers.
• What governs it: Fast to a working product. The domain model and the queue strategy are what to get right early.

Legacy modernisation

• Usual team: Two developers, one with legacy experience.
• What governs it: Scoped by test coverage, which is usually zero. Characterisation tests come first and take longer than expected.

Version upgrade

• Usual team: One developer.
• What governs it: Static analysis makes this tractable. Several major versions behind with no tests is a project rather than a task.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Nearly always queries and caching. Begins with a profiler, not with opinions.

Platform integration

• Usual team: One developer who knows the platform.
• What governs it: Scoped by the platform's extension model rather than by the size of the feature.

Migration work you may actually be hiring for

A large share of PHP work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

An unsupported PHP version to a supported release

• Why teams do it: Security patches, and libraries that no longer publish compatible versions.
• What to watch: Run static analysis at the target version first to find breakages before changing anything. Deprecated functions and type juggling changes are the usual causes, and both are findable in advance.

A custom legacy application to a framework

• Why teams do it: Testability, a hiring pool that recognises the structure, and an upgrade path that exists.
• What to watch: Strangle rather than rewrite. Put the new framework in front, move one route at a time, and keep the old application serving everything not yet moved.

The traditional request model to a long-running worker

• Why teams do it: Removing per-request startup cost, which can be a substantial performance gain.
• What to watch: Static properties, container state and anything cached in memory now persist between requests. Audit for shared state before switching, because the bugs are subtle and look like data corruption.

Untyped code to strict types with static analysis

• Why teams do it: Catching in advance the class of error PHP otherwise finds at runtime.
• What to watch: Raise the analysis level one step at a time, fixing as you go. Setting the strictest level on a large legacy codebase produces thousands of errors and the effort gets abandoned.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a PHP developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which PHP version the codebase runs on, and whether upgrading is in scope.
• Whether this is framework work, platform work such as WordPress or Magento, or custom legacy code. These are three different hires.
• Whether a dependency manager, tests and static analysis exist, since inheriting a codebase without them is a different job.
• What the caching and queue setup is, because the request model makes these architectural rather than optional.
• Whether the work is new development or maintenance, and be honest, because this determines who will be happy in the role.
• What the hosting is, since shared hosting, containers and long-running workers impose very different constraints.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

PHP work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a PHP developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a PHP developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for PHP frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Legacy habits in a modern codebase. Ask about their tooling: dependency manager, static analysis, tests. The answer is very hard to fake.

Security practice formed in an older era. Ask about injection and output escaping specifically. This is the one area where an outdated habit is dangerous rather than merely inefficient.

Framework knowledge without language depth. Ask what happens between requests. Framework familiarity can hide a shallow model of the runtime.

Reluctance to work in old code. Much PHP work is maintenance. Ask directly, because a mismatch here produces an unhappy hire rather than a bad one.

Hiring PHP developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of PHP developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Is PHP still a reasonable choice in 2026?

For web applications, yes. Modern PHP is fast, properly typed, well tooled and supported by two mature frameworks, and the hiring pool is large. The strongest arguments for it are practical: an enormous ecosystem, cheap and ubiquitous hosting, and the fact that if your site is on WordPress or Magento the decision has already been made for you.

How do we tell modern PHP experience from legacy experience?

Ask about tooling rather than about the language. Someone who names their dependency manager, their static analysis level, their test framework and their local environment setup is describing modern practice. Someone who cannot is describing something else, and it will show up in the first week.

Our site is on an old PHP version. How bad is that?

If it is past its security support date, it is a genuine risk rather than a theoretical one, because PHP applications are among the most probed surfaces on the internet. The upgrade is usually much less painful than teams fear, particularly with static analysis to find the breakages in advance. Deferring makes it worse, since each year adds another version to cross.

Should we use Laravel or Symfony?

Laravel for speed of delivery and a larger hiring pool, particularly for applications that fit its conventions. Symfony where you want explicit configuration, reusable components and a structure that scales to large teams. Both are strong. Laravel is the more common answer for a product; Symfony is the more common answer inside a large organisation.

Is PHP fast enough for a high-traffic site?

Yes, and the evidence is that a large share of the highest-traffic sites in the world run on it. Modern PHP is dramatically faster than its reputation, and where PHP applications are slow it is almost always the database or missing caching rather than the language. Long-running worker models close most of the remaining gap where it matters.

Can a WordPress developer work on our Laravel application?

Sometimes, and it should be tested rather than assumed. WordPress development is often plugin and theme work within a fixed system, which is a different skill from building an application with a framework, a domain model and a test suite. Some WordPress developers are excellent application engineers. Many have not needed to be.

What does bad PHP look like in review?

Concatenated SQL, business logic inside templates, error suppression, no dependency manager, no tests, and static state everywhere. All six are visible in minutes, and any two of them together predict that changes to this codebase will be slow and risky for as long as it exists.

Should we rewrite our legacy PHP application?

Usually no, or at least not all at once. Rewrites of systems that are still earning money have a poor record, because the old system's behaviour is never fully documented and the new one has to reproduce it exactly. Strangling it incrementally, one module at a time behind a stable interface, is slower to feel satisfying and much more likely to finish.