October 9, 2026·6 min read
A PHP interview in 2026 still looks a lot like a PHP interview in 2014. Explain the service container. What is the difference between include and require. Write a small CRUD controller.
Meanwhile the thing that actually breaks is the half of the application nobody looks at. The queue worker that exited after a deploy and was never restarted. The scheduled job that silently stopped when the server moved timezone. The listing page that issues four hundred queries because somebody added a relationship to a Blade template.
The site is up the whole time. That is what makes it expensive: nothing alerts, and the first report comes from a customer.
Because PHP interviews inherited a shape from an era when the hard part really was the language. Namespaces, autoloading, the container, the request lifecycle.
Modern Laravel has absorbed most of that. What is left is operational: workers, schedulers, storage, deploys and the places where an elegant abstraction meets two application servers. That part is almost never interviewed for, and it is where the money goes.
The setup. A Laravel application where the web side is perfectly healthy. The worker process is not running, failed jobs have been accumulating, and the feature that depends on them (exports, emails, webhooks) silently does nothing.
Ask: customers say their exports never arrive and the site looks fine to us. Start wherever you want.
Strong looks like: they check whether a worker is running before they read any job code. They look at the failed jobs table and read an actual exception rather than theorising. Then they fix both halves: the job, and the fact that nobody was told. They know a queue needs its own monitoring, because a web health check says nothing about it, and they can name what they would alert on: worker uptime, queue depth, failure rate.
Weak looks like: restarting the worker and declaring it fixed. The backlog drains, everybody relaxes, and it recurs on a day nobody connects to this one.
Why it works: silent background failure is the most common serious Laravel incident and the least interviewed. It also shows whether somebody thinks past the request cycle.
The setup. A listing page with a relationship accessed inside a loop in the template. On seed data it is instant. On a realistic table it takes seconds and the database shows hundreds of small identical queries.
Ask: this page is slow in production and fast here. Explain why, then fix it.
Strong looks like: they enable query logging or open the debug bar and count queries before touching code. They name lazy loading as the cause, fix it with eager loading, and measure again. The best candidates also say how to stop it coming back, for example by failing loudly on lazy loads in a non-production environment, which Laravel supports directly.
Weak looks like: caching the rendered page. It works, until the data changes, and it hides a problem that will reappear in every other listing in the application.
Why it works: the ORM hides cost by design, and whether someone looks through that abstraction is the clearest line between a productive mid-level developer and a senior one.
The setup. Two application servers, one database. A deploy where the migration ran on one host, or a schema change made by hand on production months ago that no migration describes. The application works until it reaches the code path that expects the new column.
Ask: staging and production disagree about the schema. How did that happen, and how do we stop it happening again?
Strong looks like: they compare rather than assume, checking the migrations table against the schema. They can explain why running migrations from an application server during deploy is risky with more than one host, and they propose where it should run instead. They also ask what else was changed by hand, because there is rarely only one.
Weak looks like: adding the column manually to make the error go away, which is how the drift happened in the first place.
Why it works: this is the task that reveals whether someone has run PHP in production or only developed it locally, and it maps directly onto how your deploys behave today.
The setup. File uploads written to the local disk behind a load balancer with two application servers. Half the uploads appear to disappear, depending on which host serves the next request. Sessions behave the same way if they are file based.
Ask: users say images upload successfully and then show as missing about half the time. Go.
Strong looks like: they notice the pattern is roughly fifty percent and reason about it as a routing and shared-state problem rather than a bug in the upload code. They can explain the fix in terms of shared object storage or a shared session store, and they mention the migration path for the files already written to one host. The same shared-state reasoning turns up one level down in the distributed systems assessment.
Weak looks like: sticky sessions as a first answer. It makes the symptom rarer and leaves the data on one machine.
Why it works: it is a true infrastructure question that a PHP developer meets constantly, and it cannot be answered from framework documentation.
Four rows, the same for every candidate:
None of those rows is "knows Laravel". Fluency shows up for free the moment they open the project.
Each of these needs a real environment. Two application servers, a queue with a backlog, a database with enough rows for lazy loading to hurt, a stopped worker. None of it is expressible in a code sample.
EasyEnv gives the candidate a real Linux box with the application deployed, the worker already stopped, the failed jobs already recorded, the schema already drifted and the uploads already on local disk. Every candidate starts from the same recipe, so the problems do not drift between interviews. The box is disposable, so handing over full shell access costs you nothing. Sessions are recorded, so you can see whether they read the failed job or guessed.
The limits, plainly. This is a 45 to 60 minute session and needs a reviewer who has operated PHP, not only written it. Building the broken environment is real work the first time. And for a role that is purely front-of-site template work, tasks three and four are more than the job needs.
Stop asking what the service container does. Give the candidate a stopped queue, a page issuing four hundred queries, a schema that drifted and uploads that land on one server out of two.
If you only run one, run the stopped queue. Whether someone checks that a process is alive before reading its code is the fastest way to tell who has run PHP in production.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
.NET gives you so much for free that the mistakes hide inside the framework rather than in the code under review. Here are four tasks on a running service, a deadlock under load, a captured dependency, a query that drags the whole table into memory, and a background worker that died quietly.
Node interviews ask candidates to recite the event loop, then production fails in ways no recitation covers. Here are four tasks on a running service, an unhandled rejection, a heap that only climbs, a retry storm and a blocked event loop, with what separates a strong answer from a plausible one.
Read more
Java interviews still run on trivia that a study guide covers in an evening, while the expensive problems live in transaction boundaries, pool exhaustion and upgrades nobody dares start. Here are four tasks on a running Spring service, and what each one separates.
Read more
