How to Vet a Laravel Developer: Questions and a Trial Task

A developer who has followed Laravel tutorials and one who has kept a Laravel application alive in production write similar resumes. The difference is in the specifics: what they do when a queued job fails twice, how they find the query that makes a page slow, what stops one customer from opening another customer's invoice. When you hire a Laravel developer, interview for those specifics, then watch the candidate work on something small.

Below are prompts to use, what a strong answer contains, a trial task sized for one day and the signals to look for in the code that comes back.

Before the interview, decide which Laravel developer you are hiring

Laravel covers several kinds of work, and few people are equally strong in all of them:

• API back end for a mobile app or a JavaScript front end: token authentication, versioning, rate limits, response design.
• Full-stack product work with Blade and Livewire, or with Inertia and Vue or React.
• Maintenance and upgrades of an older application: reading unfamiliar code, adding tests, moving across major versions.
• SaaS: multi-tenancy, subscription billing, background processing at volume.

Pick the one that describes your next six months and weight the interview toward it.

Eloquent and the database

Ask: "A page lists fifty orders with each customer's name and runs fifty-one queries. Why, and what do you change?"

A strong answer names the N+1 problem: the relationship is loaded lazily, once per row. The fix is eager loading, as the Eloquent relationships documentation describes:

$orders = Order::with('customer')->latest()->paginate(50);

Better candidates add how they catch it earlier, for example by calling Model::preventLazyLoading() outside production, so a lazy load throws an exception during development.

Ask: "How do you add a required column to a table with several million rows on a live system?"

Listen for steps: a new migration (never an edit to one that has already run), the column added as nullable, existing rows filled in batches, the code switched over, and the constraint tightened last. "I just run the migration" means they have not done it on a large table.

Ask: "When do you wrap code in a database transaction?"

When several writes must succeed or fail together, such as an order, its stock movement and its payment record. A careful developer adds that emails and queued jobs triggered inside a transaction should wait until it commits.

Queues, schedules and work that runs unattended

Ask: "What happens when a queued job throws an exception?"

The job is retried up to its configured number of attempts and is then recorded as failed, where it can be inspected and retried by hand. What separates candidates is the consequence: a job may run more than once, so it must be safe to repeat. Charging a card or sending an invoice needs a guard against doing it twice. Good answers also cover timeouts, a process monitor such as Supervisor to keep workers alive, and php artisan queue:restart on each deployment so workers pick up new code. The queue documentation covers each point, and we explain the moving parts in Laravel queues explained.

Ask: "How are scheduled tasks run, and what changes with two servers?"

One cron entry calls php artisan schedule:run every minute and Laravel decides what is due. With more than one server each would run the task, so the developer should know onOneServer() and withoutOverlapping(), and why a nightly billing run needs both.

Authorization and input

Ask: "A user changes the ID in the address bar and sees another customer's invoice. What was missing?"

Authorization. Being logged in is not the same as being allowed to see a particular record. The expected answer is a policy check on the model, as set out in Laravel's authorization documentation, or queries scoped to the current user or tenant, plus a test proving that a second user gets a 403 response.

Ask: "How do you stop someone setting is_admin by adding a field to a form?"

Validated input and mass-assignment protection: a form request class with rules, only validated data passed to the model, and fillable attributes declared on it. While on the subject, check they know that secrets belong in the environment file and not in the repository, and that APP_DEBUG must be false in production.

Tests, upgrades and deployment

Ask: "You inherit an application with no tests. What do you test first?"

The flows where a mistake costs money or leaks data: checkout, permissions, anything that calculates. Feature tests with Pest or PHPUnit, model factories for data, and the suite running on every push. A candidate who wants full coverage before touching anything will never ship. One who wants none will break things.

Ask: "The application is two major versions behind. How do you approach it?"

One major version at a time, following each upgrade guide, with package compatibility checked first and tests in place before starting. Someone who maintains production systems also knows the support policy, which gives each release a limited period of bug fixes and a longer one of security fixes. Our article on planning a Laravel upgrade describes the sequence.

Ask: "Walk me through a deployment."

You are listening for a repeatable routine and not heroics: code from Git, dependencies installed without development packages, php artisan migrate --force, cached configuration and routes, workers restarted, and a way back if something fails.

A trial task that takes a day

Pay for it, cap it at four to eight hours, and choose one of three shapes.

1. A small API. Endpoints to create and list bookings for the logged-in user, with validation, a rule that users only see their own, a queued confirmation email and tests.
2. A review. Hand over a small repository with planted problems: a query in a loop, a missing permission check, unvalidated input, logic crammed into a controller. Ask for a written list of findings and one pull request fixing the worst.
3. A real ticket. A contained item from your backlog, on a branch, with access to staging only.

The second shape suits maintenance roles, because reading other people's code is the job. The third tells you most about working together, at the cost of some setup time.

What to look for in the code they send back

• It runs. A readme, an .env.example, migrations and seed data, so the project starts with a few commands.
• Thin controllers. Validation in form requests, access rules in policies, nothing important hidden in route files or templates.
• Database care. Foreign keys and indexes in the migrations, eager loading where lists are shown, pagination instead of loading every row.
• Tests that say something. At least the unhappy paths: invalid input, another user's record, a guest.
• A job that can run twice without sending two emails.
• Nothing left behind. No committed secrets, no stray dd() calls, no commented-out blocks.
• Restraint. Framework features used as intended, with no layers of interfaces and repositories around three tables. Over-building is as much a warning as sloppiness.

Finish with a conversation about the task. Ask what they would change with another day. People who can criticize their own work are the ones you want maintaining yours.

If you cannot judge the answers yourself

A non-technical founder can run the trial and still not know whether the result is good. There are two ways around that. Pay an independent senior Laravel developer for two hours to review the submission and join the final call. Or hire through a company that has done the vetting and stands behind it. When you hire a Laravel developer from us, you still review resumes and interview, and a developer who turns out not to fit is replaced.

A freelancer is a perfectly good choice for a contained Laravel job when someone on your side can review code. For a product that has to be designed, built and then run, consider whether you need one person or a Laravel development project with a team behind it. The prompts above apply in both cases. Put them to us too.

Frequently asked questions

Should a Laravel developer also know Vue or React?

Only if your product has a JavaScript front end, and then ask which one and test it. Many strong back-end developers are average at interface work. If you need both in one person, say "full-stack" in the role and include a front-end piece in the trial task.

Is live coding in the interview a good test?

It mostly tests nerves. A paid take-home task followed by a call where the candidate explains their choices shows more, and it is closer to the real job. If you want something live, review a piece of code together and ask what they would change.

How important is experience with the newest Laravel version?

Less than it sounds. The fundamentals carry across versions, and a developer who has upgraded applications between major versions understands the framework better than one who has only started new projects. Do check that they know which versions still receive security fixes.

Can a good PHP developer learn Laravel on the job?

Yes, in a role with a senior Laravel developer nearby to review their work. The syntax comes quickly. The conventions, such as where validation, authorization and background work belong, take longer, and those are where an unsupervised newcomer creates problems.