How to Screen Candidates for PHP Developers

Screening PHP developers comes down to replacing what a resume claims with evidence you can actually check. That means a short work sample written in real PHP, a structured interview scored against the same rubric for every candidate, and a reference call that asks about specific behaviour instead of general impressions. Do those three things in that order and most hiring mistakes disappear before they reach an offer.

Here is the awkward part. PHP runs most of the server-side web, 69.9% of all sites whose backend language is known, yet only 18.9% of developers said they had worked with it in the past year in Stack Overflow's 2025 developer survey, which drew about 49,000 responses and placed PHP 12th by usage. A huge amount of running code, a much smaller pool of people who touch it. That gap is why PHP hiring attracts so many candidates whose experience is real but a decade out of date, and why a generic "5 years of PHP" filter tells you almost nothing.

TL;DR

• Decide what the role has to produce first, then pick the evidence that proves each skill. Skills come second, not first.
• A 60 to 90 minute work sample in real PHP beats any resume filter, and it is the only stage that reliably separates current PHP from 2015 PHP.
• Check version currency against PHP's published support schedule, not against years of experience. PHP 8.0 and 8.1 are already end of life.
• You do not need to read PHP to screen it well. You need a rubric, a scored work sample, and someone technical for 30 minutes at the end.
• Reference checks are the cheapest signal nobody runs properly. Ask what the person shipped and who else was on the team, not whether they were a good fit.

Which PHP skills should you screen for in 2026?

Screen for five things: current language features, framework depth in whichever framework you actually run, database behaviour under load, security habits, and testing discipline. Everything else is negotiable. A candidate strong in those five will learn your domain in a month, and a candidate weak in them will generate defects for a year.

Start with version currency, because it is the fastest signal and the easiest to verify. PHP's own release policy gives each branch two years of active support and two more of security-only fixes. As of today, PHP 8.4 has active support until 31 December 2026 and 8.5 until 31 December 2027, while 8.2 and 8.3 have dropped to security-only, and 8.0 and 8.1 are past end of life entirely. A developer whose last production work was on 7.4 is not unemployable, but they have missed enums, readonly properties, constructor promotion, first-class callable syntax and fibers. That is a real gap and it is worth knowing about before an offer, not after.

This is where Testlify earns its keep. Rather than starting with a test, it starts with the role: map the job to the competencies that actually matter, then connect each competency to a measurable piece of evidence through assessments, work samples, interviews, references and structured reviewer feedback. The output is a table you can hand to anyone on the hiring team, technical or not, and they will know exactly what they are looking at and why.

Applied to a typical PHP role, it looks like this.

Notice the fourth column. Three of the six competencies can be judged by someone who has never written a line of PHP, provided the rubric is written properly. That matters more than it sounds, because in most companies under 200 people the person running this process is the founder or an ops lead, not a CTO.

How do you source and screen PHP developers?

Run sourcing and screening as one pipeline with a fixed order, so every candidate hits the same gates in the same sequence. Post the role, apply one knockout question, send a scored assessment to everyone who passes it, review work samples blind, then interview the top five and check references on your final two.

PHP developer sourcing platforms: screening processes and reference verification to identify the best candidates

Where you post changes who applies, and each channel needs a different screening emphasis. General job boards bring volume and a wide quality spread, so the assessment stage does the heavy lifting. PHP community spaces (framework forums, local user groups, open-source issue trackers) bring fewer but better-targeted people, and there the work sample can be shorter because the self-selection has already happened. Referrals bring the highest hit rate and the worst blind spots, which is exactly why referred candidates should take the same assessment as everyone else. Skipping the test for a referral is the single most common way a structured process quietly stops being structured.

The sequence that works:

