How to evaluate candidates’ skills with a PHP assessment

A PHP assessment is a structured, scored test of what a developer can actually build in PHP: writing and debugging code, working with a database, handling user input safely, and using the frameworks your codebase already runs on. It replaces the part of screening where you read a resume and guess.

PHP still runs most of the web. W3Techs puts it at 69.9% of all websites whose server-side language is known, measured in September 2026. So the hiring problem is rarely finding people who list PHP. It is telling apart the developer who has shipped and maintained a real codebase from the one who has read about it.

TL;DR

• A PHP assessment scores job-relevant work: code you can run, a query you can check, an input-handling bug you can see them catch.
• Multiple-choice questions on their own screen for recall, not skill. Pair them with a short coding task that mirrors real work.
• Test the PHP version and framework you actually run in production. A test built on PHP 7 idioms tells you nothing useful about a PHP 8.4 codebase.
• Keep the first screen to 30 to 45 minutes. Longer tests lose good candidates who already have offers.
• Decide your cutoff score and your must-pass sections before the first candidate sits the test, then apply them the same way to everyone.

What is a PHP assessment?

A PHP assessment is a scored, job-relevant test that measures how well a candidate writes, reads, and fixes PHP code. It usually mixes knowledge questions (syntax, language behaviour, common functions) with at least one hands-on task where the candidate writes code that has to run and pass test cases. The output is a score you can compare across candidates.

That last part matters more than it sounds. The value is not the test. The value is that every candidate answered the same questions under the same conditions, so the comparison means something. An unstructured technical chat gives you a feeling about a person. A scored assessment gives you evidence you can put next to another candidate's evidence, and defend later if someone asks why you shortlisted who you did.

It is also cheap relative to the alternative. The Bureau of Labor Statistics puts the median wage for web developers at $92,650 as of May 2025, with about 13,600 openings a year over the decade to 2035. A hire who cannot do the work costs a multiple of a 45-minute screen.

What does a PHP evaluation cover?

A PHP evaluation covers six areas, and the mix should shift with the role. Skip the ones the job never touches. Testing everything is how you end up with a two-hour assessment and a 30% completion rate.

• Core language. Types, arrays and their built-in functions, string handling, control flow, error and exception handling. Sloppy array work shows up here fast.
• Object-oriented PHP. Classes, interfaces, traits, dependency injection, and the modern features in the version you run. PHP 8.4 added property hooks, asymmetric visibility and lazy objects, and a developer who has only worked in PHP 7 will not reach for any of them.
• Frameworks. Laravel, Symfony, or the CMS layer if the job is WordPress or Drupal work. Framework questions should test reasoning about routing, middleware, ORM behaviour and caching, not memorised helper names.
• Databases. Writing a query that answers a real question, using prepared statements, spotting the query that will fall over at 100,000 rows.
• Security. Input validation, access control, password handling, and safe database access. Broken access control is ranked the top application security risk in the OWASP Top 10:2025, with injection at number five, and both are things a PHP developer touches every week.
• Tooling. Composer, PHPUnit, version control, and reading someone else's code. This is the difference between a developer who can start a project and one who can join yours.

The evaluation of PHP skills goes wrong most often at the framework layer. A candidate who is strong in Laravel can look weak on a Symfony-flavoured test, and you will have rejected someone who would have been productive in three weeks. Test the framework you run, or test the language and let the framework be a learnable gap.

What should a PHP skills test include?

A PHP skills test should include a short knowledge section, one code-writing task with runnable test cases, and one debugging or code-review task. Weight them by what the role does daily. A maintenance-heavy job deserves more debugging; a greenfield build deserves more design reasoning.

This is where the Testlify Competency-to-Evidence Matrix earns its keep. The matrix starts with the role rather than the test: list the competencies the job actually needs, then attach each one to evidence you can measure, whether that is an assessment section, a work sample, an interview question or a reference. Every competency has to produce evidence. Anything on your list that produces none gets cut, and that single rule is what keeps a test from bloating into trivia.

