How to Evaluate PHP Developers: Evidence Beyond a CV

Revision: a practical assessment method, a fictional maintenance exercise and a reusable brief.

Evaluate PHP developers against the decisions they will own in your application. A CV can point to relevant experience; a focused work sample can show how someone understands an unfamiliar codebase, protects access boundaries, tests a change and explains its release implications.

Start with the developer assessment brief (editable Markdown). It contains candidate instructions, an observation worksheet and a clearly fictional example. Prepare the exercise repository separately. The template works for other development roles too: replace the technology and acceptance criteria with those of the actual job.

1. Match the assessment to the role

Write three responsibilities the person must handle during their first month. Maintaining a Laravel application, extending a WordPress integration and designing a new PHP API require different evidence. Specify the framework and runtime versions, database, deployment process and review support the role will have.

For a maintenance role, prioritize tracing existing behavior and making a contained change. For an integration role, examine request mapping, failure handling and retries. For someone leading delivery, include estimates, migration sequencing and how they review another developer's work. Do not expect one short exercise to establish all of these capabilities.

Our PHP developer sourcing guide helps turn that role into a search brief. The freelance developer platform comparison covers where to look. Apply the same relevant assessment criteria to candidates arriving through different channels.

2. Make codebase comprehension observable

Ask the candidate to trace one supplied request from its entry point through validation, authorization, database access and response generation. Their explanation should identify the files involved, the existing convention they plan to follow and the behavior they intend to preserve.

Useful evidence includes a reproducible failing case, a short dependency map and a reason for choosing the change location. Watch whether the candidate investigates an assumption before editing. A large rewrite can obscure a small defect; ask what makes each changed file necessary.

Prior work can support the discussion when the candidate is allowed to share it. Ask which part they personally delivered, what constraints shaped it and how a reviewer could inspect the result. Accept a synthetic example or written walkthrough when previous work is confidential. A lack of public client source code does not establish a lack of experience.

3. Inspect request boundaries and database reasoning

Separate three decisions: whether input has the required shape, who the caller is, and whether that caller may perform this action on this record. A valid identifier and an authenticated account do not answer the permission question. OWASP's authorization guidance recommends checking permissions on every request and denying access when no permission applies.

Give the candidate an allowed case and a denied case that differ in only one meaningful detail: workspace, role or membership status. Review the actual server-side lookup and returned fields. Hiding a button is insufficient evidence that the underlying request is protected.

For database access, inspect parameter handling, record relationships and constraints. The PHP manual's SQL injection guidance distinguishes binding data values from validating other dynamic SQL choices against allowed values. Ask the candidate to explain how the application's existing query layer handles both.

For a write-heavy role, add a separate discussion of simultaneous requests: what prevents duplicate records, lost updates or a repeated external action? Laravel documents transaction boundaries and rollback behavior, but naming a transaction is not a demonstration that a particular race is handled. Ask for the expected competing-request outcome and the database-specific test that would establish it. Keep that work outside a small read-only exercise unless it was included in the paid scope.

4. Include release judgment and handover

Ask what must happen between an approved patch and a useful release: dependency or configuration changes, schema compatibility, worker restarts, cache preparation and a smoke check relevant to the feature. The candidate should identify which steps apply to this change and explain why others do not.

If a migration is involved in the real role, discuss what the old application would do while it runs and what reverting the code would leave behind. For the narrow exercise below, no migration is required. Recognizing that boundary is useful evidence of scope control.

A handover should let another developer understand the defect, reproduce the checks and locate remaining uncertainty. “Tests pass” needs the commands, environment and observed results behind it. An honestly documented check that could not run is more informative than an unsupported completion claim.

5. Offer a bounded, paid maintenance exercise

Fictional example: prepare a disposable PHP application whose JSON draft-report preview accepts workspace_id and report_id. A manager can currently retrieve another workspace's report by changing the identifier. The task is to repair that access boundary while preserving the documented allowed response.

For this example, the buyer supplies a PHP 8.3/Laravel 12 fixture, lockfiles, SQLite test database, setup instructions, seeded fictional workspaces and a working baseline test command. The buyer verifies that baseline before assignment. These versions describe the supplied exercise. Existing authentication, roles and response conventions are part of the fixture; replacing them is outside scope.

Agree two paid hours for investigation, the patch, checks and notes, plus up to 20 paid minutes for one written review round. Record the fee, payment date and permitted use of the submission before starting. Payment covers the agreed work regardless of the hiring decision. If the environment fails to start, pause the exercise and resolve the supplied setup problem.

Allow documentation and state the policy for assistants or other tools in advance. Assess whether the candidate can explain and verify the submitted work. At the time limit, accept the current patch and a precise list of unfinished checks; do not turn a partially completed assessment into an open-ended unpaid assignment.

6. Publish the acceptance examples before work begins

The following are proposed criteria for the fictional fixture. Prepare the accounts and records in advance, and give every candidate the same expected behavior.

Request a focused patch, regression checks and a short README describing the cause, commands run, observed outcomes and limitations. Exclude production deployment, real customer records, new features, framework upgrades and a redesign of the authentication system. The exercise repository should contain only fictional data and test credentials.

7. Use a rubric based on observable work

Record each area as demonstrated, partially demonstrated, not observed or critical issue, with an evidence reference. A combined numerical score can conceal an unresolved access failure.

• Understanding: the explanation connects the failing request to the relevant code and existing conventions.
• Correctness: allowed behavior remains intact, and denied cases exercise the server-side boundary with appropriate fixture records.
• Change quality: the patch is proportionate, readable and avoids unrelated dependency or schema changes.
• Verification: submitted checks target the reported defect; results distinguish execution, failure and checks that were not run.
• Delivery judgment: release notes identify applicable steps, remaining risks and information the next reviewer needs.

For this exercise, cross-workspace data disclosure, weakening an existing permission check, destructive changes outside scope or knowingly misrepresenting test results are critical issues. They prevent treating the submission as evidence of readiness for independent maintenance. An incomplete optional improvement is different from failing the core access requirement.

8. Write the decision and its limits

The reviewer should record the role requirement, concrete evidence, unresolved gaps and a decision: proceed, request a narrowly defined paid follow-up, or decline for this role. If reviewers disagree, identify the disputed observation and reproduce it against the same fixture. Share relevant factual feedback with the candidate and allow them to clarify a misunderstood result.

A successful small exercise supports a bounded hiring decision. It does not demonstrate production incident handling, capacity planning or every aspect of application security. Assign responsibilities and review support accordingly.

Use the editable assessment brief to capture those decisions. Our freelance hiring workflow covers the engagement that follows. For a team delivery discussion, our Laravel development services page describes the application work to scope.