1. Write the requirement, not the wish list. Name the framework, the PHP version, and the one thing this person must ship in their first quarter. A PHP developer job description template is a reasonable starting point, but the first-quarter deliverable is the part that filters.
2. Add one knockout question to the application. Something like "which PHP version does your current production code run on, and what stopped you upgrading?" The answer is hard to fake and tells you more than a CV screen.
3. Send a scored assessment to everyone who passes. Everyone, including referrals. A PHP skills test at the right level, or a junior PHP developer assessment if you are hiring early-career, gives you a number that is comparable across candidates.
4. Review work samples with names hidden. Score against the rubric before you look at who wrote what.
5. Interview the top five, not the top fifteen. Use the same PHP interview questions for each of them and score as you go, not afterwards.
6. Verify references on your final two. Details below, because this is the step almost everybody fumbles.

Reference verification deserves its own discipline. A reference call that asks "was she good to work with?" produces a polite yes and no information. A structured reference asks the referee to rate specific competencies and describe a specific situation, which is much harder to answer vaguely. Testlify handles this as a linked reference assessment rather than a contact form: referees are invited to complete a short structured questionnaire, triggered immediately, on completion of the assessment, at a score threshold, or at a pipeline stage, with minimum and maximum reference counts and automatic invites. The output is comparable across candidates in the way a phone call never is.

One caveat worth stating plainly. References confirm patterns, they do not discover them. If the work sample and the interview both said this person is strong on delivery and weak on communication, references will usually confirm it. If the earlier stages told you nothing, references will not rescue the decision.

How do you compare PHP hiring channels?

Compare channels on three axes: how long they take to produce a signed candidate, what the quality signal actually is before you test, and what you personally have to verify. Cost matters less than most teams assume, because the expensive outcome is a bad hire, not an agency fee.

PHP developer recruiting comparison: candidate quality and time to placement for enterprise buyers assessing software

Larger buyers tend to ask this question in procurement terms, so here it is in those terms. The table compares the routes a company might take, and what each one leaves you to check.

The row that surprises people is referrals. They are fast and they convert, and they are also the route most likely to smuggle an untested hire into a team. Speed is not the same as evidence.

On cost, use public wage data rather than salary aggregator averages, which skew high. The U.S. Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 as of May 2025, with employment projected to grow 10% between 2025 and 2035 against 3% across all occupations. PHP roles typically sit below that median, but the growth number is the one that should shape your process: a tightening market means your screening has to be fast as well as rigorous, because good candidates are gone in two weeks.

Should you hire a freelance PHP developer?

Hire a freelancer when the work has a defined end, and hire an employee when it does not. That sounds obvious and teams still get it backwards, usually by hiring a contractor for an open-ended maintenance role and then wondering why continuity suffers. For a fixed rebuild, a migration off an unsupported PHP version, or a two-month feature push, freelance is usually the better call.

Freelance PHP developer networks: portfolio verification and skill assessment for organizations evaluating solutions

The pitch of a curated freelance network is that vetting has already happened. Sometimes it has. Often "vetted" means a screening call and an English test, which tells you nothing about whether this person can work in your codebase. Treat network vetting as a starting filter, never as the evidence itself.

Portfolio verification is where most of the risk hides, and it is genuinely checkable:

• Ask which parts they wrote. On agency-built sites the honest answer is often "the checkout flow and the admin panel, not the front end". A candidate who claims all of it is telling you something.
• Look at commit history, not the repository. A public repo proves access. A commit history spread over months proves authorship.
• Check the live site still runs. A portfolio full of dead links usually means the work is old, which matters when you are screening for current PHP.
• Ask what they would change now. Strong developers criticise their own two-year-old code readily and specifically. It is one of the more reliable signals available in a 20 minute call.

Then run the same skills assessment you would give a permanent candidate. A freelancer who objects to a 60 minute paid or scoped exercise is telling you about their availability, not their ability, and that is still useful information.

How do you test PHP skills without coding?

You test PHP without reading PHP by scoring evidence rather than code. Use an automated assessment for the technical judgment, a written rubric for the parts you can judge (clarity, security awareness, explanation quality), and borrow a developer for one 30 minute review at the end. That combination works, and it is how most small teams should run it.

The research backs the structure more than the intuition. A 2022 reanalysis of personnel-selection validity in the Journal of Applied Psychology recalculated decades of meta-analytic estimates after finding systematic overcorrection in earlier work. Structured interviews came out at .42, ahead of general mental ability tests at .31 and integrity tests at .31, with conscientiousness far behind at .19. The practical reading: a job-specific, structured, consistently-scored process predicts performance better than a general-purpose aptitude score. Structure is the lever, not cleverness.