Pro tip: include one task drawn from your own codebase, stripped of anything private. A real function with a real bug tells you more in ten minutes than twenty generic questions, and candidates notice the difference too.

Which test format fits which role?

Format is the decision most teams get wrong, because they pick the one that is easiest to send rather than the one that answers their question. Each format proves something different and costs something different.

For most teams the answer is a short knowledge section plus a coding task, then a live session only for finalists. That combination takes about 45 minutes of the candidate's time and none of your engineers' time until the shortlist is already scored.

Coding tasks are worth setting up properly. In Testlify, a coding question can be a single file or a multi-file project, candidates work in an embedded VS Code editor, and you can attach up to 20 test cases, visible or hidden, with per-test-case scoring and SQLite database test cases for query work. There is also a vibe coding format, where the candidate directs AI tools toward a working solution instead of typing every line, which is closer to how a lot of PHP work now actually gets done.

How long should a PHP assessment test be?

A first-round PHP assessment test should run 30 to 45 minutes. That is long enough for a knowledge section and one real coding task, and short enough that a developer who is already interviewing elsewhere will finish it. Past an hour, completion rates fall and the people who drop out are usually the ones with options.

Split the time rather than stretching it. Fifteen minutes of knowledge questions, twenty-five minutes of code, done. If you need more signal after that, the next step is a paid take-home or a live session with a finalist, not a longer screen. Only 19.1% of professional developers reported working extensively with PHP in the 2025 Stack Overflow Developer Survey, so the pool is smaller than the language's web footprint suggests. Treat every completed assessment as something you had to earn.

One practical note on versions: run the test on the PHP version you deploy. PHP 8.2 drops to security fixes only at the end of December 2026, and 8.4 and 8.5 are the branches in active support. Testing a candidate on behaviour that changed three versions ago scores them on the wrong thing.

How do you score and shortlist candidates?

Set the cutoff before you send the first invitation. Decide what score moves someone forward, which sections are must-pass regardless of the total, and who reviews borderline results. Writing that down in advance is what stops the score from quietly becoming a justification for a decision you already made.

Weighting beats a flat average. A test that is 60% hands-on coding and 40% knowledge ranks candidates differently than a straight total, and it ranks them closer to how they will perform. Testlify supports both, either score-based weighting where each test's impact follows its total score, or explicit weights from x0 to x5 per test. The same applies to negative marking, which has two modes worth understanding before you switch it on: full credit for at least one correct answer, or full credit only when every correct answer is selected and no wrong one is.

Read the section breakdown, not the headline number. Two candidates on 72% are not the same candidate if one lost their points on framework trivia and the other lost theirs on input validation. Percentile benchmarking helps here, because it tells you how a score compares against everyone else who took the same test rather than against a number you picked out of the air.

Testlify also surfaces item-level statistics most platforms keep to themselves: a difficulty index, a discrimination index, and a quality-risk flag for questions with very low accuracy or high skip rates. If a question is failing everyone, it is usually the question that is broken, and that is worth knowing before you reject a batch of candidates on it.

Where the assessment fits in your hiring process

Send it after a quick application review and before the first human conversation. That order is the whole point: it means the first call happens with someone whose skills are already evidenced, and your engineers stop spending Thursday afternoons on candidates who cannot write a loop.

1. Write the role down as competencies, not as a wish list of technologies.
2. Build or pick the assessment from those competencies, with the version and framework you actually run. A back-end developer job description is a useful starting point for the competency list.
3. Invite every applicant who clears the basic screen, not just the ones with familiar employers on the resume.
4. Score, then review the section breakdown for anyone near the cutoff.
5. Run the live session with the top few, using their own submitted code as the conversation starter.
6. Keep the evidence with the candidate record so the decision is reviewable later, and sync results into the ATS your team already runs.

Take an agency that maintains 30 client sites on a legacy PHP codebase and needs someone who can take it over without breaking it. Their assessment should be mostly debugging and code review, with a small security section, and almost no greenfield design questions. The same role at a product company building something new would flip that balance completely. Same job title, different evidence.

