Vet Laravel Developers: Tests and Red Flags

To vet Laravel developers, test how they handle queries, queues, security and upgrades on code you give them, not how well they recite framework trivia. Most candidates can explain what a service provider is, but far fewer can tell you why a page runs dozens of queries, or what happens to a job that fails halfway through a database transaction.

We run Laravel projects for clients in the US, the UK and the Gulf, and we sit on both sides of this conversation: clients interview our engineers, and we interview engineers before they join the team. This is how we vet Laravel developers on our side, written so you can run it yourself, whichever route you take. If you would rather start from engineers who have already been through it, you can hire dedicated Laravel engineers and interview them directly. For the wider choice of model, our post on remote, in-house and hybrid teams comes first. This post is about the vetting itself.

What a dedicated Laravel developer is actually hired to do

A dedicated developer works inside your repository, your board and your release process for months, not for a single deliverable. That changes what you are testing. A freelancer on a fixed brief needs to finish a feature, whereas a dedicated Laravel developer needs to keep a codebase healthy while features land on top of it, which is mostly about judgment: when to add a queue, when a model has taken on too many responsibilities, when an upgrade can no longer wait.

If you are still weighing the framework itself, our post on why Laravel is the go-to framework for modern web applications covers that; this one assumes you have chosen it.

Before any interview, write down the three things the role will do in its first six months. A SaaS back end with billing and roles needs different depth from a legacy PHP rescue or an API for a mobile app. Try to vet developers without that list and you end up with a generic Laravel quiz, which favours people who prepare for quizzes.

Skills to test when you vet Laravel developers

Six areas separate people who have shipped and maintained Laravel applications from people who have followed tutorials. For each one, ask for evidence, not definitions.

Eloquent and the N+1 problem

Ask the candidate to describe the last slow page they fixed. A developer with real experience will talk about query counts, eager loading with with() and the tool they used to see the queries. Laravel’s own documentation shows the scale of the problem: looping over 25 books and reading each author’s name runs 26 queries, where eager loading needs two.

Then ask what stops it from coming back. The strong answer is a guard in the application, such as Model::preventLazyLoading(), which the Eloquent docs show switched on everywhere except production, so that lazy loading throws in development and in tests instead of surfacing as a slow page six months later.

Queues, Horizon and jobs that fail

As a product grows, it almost always ends up with background jobs: emails, exports, webhooks, billing runs. Ask what happens when one fails. By default Laravel attempts a job once, so a developer who has run queues in production should be able to explain how they set tries and backoff, where failed jobs go and who looks at them.

Push on two cases. First, a job dispatched inside a database transaction can be picked up by a worker before the transaction commits; the framework’s answer is the afterCommit option. Second, a job that runs twice must not charge a customer twice. ShouldBeUnique keeps a duplicate off the queue and WithoutOverlapping stops two copies running at once, but neither makes the charge itself idempotent, and a candidate who has run billing jobs will draw that line without being asked. If Redis queues are in play, ask how they watch them. Horizon is the usual dashboard, and its docs warn that a worker timeout has to stay a few seconds shorter than the queue’s retry_after, or the same job can be processed twice. Someone who has run it in production will know why.

Testing with Pest or PHPUnit

Either tool is fine. What matters is whether tests exist in the candidate’s world and what they are for. Ask them to show a feature test they wrote and the bug it caught. A weak candidate describes coverage percentages; a strong one describes the checkout flow that broke after a refactor and the test that now guards it. If they cannot say how a pull request gets tested before merge, expect to build that habit for them.

Migrations that do not hurt on a live table

Ask how they would add a column, or change one, on a table with millions of rows in a system that cannot go down. Good answers split the change into steps that can each be deployed and rolled back on their own: add the column as nullable, deploy code that writes both, backfill in batches, then tighten. They also write a working down() method, keep data changes out of schema migrations and know which operations lock the table on the database they use.

Security: mass assignment and authorization