Three techniques work well for a non-technical screener:

• The flawed-snippet review. Give the candidate 15 lines of PHP containing an SQL injection, an unescaped output and a hardcoded credential. Ask what they would fix first and why. You do not need to spot the bugs yourself, because the rubric lists them; you are scoring whether the candidate finds them and how they prioritise.
• The explain-it-simply question. "Explain to me, as if I do not write code, why an N+1 query is a problem." Communication is a competency you are fully qualified to judge, and it correlates with how this person will behave in a planning meeting.
• The tradeoff question. "When would you not write a test?" Anyone who says "always test everything" is reciting. Anyone who talks about throwaway scripts and stable third-party code has actually shipped things.

Testlify's automated scoring covers the part you cannot judge. It scores open-ended answers and source code across roughly 15 languages, and an AI checker classifies each written answer as human, AI-generated or mixed, distinguishing fully generated text from partially AI-edited text. All of it is advisory by design: the product states that AI scores and insights are for guidance only and that human judgment makes the final decision, and both "display AI scores to the reviewer" and "include AI score in the final average" are toggles you control. If you would rather run AI scoring as a hint and keep the numbers out of the average, you can.

What does a good PHP work sample look like?

A good PHP work sample takes 60 to 90 minutes, uses a realistic slice of the kind of work the job involves, and produces something a rubric can score consistently. It should never be a four-hour unpaid project, and it should never be an abstract algorithm puzzle that has nothing to do with building web applications in PHP.

Concretely, a strong sample for a mid-level role: here is a small Laravel or Symfony service with a seeded database and one failing test. Fix the bug, add one test, and leave a two-sentence note on what you would refactor if this were production. That exercise touches framework knowledge, database behaviour, testing discipline and communication in about an hour, and every one of those is on the competency table above.

Pro tip: seed the database with about 5,000 rows rather than 20. An N+1 query is invisible at 20 rows and obvious at 5,000, so the dataset does the screening for you and you never have to ask a leading question about it.

On tooling, the details matter more than the category. Testlify's coding questions run in an embedded VS Code editor in the browser and support multi-file projects, so the exercise can look like real work rather than a text box. You can attach up to 20 test cases per question, visible or hidden, score them individually, include SQLite database test cases for query work, and decide whether candidates can run the tests themselves. There is also a vibe coding mode, where candidates direct AI tools toward a working solution instead of writing every line by hand, which is worth considering if that is how your team already builds. Browse the coding assessments if you want to see the formats, or the PHP and WordPress test if your codebase is WordPress-heavy.

Cheating deserves an honest answer rather than an arms race. Proctoring presets range from standard to strict, and the measures include tab-switch detection, full-screen enforcement, AI-tool detection and dual-device monitoring, where the candidate's phone acts as a second camera and the session will not start until it is active. Useful for high-stakes or high-volume hiring. Probably overkill for a five-person team hiring one developer, where a scoped exercise and a follow-up conversation about the submitted code catches nearly everything. The follow-up conversation is the control that costs nothing: ask someone to walk through a decision in code they supposedly wrote, and authorship becomes obvious in about four minutes.

One more caution on scoring. Testlify's own reports surface item-level psychometrics (difficulty index, discrimination index and a quality-risk flag for questions with very low accuracy or high skip rates), and those numbers are worth reading before you trust a cutoff. A question everyone fails is usually a bad question, not a weak candidate pool.

How do you run PHP reference checks?

Run references on your final two candidates only, ask the same questions of each referee, and ask about behaviour rather than character. Two structured references per finalist, each taking about 15 minutes, is the right amount of effort. More than that and you are delaying an offer you have already decided to make.

Four questions that produce real information:

