How to Hire a Legacy PHP Developer Who Can Modernize Safely

Hiring a legacy PHP developer is different from hiring someone to start a greenfield application. The job is not simply to write current PHP syntax. It is to understand unfamiliar behavior, reduce risk, improve the system in useful slices, and keep the business running while the code changes.

A strong interview should test those abilities directly. Framework trivia, puzzle questions, and a weekend rewrite project reveal little about how a candidate will handle production software with hidden dependencies and incomplete tests.

Define the work before defining the candidate

“Legacy” can mean a ten-year-old monolith, an unsupported framework, procedural scripts, a WordPress plugin with many extensions, or a mostly healthy application held back by one runtime constraint.

Before writing the job description, document:

• Supported PHP and database versions
• Frameworks, CMS components, and major dependencies
• Test coverage and deployment process
• Business-critical workflows
• Known security or reliability risks
• External integrations and extension points
• The expected balance of maintenance and feature work
• On-call, communication, and documentation expectations

This prevents a common mismatch: hiring for abstract “modern PHP” expertise when the actual work is careful discovery, compatibility management, and incremental delivery.

Look for modernization judgment

The most valuable signal is not whether a candidate wants to replace the current architecture. It is whether they can explain what to learn before deciding.

Ask: “You inherit a revenue-critical PHP application with almost no automated tests. What do you do in the first two weeks?”

A strong answer usually includes production observation, a reproducible environment, dependency and runtime inventory, sanitized fixtures, critical-flow smoke tests, and conversations with the people who understand the business. The candidate should separate urgent risk containment from long-term design improvements.

Warning signs include proposing a rewrite before identifying business behavior, treating production as the test environment, or promising a precise completion date without inspecting the system.

Interview questions that expose real skill

Use follow-up questions. The reasoning is more informative than a memorized list.

How would you upgrade the PHP runtime?

Listen for a staged plan: inventory deprecated behavior and extensions, establish test and static-analysis feedback, upgrade dependencies, move one supported PHP version at a time, test in production-like environments, observe after release, and preserve a rollback route.

A good candidate understands that a runtime upgrade, framework upgrade, and architecture refactor are different changes. Combining them can make failures difficult to isolate.

How would you change a class that creates its own database and HTTP clients?

Look for the idea of a seam. The candidate may introduce dependencies at construction, wrap a hard global, or extract one boundary. They should avoid turning every class into an interface without a reason.

What would you test first?

Strong answers start from risk and observable behavior: authentication, billing, permissions, data writes, scheduled jobs, and integration boundaries. They should mention characterization tests for existing behavior and focused unit tests for newly isolated rules.

How do you review a dynamic SQL query?

Expect bound values, allowlisted identifiers, stable ordering, authorization checks, input limits, and examination of the query plan. A candidate should know that placeholders cannot represent a column name or sort direction.

How do you deprecate an extension point?

For WordPress or plugin work, look for preserving argument order, return values, and timing while invoking the supported hook, adding deprecation notices, testing old and new consumers, documenting a removal policy, and waiting for an appropriate major release.

Tell us how you communicate uncertainty

A senior developer should distinguish observed facts, inferences, and recommendations. “I need to inspect the call sites and production traces before choosing” is often a stronger answer than instant certainty.

Use a bounded practical exercise

Give the candidate a small, representative repository that can be completed in roughly 60 to 90 minutes. Do not use proprietary production code, and do not ask for unpaid feature work your company intends to ship.

One useful exercise contains:

• A small PHP endpoint with a database query
• A hidden dependency such as the current time
• One authorization defect
• A fragile test or no test around the target behavior
• A README describing the business rule
• A request to make one defined change safely

For example:

Add an optional status filter to this invoice endpoint. Preserve its existing response format, prevent unauthorized account access, and explain how you would deploy the change. You may refactor only what is needed.

Allow normal documentation and search tools. The job will not be performed from memory, so the exercise should not pretend otherwise. Ask the candidate to leave a short note covering assumptions, tests run, remaining risks, and the next improvement they would make.

Score with a shared rubric

Use the same rubric before reviewing any submission. A practical 100-point distribution is:

The numbers are less important than consistency. Two interviewers should be able to point to evidence for their scores. Discuss major differences before making a decision.

Do not reward a large diff automatically. In legacy work, a small change with a strong safety case is often better than an elegant redesign that expands the failure surface.

Review the exercise as a conversation

Ask the candidate to walk through the change rather than defend it. Useful prompts include:

• What did you decide not to change?
• Which assumption would you verify in the real application?
• Where could this fail under concurrent traffic?
• What would make you roll the deployment back?
• How would your design change if another filter were added?
• Which test gives you the most confidence, and which risk remains uncovered?

Strong candidates can critique their own work without collapsing into vague self-doubt. They can also explain a technical decision in terms of business impact.

Evaluate collaboration, not performance theater

Legacy modernization crosses product, support, operations, and engineering. Include a structured conversation about how the candidate would:

• Ask a domain expert to clarify an undocumented rule
• Report a serious security finding discovered outside the assigned task
• Negotiate a smaller delivery slice
• Document a strange behavior that cannot yet be changed
• Review a teammate's risky migration
• Communicate a rollback to nontechnical stakeholders

Avoid culture-fit questions that reward similarity. Score concrete behaviors: clarity, listening, evidence, ownership, and the ability to disagree without making the work personal.

Verify the experience that matters

Reference checks, where lawful and appropriate, should focus on observable working patterns. Ask whether the candidate improved a difficult system safely, how they handled uncertainty, and whether their changes were understandable to the next developer.

Do not confuse years of PHP use with modernization skill. Someone can repeat the same risky habits for a decade. Conversely, a developer with fewer years may demonstrate excellent testing, security, delivery, and communication judgment.

A good hiring decision

The best legacy PHP developer for your team is not necessarily the person with the most framework names on a résumé. It is the person who can build understanding, protect existing value, expose risk honestly, and make the system easier to change with each delivery.

Design the process around that job. Give every candidate the same realistic problem, the same time boundary, and the same scoring dimensions. You will get a much clearer signal than a trivia round can provide, and the interview itself will reflect the careful engineering culture you want them to join.