Two checks cover most of the damage a careless developer can do. The first is mass assignment. Eloquent only fills attributes listed in $fillable, and by default silently discards the rest. A developer who sets $guarded = [] to make that friction go away, then passes $request->all() into create(), has let any user write any column they can name, including an is_admin flag. The second is authorization. Ask where a rule such as “only the owner can edit this order” lives. The right place is a policy, called with Gate::authorize() or the can middleware, on the server. The wrong place is a hidden button in the interface.

Versions and upgrades

Laravel ships a major release every year, around the first quarter. Its support policy gives each release 18 months of bug fixes and two years of security fixes. In October 2026 that means Laravel 11 is out of support, having received its last security fixes on March 12, 2026. Laravel 12 stopped getting bug fixes on August 13, 2026 and gets security fixes until February 24, 2027. Laravel 13, released on March 17, 2026, requires PHP 8.3.

So ask which version the candidate’s last project ran, which they upgraded from, and what broke. Someone who has done a major upgrade will mention reading the upgrade guide, running the test suite first and stepping through versions one at a time. Someone who has never upgraded is the person most likely to leave your application on an unsupported version.

A short exercise for Laravel developers on real work

A puzzle tells you how someone solves puzzles. A small piece of your own work tells you how they will behave on the job. Two formats work, and which to use depends on how much time candidates have.

The take-home

Give them a small repository with a deliberately flawed feature: an endpoint that lists orders with their customers and items, a policy missing from one route, a job that sends an invoice email. Ask for a pull request, not a finished product, with a description of what they changed and why. Cap it at two or three hours, and pay for it if it runs longer. When the pull request comes back, read the description before the code, because it shows how they will write to a team that is not in the room.

Pairing on a review

A take-home can be too much to ask of a senior candidate who already has a job. For them, a 45-minute pairing session works better: share a real pull request, with secrets removed, and ask the candidate to review it aloud. You are listening for what they notice first. Strong reviewers spot the missing authorization check and the loop that fires a query per row before they comment on naming.

What to score

Score four things, each out of three, and write the scores down before the debrief: did they find the real problems, did they explain the trade-offs, did they leave the code easier to test, and was the written description clear enough for a teammate in another time zone. A developer who scores well on the first and badly on the last will still struggle on a distributed team.

Interview questions for Laravel developers that ask for stories

Skip anything a search engine can answer. The questions below ask for stories, which are much harder to fake:

1. Tell me about a production incident in a Laravel application you maintained. What was the cause and what changed afterwards?
2. When did you decide not to use an Eloquent model, a service class or a package, and why?
3. A report page takes 20 seconds. Walk me through your first ten minutes.
4. How would you let a user export 500,000 rows without timing out the request?
5. What do you do when a package you depend on stops being maintained?
6. Describe a pull request you rejected, and one of yours that was rejected.

Follow up each answer with “what did you try first that did not work?” Real experience has dead ends in it. A recited answer goes straight to the tidy conclusion.

Red flags when you vet Laravel developers

• They describe every problem as a missing package, and never as a design question.
• They cannot name the last version they upgraded, or are still on a release that no longer gets security fixes.
• Authorization lives only in the front end or in route names.
• There is no test they can point to, or the tests only check that a page returns 200.
• They treat .env files as something to commit, share or paste into chat.
• Their portfolio is entirely screenshots, with no repository, pull request or reference you can look at.
• The written description of their exercise is one line long.

One flag alone rarely decides it, but two or three together, especially around security and testing, usually do.

Engagement terms to settle before a dedicated Laravel developer starts

Vetting does not end at the offer. Agree the following in writing, before the first commit:

Of all the ways to vet Laravel developers, the trial is the strongest, because it measures what the interview cannot: how the person behaves in your codebase, with your reviewers, on a deadline. Our own engagements start with a two-week paid trial sprint, so a client who finds the fit wrong stops there and pays only for that sprint. Start with limited access and widen it once the trial has gone well.

A week-long process to vet Laravel developers

Run in order, the checks before the trial take about a week of calendar time: a short screen on the six skill areas, the take-home or pairing review, one story-based interview, then a reference call you arrange yourself. The paid trial follows. Each stage costs more than the one before it, which is the point: the cheap checks remove the people who would have been expensive to find out about during the trial.