• "What did they ship while you worked together, and who else was on that project?" Scope inflation collapses fast under a follow-up question about team size.
• "What did they need help with?" Everyone needs help with something. A referee who cannot name anything either did not work closely with them or is managing the answer.
• "How did they handle a production incident or a missed deadline?" You are listening for ownership and communication, not for a heroic story.
• "Would you work with them again, and in what kind of role?" The second half is the useful half. "Yes, but in a team with a strong tech lead" is a genuinely helpful answer.

Where structured reference assessments beat calls is comparability. When both finalists' referees have rated the same competencies on the same scale, you have something to weigh. When one referee gushed on a Tuesday call and the other was terse on a Friday, you have noise. That said, references carry the weakest signal of any stage here, because candidates choose their own referees. Treat them as a confirmation step and a way to surface anything alarming, never as a tiebreaker between two strong finalists.

Red flags when screening PHP developers

Some warning signs are reliable and some are folklore. These are the ones worth acting on, with the reasoning, because a red flag you cannot explain is just a bias with better branding.

• Cannot name the PHP version in their current production environment. Anyone shipping code knows this, or knows where to look. Not knowing suggests distance from deployment.
• Talks about frameworks exclusively, never about the language. Framework fluency without language fluency breaks the moment something goes wrong below the abstraction.
• Builds SQL by concatenating strings in the work sample. This is not a style preference. It is an injection vulnerability, and in 2026 it signals someone who stopped learning a long time ago.
• Work sample is flawless and the follow-up conversation is vague. The mismatch is the signal, not the perfection.
• Cannot explain a past technical decision without blaming someone. Watch for whether they can articulate the constraint they were under. Blame without constraint is a pattern that will repeat on your team.

And two that are commonly treated as red flags but should not be. A gap in employment history says nothing about capability, and plenty of strong developers have one. An empty GitHub profile says even less: most professional PHP is written in private repositories for employers, so public code is a nice-to-have signal and never a requirement. Screening on it quietly filters for people with free time.

Worth naming the broader shift too. The World Economic Forum's Future of Jobs Report 2025 found employers expect 39% of workers' core skills to change by 2030, with 59% of the workforce needing training in that window. For PHP hiring that argues for weighting how quickly someone learns over which exact framework version they used last, because the framework will change underneath them anyway.

Hire PHP developers on evidence, not gut feel

Pick one role you are hiring for now, write the competency table for it, and attach a scored assessment to the application before the next candidate arrives. That single change does more than any interview technique, because it makes every candidate comparable on the same evidence. If you want to see how the pieces fit, browse the PHP skills test or book a demo and walk through a real PHP screening flow with someone. For the wider hiring picture beyond screening, the full PHP hiring guide covers salary bands and offer structure.

Key takeaways

• Start with the role, not the test. Mapping competencies to evidence before you pick an assessment is what keeps the process honest, because it forces you to say in advance what would count as proof. Teams that pick the test first end up rationalising whatever score comes out.
• Version currency beats years of experience. PHP 8.0 and 8.1 are end of life and 8.2 is security-only, so a decade of PHP tells you nothing about whether someone writes current code. Ask what runs in production today and why it has not been upgraded; the answer is hard to rehearse.
• A 60 to 90 minute work sample is the highest-value stage you have. It is the only step that shows you how someone actually writes, and it doubles as the fairest stage in the process because everyone gets the same task. Anything longer starts costing you good candidates who have other offers.
• Structure outperforms expertise in the screener. Validity research puts structured interviews ahead of general aptitude testing, which means a non-technical founder with a good rubric will out-screen a senior developer improvising questions. Write the rubric down before the first call.
• Never exempt referrals from the assessment. Referrals are the fastest channel and the one most likely to put an untested person on your team, and one exception is usually all it takes for the process to stop being a process.
• Treat references as confirmation, not discovery. Candidates choose their referees, so references reliably confirm patterns your earlier stages already found and rarely reveal new ones. Run two structured ones on finalists only and keep the questions identical.
• Design screening for speed as well as rigour. With software employment projected to grow well above the all-occupation average, a process that takes six weeks will lose its best candidates to a process that takes two. Rigour and speed are not opposites; unstructured processes are slow precisely because nobody can compare anything.

Frequently asked questions (FAQs)