Interviewing a Laravel developer should not be a “guess what I’m thinking” session or a PHP syntax exam. If you lead a technical team and need someone who contributes from day one, this checklist helps you separate real experience from hype in 60-90 minutes.
1. Pre-screen: async code review
Before the live interview, send an async code review task: 30 minutes, no pressure, written results. Give them a pull request with real problems and ask them to review it.
The PR should contain:
- A controller with business logic inline
- Missing type hints and docblocks
- An N+1 query
- Generic error handling (empty try-catch)
- No tests
What to look for: they identify at least 3 issues, explain why each is a problem, and propose concrete solutions. They don’t need to catch everything; you need to see their thinking process.
2. Open-ended technical questions
Laravel Architecture
| Question | What it reveals |
|---|---|
| ”When would you use an Action vs a Job vs a Listener?” | Understands Service Layer, queues, events |
| ”How would you design a billing module that will grow to 10 microservices?” | Scaling vision, not just CRUD |
| ”What do you do when a job fails after 3 retries?” | Queue knowledge, failed jobs, alerting |
| ”How do you version an internal API used by 4 teams?” | API versioning, contracts, breaking changes |
Testing
| Question | What it reveals |
|---|---|
| ”When is a unit test not enough?” | Understands test pyramid |
| ”How would you test that an invoice is sent by email?” | Fakes, Mail fake, event testing |
| ”What are Pest architectures and when would you use each?” | Knows Pest beyond PHPUnit basics |
AI in the workflow
| Question | What it reveals |
|---|---|
| ”Which tasks do you delegate to Claude Code and which do you always review?” | Uses AI with judgment, not as a crutch |
| ”How do you ensure quality in AI-generated code?” | Has a review process, real understanding |
| ”What MCP servers do you use or would you build?” | Current with AI/agent ecosystem |
3. Live code review (pair session)
Spend 20 minutes on this. Share a screen with real code (or a prepared snippet) and ask them to critique it out loud:
// Code for joint review
class OrderController extends Controller
{
public function process(Request $request)
{
$order = Order::find($request->order_id);
$order->status = 'processing';
$order->save();
$user = User::find($order->user_id);
Mail::send('emails.order', ['order' => $order], function ($m) use ($user) {
$m->to($user->email);
});
PaymentGateway::charge($order->total);
return redirect()->back()->with('success', 'Order processed');
}
}Positive signals:
- Points out the controller has too many responsibilities
- Asks what happens if PaymentGateway fails (missing try-catch, transaction)
- Notes missing validation (no check if order exists)
- Questions why the email is sent before payment
- Mentions
Order::findshould befindOrFail
Red flags:
- Says “looks fine” without criticism
- Only points out syntax issues (semicolons, etc.)
- Doesn’t mention database transactions
4. Architecture whiteboard
Give them 15 minutes to design (paper, Excalidraw, whatever they’re comfortable with) a solution to a real problem:
Scenario: “Our Laravel app needs to process recurring payments. The user uploads a CSV with the month’s payments, the system validates each row, processes the charge, and notifies the user about errors. How would you model this?”
What to look for:
- Separation into layers (CSV parser, validator, payment processor, notifier)
- Row-level error handling (don’t fail all rows for one error)
- Queues for slow payments (each payment in its own job)
- Testing: how to verify each piece
- Do they mention an Action or Service class?
5. Communication and attitude
A senior developer does not just write code: they communicate technical decisions to non-technical stakeholders.
Question: “Imagine the CEO asks why a seemingly simple feature will take two weeks instead of two days. How do you respond?”
What to look for:
- Explains the problem without unnecessary jargon
- Offers options (quick fix vs correct solution)
- Doesn’t dismiss the CEO’s question
- Shows prioritization judgment
Red flags and green flags summary
| Area | Green flag | Red flag |
|---|---|---|
| Code review | Critiques, suggests, asks questions | Says “looks fine” |
| Testing | Asks “how do you test this?” | Doesn’t mention tests |
| Architecture | Separates concerns, names patterns | Everything in controllers |
| AI | Uses tools with judgment | Doesn’t use AI or uses without review |
| Communication | Explains, simplifies, offers options | Gets lost in jargon |
| Queues | Mentions jobs, retries, failures | Only knows “dispatch” |
| Database | Transactions, indexes, N+1 awareness | Flat queries |
Conclusion
The best Laravel developer is not the one who writes code fastest; it’s the one who makes decisions that save the team work. Look for judgment, not syntax.
If you’d rather skip the process and hire someone who already checks all these boxes, review my stack, experience and availability.
Related Articles
- CTO Guide to Hiring Laravel Developers in Spain — Market, modalities, time zones
- How to Hire a Laravel Developer Remotely in Spain — Process, budget, onboarding
- Tech Stack for Startups in 2026 — Laravel, Vue, Inertia, testing, deployment
