Thirty questions in six sets for the owner or lead running the interview: modern PHP, framework and stack fit, security, legacy code and upgrades, working style, and a 1-to-5 scorecard. Every question comes with why it is worth asking and what a strong answer sounds like. Download as DOCX.
The first PHP interview I ever ran, I did what almost every owner does: I pulled a list of questions off the internet and asked what the difference is between two comparison operators. The candidate answered it perfectly. He also could not tell me how he would stop a customer form from being turned into a database query, which was the only thing that actually mattered for the application we were running.
That is the trap with this hire. PHP has a huge supply of trivia questions and almost none of them predict anything, because a candidate can retrieve any of them in seconds. What still separates people is judgment: what they do first with an application they have never seen, how they plan an upgrade off an unsupported version, and whether they can explain a trade-off to somebody who does not write code.
At FirstHR we build for small businesses that hire without an HR department, where the owner usually runs the whole interview alone. This page gives you thirty questions in six downloadable sets, each with the reason it earns a slot and what a strong answer sounds like, plus a 1-to-5 scorecard. The matching PHP developer job description templates cover the posting side of the same hire.
TL;DR
Interview a PHP developer on six things: modern PHP fluency, framework and stack fit, security and data handling, legacy code and upgrade judgment, testing and working style, and communication. Skip syntax trivia, because anyone can look it up. Weight security hardest if the application touches money or customer data, and score every candidate on the same 1-to-5 rubric.
Decide Which PHP Job You Are Hiring For
PHP developer is not one job, and the four versions of it need different interviews. Framework product work, CMS and agency work, legacy maintenance, and e-commerce all carry the same title and reward almost opposite strengths, so decide which one you are filling before you pick a single question.
Framework product work
Laravel or Symfony
Building and running an application on a modern framework. Weight modern PHP, stack fit, and testing. This is the version of the role closest to general backend engineering.
CMS and agency work
Sites and content platforms
Themes, plugins, integrations, and client sites. Weight stack fit and security, and ask hard about when to write custom code instead of installing another extension.
Legacy maintenance
The app that already exists
Keeping an older application alive, fixing what breaks, and moving it onto a supported version. Weight the legacy, debugging, and upgrade set above everything else.
E-commerce and payments
Money is involved
Checkout, orders, and payment integrations. Weight security and data handling hardest, because the cost of a mistake is measured in chargebacks and customer trust.
Getting this wrong is the most common way a PHP interview wastes everyone's time. An excellent agency developer can look weak against framework architecture questions, and a strong product engineer can look weak against questions about theme and plugin trade-offs, when in both cases the interview simply asked about the wrong job.
If the job is
Weight these sets hardest
Care less about
Framework product work
Modern PHP, stack fit, testing
CMS extension trade-offs
CMS and agency work
Stack fit, security, working style
Deep framework architecture
Legacy maintenance
Legacy and debugging, security
Latest language features
E-commerce and payments
Security, legacy and debugging
Front-end polish
First developer at the company
Working style, security, legacy
Narrow specialization
What to Assess in a PHP Developer
Assess six things: modern PHP fluency, framework and stack fit, security and data handling, legacy and debugging judgment, testing and code quality, and communication with a non-technical owner. Those six are what the scorecard on this page rates, and they hold across all four versions of the role.
Notice what is missing. There is no recall category, because syntax recall no longer separates candidates and never predicted much. The most reliable approach is a structured interview built on questions with no single correct answer, scored on a consistent rubric, so you are comparing evidence instead of comparing how much you enjoyed the conversation.
Version Support Has Hard End Dates
PHP runs on a fixed lifecycle: two years of active support, then two more of security fixes only. As of August 2026, PHP 8.5 (released 20 November 2025) and PHP 8.4 are in active support, PHP 8.3 and PHP 8.2 are in security-fix-only mode, and PHP 8.2 leaves support entirely at the end of 2026. PHP 8.1 and everything older are already end of life. If your application sits on an unsupported version, the upgrade question in Set 4 stops being a nice signal and becomes the most important question in the interview.
Which Question Set to Use
The six sets below cover thirty questions plus a scorecard. Pick two or three sets that match the job, then use the same ones for every candidate so the comparison holds. Every question carries the reason it is worth asking and what a strong answer sounds like.
Set 1: Modern PHP fundamentals
Are their habits current?
Version fluency, structure judgment, dependency management, error handling, and query thinking. Six questions that work without asking anyone to recite syntax.
Set 2: Framework and stack fit
Can they work on yours?
Framework depth, the path a request takes, plugin versus custom code, secrets, deployment, and performance. Fill in your own stack before you ask.
Set 3: Security and data handling
The set nobody should skip
Injection, password storage, output escaping, request forgery, file uploads, and dependency risk. The highest-value questions on the page for a small business.
Set 4: Legacy, debugging, upgrades
Most PHP hiring is maintenance
Inheriting an unfamiliar application, production-only bugs, version upgrades, rewrite judgment, and working safely in untested code.
Set 5: Testing and working style
Standards without supervision
What they test, how they review code, explaining trade-offs to a non-technical owner, staying current, disagreement, and how they use AI assistants.
Set 6: Scorecard and red flags
Score, do not guess
A 1-to-5 rubric across all six areas, a junior to senior calibration guide, and the seven red flags worth stopping an interview over.
Write the Weights Down Before the First Interview
Decide in advance which two sets matter most for this specific role, and write it at the top of the scorecard. Without that, the sets you happen to ask first quietly become the ones you weight most, and candidate one gets judged on a different basis than candidate four. If the application takes payments or stores customer records, security is the set to weight hardest, regardless of what else the job involves.
30 Questions and a Scorecard to Download
Download all six as one file or copy the sets you need. Each set lists the questions, why each one earns a slot, what a strong answer sounds like, what a weak one sounds like, and space for notes. The final file is the scorecard with a junior to senior calibration guide.
Download All Question Sets and the Scorecard
Five question sets by competency plus a 1-to-5 scoring rubric with level calibration and red flags. All in one DOCX.
Set 1: Modern PHP Fundamentals Questions
Version fluency, structure judgment, dependency management, error handling, query thinking, and one question about code they would write differently today. None of it requires reciting syntax.
Modern PHP Fundamentals Questions
PHP DEVELOPER INTERVIEW: MODERN PHP FUNDAMENTALS
Candidate: __
Interviewer: __
Date: __
Ask the same questions of every candidate and write the answers down. Six
questions, each with the reason it earns a slot and what a strong answer
sounds like.
QUESTIONS TO ASK
1. Which PHP version are you most current on, and what did you start using
once you moved to PHP 8?
Why ask it: PHP changed more between 5.x and 8.x than most languages do in
a decade. This question separates a developer whose habits are current from
one whose habits froze years ago, without asking anyone to recite trivia.
Strong answer: names concrete features and where they helped, such as typed
properties, constructor property promotion, enums, match expressions, named
arguments, or readonly properties. Says what they stopped doing as a result.
Weak answer: talks about PHP in the abstract, or describes patterns that
only made sense before namespaces, Composer, and autoloading existed.
2. When would you reach for an interface or an abstract class, and when would
you just write a plain function?
Why ask it: it tests judgment about structure rather than knowledge of
syntax. Over-engineering a small codebase is as expensive as under-building
it, and a small business feels both.
Strong answer: ties the choice to how many implementations actually exist
and how likely the code is to change. Admits that a small app often does not
need an abstraction yet.
Weak answer: applies patterns by reflex, or cannot give an example where the
simpler option was the right call.
3. How do you manage dependencies and autoloading in a PHP project?
Why ask it: Composer and PSR-4 autoloading are the baseline of professional
PHP. A candidate who does not use them is telling you about the codebases
they came from.
Strong answer: describes Composer, a committed lock file, semantic
versioning, and a deliberate approach to updating packages rather than
running an update and hoping.
Weak answer: manual includes, vendored copies of libraries, or no answer
about how versions are pinned.
4. What is the difference between how you would handle an error and how you
would handle an exception in production code?
Why ask it: error handling is where sloppy PHP shows up first, and where a
small business gets silent failures nobody notices for a month.
Strong answer: catches what it can act on, lets the rest bubble up, logs
with context, and never shows a stack trace to a user. Mentions setting a
handler and turning display of errors off in production.
Weak answer: suppresses errors, wraps everything in a catch-all, or has no
view on what should be logged.
5. How do you decide what belongs in the database query versus in PHP?
Why ask it: the most common performance problem in a small PHP application
is a loop that fires one query per row. This question surfaces whether the
candidate thinks about that at all.
Strong answer: pushes filtering, joining, and aggregation to the database,
watches for the N+1 pattern, and knows how to see the queries a page runs.
Weak answer: pulls whole tables into PHP and filters in a loop, or has never
looked at the queries a page actually executes.
6. Tell me about a piece of PHP you wrote that you would write differently
today. What changed?
Why ask it: it tests self-awareness and growth, and it is hard to fake.
Strong answer: a specific piece of code, a specific reason it aged badly,
and a specific different approach. Owns the decision rather than blaming a
deadline or a teammate.
Weak answer: cannot think of anything, or answers with a generic statement
about always learning.
NOTES
[Capture the examples, the versions named, and any red flags here.]
Set 2: Framework and Stack Fit Questions
Framework depth, the path a request takes through the application, plugin versus custom code, secrets across environments, deployment, and performance. Fill in your own stack before you ask.
Framework and Stack Fit Questions
PHP DEVELOPER INTERVIEW: FRAMEWORK AND STACK FIT
Candidate: __
Interviewer: __
Date: __
Fill in your own stack before the interview: framework, database, hosting,
and CMS or e-commerce platform. Then ask about yours, not about PHP in
general.
QUESTIONS TO ASK
1. What is your strongest PHP framework, and what did you actually build in it?
Why ask it: a candidate strong in the framework you already run is
productive in days. One learning it from scratch costs weeks you will not
get back.
Strong answer: names a framework, describes real features shipped in it, and
is honest about the parts they have not touched. Explains how they would
come up to speed on yours if it is different.
Weak answer: lists every framework as a strength, or names one but cannot
describe anything built with it.
2. Walk me through how a request moves through the application you worked on
most recently, from the URL to the response.
Why ask it: this single question tells you whether the candidate understood
the system or only touched the files they were assigned.
Strong answer: routing, middleware or filters, controller, the service or
model layer, the database, the view or serialized response. Mentions where
caching and authentication sit.
Weak answer: stops at the controller, or describes the folder layout instead
of the flow.
3. If we run a CMS or an e-commerce platform, how do you decide between a
plugin, a theme change, and custom code?
Why ask it: the CMS and e-commerce side of PHP is where a small business
most often gets an unmaintainable site, and the failure is usually a
decision, not a coding mistake.
Strong answer: prefers the supported extension point, avoids editing core,
weighs the upgrade cost of a plugin against writing a small amount of custom
code, and thinks about who maintains it a year from now.
Weak answer: modifies core files, or reaches for a plugin for everything
without asking who supports it.
4. How do you handle configuration and secrets across local, staging, and
production?
Why ask it: leaked credentials in a repository are a common and entirely
avoidable incident, and a small business rarely has anyone checking.
Strong answer: environment variables or a secrets store, nothing sensitive
in version control, different credentials per environment, and a documented
way to rotate them.
Weak answer: config values committed to the repository, or one set of
credentials shared across every environment.
5. What does your deployment look like, and what happens when a deploy goes
wrong?
Why ask it: at a company without a dedicated operations team, the PHP
developer is often the person who ships. Their deployment habits become
yours.
Strong answer: a repeatable pipeline, migrations run in a known order, a way
to roll back, and cache or opcode cache handled deliberately. Has a story
about a bad deploy and what they changed afterward.
Weak answer: files copied over by hand, no rollback plan, or has never been
responsible for a release.
6. How do you approach performance when a page gets slow?
Why ask it: it separates a developer who measures from one who guesses, and
guessing is expensive.
Strong answer: measures first with profiling or query logging, finds the
actual bottleneck, then fixes it. Mentions opcode caching, query tuning,
caching layers, or moving slow work into a queue.
Weak answer: jumps straight to adding a cache or a bigger server without
knowing what is slow.
NOTES
[Capture the frameworks named, the request walkthrough, and any red flags.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Injection, password storage, output escaping, request forgery, file uploads, and dependency risk. Weight this set hardest if the application touches money or customer records.
Security and Data Handling Questions
PHP DEVELOPER INTERVIEW: SECURITY AND DATA HANDLING
Candidate: __
Interviewer: __
Date: __
PHP powers a large share of the public web, which makes PHP applications a
constant target. These are the questions a small business cannot afford to
skip, because there is usually no security reviewer behind the developer.
QUESTIONS TO ASK
1. A customer form writes to the database. How do you make sure it cannot be
used for SQL injection?
Why ask it: this is the single highest-value question on the page. Injection
has been a top web application risk for two decades and it is still the way
small sites get emptied.
Strong answer: prepared statements with bound parameters through PDO or the
framework query builder, every time, with no string concatenation of user
input into SQL. Validates input as a separate concern from escaping.
Weak answer: escaping functions alone, hand-built query strings, or the
claim that the framework handles it without knowing how.
2. How do you store user passwords?
Why ask it: it is a one-sentence question that instantly sorts current
practice from practice that stopped a decade ago.
Strong answer: the built-in password hashing functions with a modern
algorithm, never a raw hash such as md5 or sha1, no home-grown salting
scheme, and rehashing when the algorithm or cost changes.
Weak answer: any raw hash function, encryption instead of hashing, or a
custom scheme they invented.
3. Where does output escaping happen in your applications, and what does it
protect against?
Why ask it: cross-site scripting is the failure that turns a marketing site
into a malware host, and it is a habit rather than a feature.
Strong answer: escape on output, in the template layer, matched to the
context, and relies on auto-escaping templating rather than remembering
every spot. Names cross-site scripting as the risk.
Weak answer: sanitizes on input only, trusts data because it came from the
database, or disables auto-escaping for convenience.
4. What is cross-site request forgery, and how do you defend against it?
Why ask it: a candidate who cannot explain it has probably been relying on
framework defaults without understanding what they do, which breaks the
moment they write a custom endpoint.
Strong answer: explains a forged authenticated request from another site,
then names per-session tokens on state-changing requests and sensible cookie
attributes.
Weak answer: confuses it with cross-site scripting, or has no defense beyond
checking the referring page.
5. A user uploads a file. Walk me through what you check before you keep it.
Why ask it: file upload is where a lot of small PHP sites get compromised
outright, and the checks are easy to describe if you have actually done it.
Strong answer: validates type by inspecting the file rather than trusting
the submitted content type, restricts extensions, renames the file, stores
it outside the web root or in object storage, and caps the size.
Weak answer: trusts the browser-supplied type, keeps the original filename,
or writes uploads into a publicly executable directory.
6. How do you keep dependencies from becoming a security problem?
Why ask it: most PHP code in an application is not code the developer wrote,
and a stale package is the quiet risk nobody owns at a small company.
Strong answer: an audit step in the pipeline, regular scheduled updates,
awareness of which packages are abandoned, and a rule about adding a
dependency for something small.
Weak answer: never updates because it might break, or adds packages freely
with no review of what they pull in.
NOTES
[Capture the security answers verbatim where you can. This set is the one to
weight most heavily if the application touches customer or payment data.]
Set 4: Legacy Code, Debugging, and Upgrades Questions
Inheriting an unfamiliar application, production-only bugs, planning a version upgrade, rewrite judgment, and changing code that has no tests around it. This is the set most maintenance hires live in.
Legacy Code, Debugging, and Upgrades Questions
PHP DEVELOPER INTERVIEW: LEGACY CODE, DEBUGGING, AND UPGRADES
Candidate: __
Interviewer: __
Date: __
Most PHP hiring at a small business is maintenance hiring: an application that
already exists, that somebody else wrote, and that has to keep running. Weight
this set heavily if that describes your situation.
QUESTIONS TO ASK
1. You inherit an application you have never seen and a bug report. What are
the first three things you do?
Why ask it: it is the most realistic prediction of week one on your team.
Strong answer: reproduce the bug first, read the surrounding code and the
logs, check version control history for what changed, and confirm the fix
against the reproduction. Asks questions before changing anything.
Weak answer: starts rewriting, or proposes a rebuild before understanding
what the application does.
2. How do you debug a problem that only happens in production?
Why ask it: every small business has one of these, and the answer reveals
discipline under pressure.
Strong answer: logs with enough context to be useful, error tracking,
reproducing against production-like data, and adding instrumentation rather
than guessing. Knows the difference between what to log and what never to
log, such as credentials or personal data.
Weak answer: adds output statements to a live site, or edits code directly
on the server.
3. We are on an older PHP version. How would you plan the upgrade?
Why ask it: version support has hard end dates, and an unsupported runtime
is a business risk rather than a technical preference.
Strong answer: inventory the code and the dependencies, run a compatibility
scan, upgrade in staged steps behind tests, deal with deprecations in
batches, and do it on a staging environment first. Estimates honestly and
flags the parts that are unknown.
Weak answer: proposes a full rewrite, or treats the upgrade as a weekend
task with no assessment.
4. When is a rewrite the right call, and when is it the wrong one?
Why ask it: a developer who wants to rewrite everything they inherit can
cost a small business a year. One who never refactors leaves you with the
same problem compounding.
Strong answer: defaults to incremental improvement, replacing a piece at a
time behind a stable interface, and reserves a rewrite for cases where the
platform itself is unsupported or the business need has changed completely.
Weak answer: rewrite as a first instinct, or refusal to touch anything.
5. Tell me about the worst code you have had to maintain. What did you do
about it?
Why ask it: it shows both technical judgment and temperament, and the way a
candidate talks about other people’s code predicts how they will talk about
yours.
Strong answer: a concrete example, a pragmatic plan such as adding tests
around the risky area before changing it, and a result. Critical of the code
without being contemptuous of the people.
Weak answer: pure complaint with no plan, or a story that ends in an
abandoned rewrite.
6. How do you handle a change that touches a part of the system with no tests?
Why ask it: this is the real condition of most small business codebases,
and it separates careful developers from lucky ones.
Strong answer: adds a test around the existing behavior first, makes the
change small and reversible, and verifies manually where automation is not
practical yet. Communicates the risk before shipping.
Weak answer: ships and hopes, or blocks entirely until a full test suite
exists.
NOTES
[Capture the inherited-code answer in detail. It is the best single predictor
of how the first month will go.]
Set 5: Testing, Code Review, and Working Style Questions
What they test and what they skip, how they review a pull request, explaining a trade-off to a non-technical owner, staying current, handling disagreement, and how they use AI coding assistants.
Testing, Code Review, and Working Style Questions
PHP DEVELOPER INTERVIEW: TESTING, CODE REVIEW, AND WORKING STYLE
Candidate: __
Interviewer: __
Date: __
At a small company the developer is often the only person who reads the code.
These questions test whether they hold their own standard when nobody is
checking, and whether they can explain technical work to a non-technical owner.
QUESTIONS TO ASK
1. What do you test, and what do you deliberately not test?
Why ask it: an answer of everything is as unhelpful as an answer of nothing.
You want to hear priorities.
Strong answer: covers the logic that would cost real money if it broke, such
as billing, permissions, and data integrity, plus a thin layer of end-to-end
coverage on the critical paths. Skips trivial getters and unstable interface
details.
Weak answer: no testing at all, or a claim of full coverage with no example
of what was worth covering.
2. What do you look for when you review someone else’s pull request?
Why ask it: even a solo developer eventually reviews contractor work, and
this question shows what standard they carry.
Strong answer: correctness first, then security and edge cases, then
readability and naming, then style, in roughly that order. Separates opinion
from a real defect and says so in the comment.
Weak answer: only style nitpicks, or a rubber stamp with no criteria.
3. Explain a technical trade-off you made to a non-technical stakeholder. How
did you frame it?
Why ask it: at a small business the developer talks to the owner, not to a
product manager. This skill is part of the job, not a bonus.
Strong answer: translates the trade-off into cost, risk, and time, offers
options rather than a verdict, and does not hide behind jargon.
Weak answer: cannot give an example, or describes the conversation as the
business side not understanding.
4. How do you keep your PHP current when the work itself is maintenance?
Why ask it: maintenance roles can quietly freeze a developer’s skills, and
you are hiring for the next several years, not this quarter.
Strong answer: a real habit, such as following release notes, upgrading a
side project, reading source of packages they depend on, or contributing
fixes upstream. Specific rather than aspirational.
Weak answer: says they learn on the job with no example of anything learned
recently.
5. Describe a time you disagreed with a technical decision. What happened?
Why ask it: it reveals how the candidate handles being overruled, which
matters more on a two-person team than on a twenty-person one.
Strong answer: made the case with reasoning, accepted the decision, and
documented the risk. Ideally returned to it later with evidence.
Weak answer: went around the decision, or dropped it without ever raising
the concern.
6. How do you use AI coding assistants, and how do you check what they produce?
Why ask it: assistants have made syntax recall a poor screening signal, and
the useful question now is whether the candidate reviews generated code or
ships it unread.
Strong answer: uses them for scaffolding and unfamiliar syntax, then reads
every line, tests it, and is specifically wary of generated database and
authentication code. Can name a time the output was wrong.
Weak answer: pastes output without review, or refuses to discuss it.
NOTES
[Capture the stakeholder-communication answer. It is the one most owners
underweight and later regret.]
Set 6: Scorecard, Level Calibration, and Red Flags
A 1-to-5 rubric across all six areas, a junior to mid-level to senior calibration guide, and the seven red flags worth ending an interview over. The asset most question lists leave out.
PHP Developer Interview Scorecard and Red Flags
PHP DEVELOPER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Role type: [ ] Framework product [ ] CMS or agency [ ] Legacy maintenance [ ] E-commerce
Date: __
Score each area from 1 (poor) to 5 (excellent) with a note citing something
the candidate actually said. Score before you discuss with anyone else.
SCORING AREAS
Modern PHP fluency Score: [ 1 2 3 4 5 ]
Notes: __
Framework and stack fit Score: [ 1 2 3 4 5 ]
Notes: __
Security and data handling Score: [ 1 2 3 4 5 ]
Notes: __
Legacy code and debugging Score: [ 1 2 3 4 5 ]
Notes: __
Testing and code quality Score: [ 1 2 3 4 5 ]
Notes: __
Communication and working style Score: [ 1 2 3 4 5 ]
Notes: __
LEVEL CALIBRATION
Junior: writes correct code for a defined task, needs review, learns fast.
Expect gaps in security and deployment. Only hire at this level if someone
will review the work.
Mid-level: ships a feature end to end without supervision, debugs an
unfamiliar area, and knows the security basics without prompting.
Senior: makes the architecture and upgrade calls, weighs cost against risk,
explains trade-offs to a non-technical owner, and raises the standard of the
people around them.
RED FLAGS
•Cannot describe how to prevent SQL injection with prepared statements.
•Stores passwords with a raw hash or a home-grown scheme.
•Proposes a full rewrite before understanding the existing application.
•Edits code directly on the production server.
•Names every framework as a strength but cannot describe one project.
•Talks about the previous team or the previous codebase with contempt.
•Cannot name a single thing learned in the past year.
SUMMARY
Total score: ______ / 30
Overall recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Note: if more than one person interviews, each scores independently before the
group talks. Compare written evidence first, opinions second.
How to Judge Answers If You Do Not Write PHP
Judge the shape of the answer, not the code. Three signals carry most of the weight and none of them require the language: specificity, meaning real projects and real trade-offs instead of generalities; explicit reasoning about why one option beat another; and method, meaning the candidate reproduces a problem before changing anything.
How do you make sure a customer form cannot be used for SQL injection?
Strong answer: Prepared statements with bound parameters, every time, through PDO or the framework query builder, with no user input concatenated into a query string. A strong answer also treats validation as a separate job from escaping, and can say what happens if a single query is built by hand for a reporting screen.
Weak answer: Escaping functions on their own, hand-built query strings, or the claim that the framework takes care of it with no idea how. Any of the three is a stop.
You inherit an application you have never seen and a bug report. What are the first three things you do?
Strong answer: Reproduce the bug before touching anything, read the surrounding code and the logs, check version control history for what changed recently, then confirm the fix against the original reproduction. A strong answer asks questions first and keeps the change small.
Weak answer: Starts rewriting, or proposes replacing the application before understanding what it does. This is the most expensive habit a small business can hire.
What did you start using once you moved to PHP 8?
Strong answer: Names specific features and where they helped: typed properties, constructor property promotion, enums, match, named arguments, readonly properties. A strong answer also says what they stopped doing, which is the part that shows the habit actually changed.
Weak answer: Speaks about PHP in the abstract, or describes patterns from before namespaces and Composer. Fine for a junior hire with a reviewer, a real concern for a senior one.
The most useful follow-up in any technical interview is some version of what did you try that did not work. A candidate who has genuinely done the work has a dead end to describe. One who has rehearsed a story usually does not.
The Security Questions Nobody Should Skip
Five security questions carry most of the value: injection defense, password storage, output escaping, request forgery, and file upload handling. A candidate who cannot answer the first two concretely should not be hired to touch customer data, whatever else they scored.
This matters more at a small business than at a large one, for a reason that has nothing to do with the code. There is no security reviewer sitting behind the developer, no separate team reading the pull request, and often no one who would notice a bad pattern for months. The interview is the review.
Ask this
Listen for
Stop signal
How do you prevent SQL injection?
Prepared statements with bound parameters, always
Escaping alone, or hand-built query strings
How do you store passwords?
Built-in hashing with a modern algorithm
Raw md5 or sha1, or a home-grown scheme
Where does output escaping happen?
On output, in the template layer, by context
Sanitizing on input only, or auto-escaping turned off
What is cross-site request forgery?
Forged authenticated request, defended by tokens
Confuses it with cross-site scripting
What do you check on a file upload?
Verified type, renamed, size-capped, outside web root
Trusts the submitted content type
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
A small work sample predicts better than either a whiteboard puzzle or a large take-home project. Cap it at about two hours, say so up front, make it resemble the real job, and score the debrief conversation rather than the polish of the submission.
Security instincts and review standard, in 30 minutes
Yes, cheap and revealing
Add one endpoint to a skeleton app
Framework fluency and structure judgment
Yes, if stack fit is the question
Multi-day unpaid take-home project
Who had a free weekend
No, it filters for time, not skill
Algorithm puzzle on a whiteboard
Performance under artificial pressure
No, it does not resemble the job
Whatever format you choose, the debrief is where the value is. Ask why they made each choice, what they would do with another four hours, and what they deliberately left out. Those answers separate candidates far more cleanly than the code does, and they work even for an interviewer who cannot read the diff.
Follow-Ups and Red Flags
The prepared questions get you started; the follow-ups are where you learn what is real. Push for the specific project, the specific failure, and the specific outcome, and watch for the patterns that consistently predict an expensive hire.
Follow-ups worth asking
What did you try that did not work?
How did you know the fix was the real fix?
Who reviewed it, and what did they catch?
Security signals
Prepared statements named without prompting
Escapes on output, in the template layer
Treats dependency updates as scheduled work
Maintenance signals
Reproduces before changing anything
Adds a test around risky code first
Prefers incremental replacement to a rewrite
Red flags
Cannot explain injection defense concretely
Edits code directly on the production server
Contempt for the previous team or codebase
One red flag deserves special weight at a small company. A candidate who talks about a previous codebase or a previous team with contempt will talk about yours the same way, and at a company where the developer works largely alone, that attitude has nothing to push back against.
PHP Developer Pay
There is no federal wage series for PHP, because occupations are classified by the work rather than by the programming language. Benchmark against the nearest classifications and pick the one that matches the job you defined at the top of this page, then read the percentile ladder as a leveling map rather than as a single market rate.
Nearest Federal Classifications, National Wages
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), national median annual wages were $135,980 for software developers, $100,390 for computer programmers, and $92,650 for web developers. The tenth to ninetieth percentile range ran $82,460 to $214,670 for software developers and $48,100 to $162,290 for web developers (U.S. Bureau of Labor Statistics, OEWS national estimates).
Percentile
Software developers
Web developers
Read it as
10th
$82,460
$48,100
Junior, or a narrow scope
25th
$105,210
$64,230
Early career with review
50th (median)
$135,980
$92,650
Solid mid-level
75th
$171,980
$126,230
Senior individual contributor
90th
$214,670
$162,290
Specialist or high-cost market
The gap between those two columns is the whole point: two jobs that can carry the same PHP developer title sit roughly $43,000 apart at the median. A framework product role benchmarks toward the software developer figures, while agency and CMS site work benchmarks toward the web developer figures. The back end developer templates cover the language-agnostic version of the same decision.
One classification note before you set the offer. Most PHP roles at this level are exempt from overtime under the federal computer employee exemption, which turns on duties and on a salary of at least $684 per week or an hourly rate of at least $27.63, not on the job title (U.S. Department of Labor). Check the duties against the test rather than assuming. This is general information, not legal advice.
Fair, Legal, and Structured Interviewing
Fair, legal, and structured are the same practice viewed from three angles. Asking every candidate the same job-related questions in the same order keeps you compliant, reduces bias, and produces better hires at the same time. It is the part almost every interview question list omits.
Ask about the work, not about the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and questions that probe them create risk even when they are asked as small talk. Keep away from age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Developer interviews have a specific trap: graduation year, how long someone has been writing code, or a joke about learning PHP before a candidate was born all edge toward age. Ask what they have built and how they would approach your problem instead. Every question in these sets is written to stay on the work. This is general information, not legal advice.
Same core questions, same order, every candidate
A structured interview, where every candidate answers the same job-related questions scored against the same rubric, predicts on-the-job performance better than a conversation that goes wherever the rapport takes it. It also protects you, because a consistent, job-related process is far easier to defend than a set of ad hoc chats. For a technical hire this matters more than usual, since a candidate who shares your background is easy to over-rate and one who does not is easy to under-rate. Write the questions before the first interview, ask them in the same order, and score them the same way.
Keep the take-home small and paid where required
A work sample is the best predictor you have for a developer, but an unpaid multi-day project is both a bad filter and a fairness problem, because it selects for candidates with free time rather than skill. Cap the exercise at about two hours, tell candidates the cap, and score the debrief conversation rather than the polish of the code. Some jurisdictions and some worker classifications require payment for work performed, so if your exercise is real production work rather than a self-contained exercise, pay for it. When in doubt, keep it synthetic and short. This is general information, not legal advice.
Score independently, then discuss
When two or more people interview, each fills in the scorecard alone before the group talks. Otherwise the most technical voice in the room anchors everyone, which is how strong candidates get talked out of and weak ones get talked in. Compare the written evidence first and the impressions second. For an owner who is also the only interviewer, the scorecard does a different job: it forces you to write down what the candidate actually said, so you can compare candidate three against candidate one two weeks later without relying on memory.
Structure Beats Conversation
A structured interview, where every candidate answers the same job-related questions scored against a consistent rubric, is a more reliable predictor of on-the-job performance than an unstructured conversation, and asking the same job-related questions of everyone also keeps you inside the EEOC rules against basing decisions on protected characteristics. The difference between the two formats is mostly whether the questions existed before the candidate walked in.
For a developer interview, the specific trap is age. Graduation year, how many years someone has been writing code, and jokes about which version of PHP they started on all point at the same protected characteristic. Ask what they have built and how they would approach your problem instead. This is general information, not legal advice.
Interviewing Without an HR Department
At a large company a developer candidate runs through coordinated panels with a recruiter collecting the scorecards. At a small business the owner usually runs the interview alone, between everything else, and often cannot read the code being discussed. Here is how to make that interview as rigorous as a full hiring team's.
You are hiring a PHP developer and you do not write PHP yourself
Most owners running this interview cannot grade the code, which is exactly why every question in these sets ships with the reason it is worth asking and what a strong answer sounds like. You are not judging syntax. You are judging whether the answer is specific, whether it names real trade-offs, and whether the candidate reproduces a problem before changing it. Those three signals separate a careful developer from a confident one, and you can hear all three without knowing the language. If you want a second opinion on the technical depth, borrow a developer you trust for 30 minutes on the shortlist rather than for the whole funnel.
The trivia questions on most lists no longer filter anything
The classic PHP screening questions, the difference between two comparison operators or what a particular array function returns, have stopped separating candidates. Anything a candidate can look up in seconds tells you nothing about how they work. The questions that still discriminate are the ones with no single correct answer: how would you plan this upgrade, what would you check before keeping this uploaded file, when is a rewrite the wrong call. Those require judgment built from experience, and judgment is what you are actually buying. Every set on this page is built that way on purpose.
Whoever you hire will probably be your only developer
At a small business the PHP developer often has no one reviewing their work, no one to escalate to, and a direct line to the owner. That changes what you interview for: security habits matter more because nobody is checking them, communication matters more because the developer talks to you rather than to a product manager, and maintenance judgment matters more because there is no team to absorb a bad rewrite. Once you choose someone, FirstHR handles the people side: the offer and any confidentiality agreement signed electronically, onboarding tasks for repository and server access, and every signed document stored on the employee profile. FirstHR is an onboarding and HR platform, not a code hosting or development tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
If you are still assembling a candidate pool rather than choosing between finalists, the sourcing side is a separate problem with its own playbook, covered in the guide to finding developers for a small company. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
The interview is step one. Once you choose someone, the work shifts to hiring well: a clear offer letter, signed policies, access granted at the right level before day one, and a structured first month. For a developer, that first month decides how quickly they can ship anything at all.
Send the offer
Put the role, level, pay, and start date in writing and get it signed electronically, so both sides are working from the same document.
Plan access before day one
Repository, server, database, and deployment access as onboarding tasks, granted at the right level and revocable in one place.
Get the policies signed
Confidentiality, acceptable use, and any intellectual property assignment acknowledged before the first commit, not after.
Store the records
Offer, signed policies, I-9, W-4, and the interview scorecards kept together on the employee profile and easy to find later.
FirstHR connects the offer, the e-signature, the onboarding tasks, and the document storage in one place, so a small business can run the whole path from decision to first day without a spreadsheet and a folder of email attachments. Browse the rest of the hiring templates for the postings, evaluation forms, and reference-check documents that go around this one. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Decide which PHP job you are filling first: framework product, CMS and agency, legacy maintenance, or e-commerce, because the four need different question weights.
Skip syntax trivia. Questions with one lookup-able answer no longer separate candidates and never predicted much.
Weight security hardest whenever the application touches money or customer records, because at a small business the interview is the only review.
Judge the shape of the answer, not the code: specificity, explicit trade-offs, and reproducing a problem before changing it.
Cap the work sample at about two hours and score the debrief conversation rather than the polish of the submission.
Ask every candidate the same job-related questions in the same order and score all six areas from 1 to 5 with written evidence.
Frequently Asked Questions
What questions should I ask a PHP developer in an interview?
Ask across six areas rather than testing syntax recall. Modern PHP fluency: which version they are current on and what they started using in PHP 8. Framework and stack fit: their strongest framework, what they built in it, and how a request moves from URL to response. Security: how they prevent SQL injection, how they store passwords, and what they check on a file upload. Legacy and debugging: what they do first with an unfamiliar application and a bug report, and how they would plan a version upgrade. Testing and working style: what they deliberately do not test, and how they explain a trade-off to a non-technical owner. Finally, score every candidate on the same 1-to-5 rubric. The six downloadable sets on this page carry all thirty questions with the reason each is worth asking.
Are PHP trivia questions still useful for screening?
No, and they were never as useful as they looked. Questions with one lookup-able answer, such as the difference between two comparison operators or what a particular array function returns, now filter almost nobody, because any candidate can retrieve them in seconds. They also fail in the other direction: a strong developer can blank on a definition they use correctly every day. The questions that still discriminate have no single right answer and require judgment built from experience, such as how you would plan an upgrade off an unsupported version, when a rewrite is the wrong call, or what you check before keeping an uploaded file. Ask those, then listen for specificity, named trade-offs, and a habit of reproducing a problem before changing it.
How do I interview a PHP developer if I do not write PHP myself?
You judge the shape of the answer rather than the code. Every question in these sets ships with what a strong answer sounds like and what a weak one sounds like, so you can compare against a written reference instead of your own technical judgment. Three signals carry most of the weight and none of them require the language: specificity, meaning real projects, real numbers, and real names rather than generalities; trade-off awareness, meaning the candidate explains why they chose one option over another; and method, meaning they reproduce a problem before changing anything. If you want technical depth verified, bring in a developer you trust for a single 30-minute conversation with your shortlist rather than for the whole process, and keep the structured scoring in your own hands.
What are the most important PHP security questions to ask?
Five carry most of the value. How do you prevent SQL injection: you want prepared statements with bound parameters, every time, not escaping alone. How do you store passwords: the built-in password hashing functions with a modern algorithm, never a raw hash such as md5 or sha1 and never a home-grown scheme. Where does output escaping happen: on output, in the template layer, matched to context, to defend against cross-site scripting. What is cross-site request forgery and how do you defend against it: per-session tokens on state-changing requests. And what do you check before keeping an uploaded file: type verified by inspection rather than the submitted content type, renamed, size-capped, and stored outside the web root. A candidate who cannot answer the first two concretely should not be hired to touch customer data.
Should I give a PHP developer a coding test or a take-home project?
A small work sample beats both a whiteboard exercise and a large take-home. Whiteboard puzzles test performance under artificial pressure rather than the job, and multi-day unpaid projects filter for candidates with free time rather than for skill. Cap the exercise at roughly two hours, tell candidates the cap up front, and make it resemble the actual work: fix a bug in a small existing codebase, review a short piece of code and list what you would change, or add one endpoint to a skeleton application. Then score the debrief conversation rather than the polish of the submission, because asking why they made each choice reveals far more than the diff does. If the exercise is real production work rather than a self-contained one, pay for it.
How do I tell a junior PHP developer from a mid-level or senior one?
Read the answers for scope of ownership rather than years on a resume. A junior writes correct code for a well-defined task, needs review, and typically has gaps in security and deployment, so only hire at that level if someone will review the work. A mid-level developer ships a feature end to end without supervision, debugs an area they have never seen, and names the security basics without being prompted. A senior makes architecture and upgrade calls, weighs cost against risk out loud, explains trade-offs to a non-technical owner, and raises the standard of the people around them. The clearest single discriminator is the inherited-application question: juniors describe editing files, mid-level developers describe reproducing and isolating, and seniors describe reducing risk across the whole change.
What should a PHP developer earn?
There is no federal wage series for PHP, because occupations are classified by the work rather than by the language, so benchmark against the nearest classifications and pick the one that matches the job. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), national median annual wages were $135,980 for software developers, $100,390 for computer programmers, and $92,650 for web developers. A framework product role benchmarks toward the software developer figures, while agency and CMS site work benchmarks toward the web developer figures, a gap of roughly $43,000 at the median for two jobs that can carry the same title. Read the percentile ladder as a leveling map, then adjust for your local market and post the range where pay transparency rules require it.
What questions are off limits in a developer interview?
Avoid anything that probes a characteristic protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Developer interviews have a specific version of this trap around age, so keep away from graduation year, how many years someone has been writing code, and jokes about which version of PHP they started on. You may ask whether a candidate can perform the essential functions of the job and whether they are authorized to work in the United States. The safest and most effective approach is the same one that produces better hires: ask every candidate the same job-related questions in the same order and score them on the same rubric. This is general information, not legal advice.