How do you stop cheating on a remote test?

Assume AI assistance is available to every candidate, because it is. The useful question is not whether they used a model, it is whether the test still separates people when they do. Tasks that require reading unfamiliar code, explaining a tradeoff, or fixing a bug in context hold up far better than "write a function that reverses a string".

Beyond task design, the controls that matter are structural. Variable question banks draw a different set for each candidate, though smaller banks raise the odds of overlap, so a bank needs to be several times larger than the question count to be worth it. Testlify's proctoring runs as three presets (Standard, Strict, or fully custom) covering full-screen enforcement, tab-switch detection, face and photo-ID verification, copy-paste tracking, multi-monitor restriction and AI-tool detection. Dual-device proctoring turns the candidate's phone into a second camera pointed at both them and their screen, and the session will not start until it is active.

Keep the framing honest, though. A flag is evidence for a human to review, not a verdict. Testlify's own reports say as much: a yellow flag reads "a quick manual review is recommended", and automatic termination is a separate setting a recruiter has to switch on deliberately. Rejecting someone because software raised a flag, without a person looking at what actually happened, is how you lose a good hire and earn a complaint.

What goes wrong with PHP tests?

Most failed assessments fail for the same handful of reasons, and none of them are about the technology.

• Trivia instead of skill. Asking for the argument order of an obscure function tests memory of a manual page any developer would open anyway. Ask what happens when the input is null.
• Testing the framework you wish you ran. A Symfony test for a Laravel job filters for the wrong person.
• Unpaid four-hour take-homes. They read as disrespect to experienced developers, who quietly decline and take the other offer.
• Different rules for different candidates. Extra time for one person and not another destroys the comparison, and it is the part a tribunal would ask about first.
• Using the score as the decision. The score narrows the field. A person makes the call, with the code, the conversation and the references in front of them.

There is a real tradeoff buried in all this. Every control you add (longer tests, stricter proctoring, more sections) buys you signal and costs you candidates. For a niche senior role in a tight market, a 20-minute focused screen with light proctoring will get you further than a rigorous one nobody finishes. For a high-volume junior intake where a hundred people apply, the stricter setup pays for itself. Pick deliberately rather than defaulting to maximum.

Hire PHP developers with confidence

Pick the assessment that matches your codebase and send it to the next batch of applicants. Testlify's PHP test covers core language and web development skills, with an intermediate coding algorithms assessment and a full-stack PHP assessment when the role stretches past the back end. There are role-specific options across the wider test library if the job mixes PHP with other skills.

Want to see how the scoring, proctoring and reporting work on a real role before you commit? Book a demo and walk through it with your own job description.

Key Takeaways

• Evidence beats impressions. A scored assessment lets you compare two candidates on the same basis, which a technical chat never does. That comparison is also what makes the decision defensible months later, so the record you keep matters as much as the score itself.
• Match the test to the codebase. PHP 8.2 moves to security-only fixes at the end of December 2026, and the framework layer is where candidates get mis-scored most often. Test the version and framework you actually deploy, and treat a different framework as a learnable gap rather than a rejection.
• Format is a decision, not a default. Multiple-choice questions measure recall, coding tasks measure building, debugging tasks measure the reading work that fills most of a maintenance job. Pick the one that answers your question, then keep the first screen to 30 to 45 minutes so good candidates finish it.
• Set the bar before you send the test. Deciding the cutoff, the must-pass sections and the reviewer in advance stops the score from being reverse-engineered into a decision already made, and gives borderline candidates a fair second look.
• Design for AI, do not just police it. Tasks requiring judgment and context survive AI assistance better than syntax puzzles. Proctoring flags are evidence for a human to review, never an automatic rejection.
• Every control costs candidates. Stricter and longer buys signal and loses applicants. In a tight senior market that trade rarely pays; in a high-volume junior intake it usually does.

FAQs