Most Laravel interview guides give you trivia. “What is the service container?” “Name five Artisan commands.” That's not an interview it's a quiz. A developer who's read the docs for 20 minutes can pass those questions. A developer who can't build anything in production can pass those questions.
The questions below are designed to show you how someone actually thinks and what they've actually built. Each one comes with what a strong answer sounds like and what a weak one reveals.
## The Architecture Questions
### 1. Walk me through the last Laravel application you built from scratch.
**What you're listening for:** Specificity. A good developer will describe the domain (what the app actually does), the key technical decisions they made, and the tradeoffs they considered. They'll mention things like how they structured the authentication, whether they used queues and why, and what they'd do differently.
**Weak answer:** “I built a web app with authentication, CRUD operations, and an admin panel.” This describes almost every Laravel project ever built. It tells you nothing.
**Strong answer:** “We built a multi-tenant invoicing platform for freelancers. I decided to use a single database with tenant_id scoping rather than separate databases because our expected tenant count was in the hundreds rather than thousands, and it simplified the infrastructure significantly. The trickiest part was making sure the global scope ran on every model we had one early bug where a support admin could see another tenant's invoices because a model didn't have the scope applied. We caught it in testing before it hit production.”
That answer demonstrates real experience, architectural thinking, and the kind of problem that only surfaces when you've actually shipped something.
### 2. How would you design the backend for a SaaS application where each customer needs their own isolated data?
**What you're listening for:** This is a multi-tenancy question. There are two main approaches shared database (tenant_id on every table) and separate databases per tenant and a good developer knows both, knows the tradeoffs, and can justify which one fits different scenarios.
**Weak answer:** “I'd use a separate database for each customer.” (No justification, no consideration of the tradeoffs.)
**Strong answer:** “It depends on the expected number of tenants and the data isolation requirements. For most early-stage SaaS products, shared database with a global scope on every model works well — it's simpler to manage and cheaper to run. For highly regulated industries or enterprise clients who require contractual data isolation, separate databases make sense. I'd probably start with shared database and design the architecture so the switch is possible if needed. I've used the Tenancy for Laravel package (stancl/tenancy) in the past — it handles both approaches and saves a lot of boilerplate.”
### 3. How do you approach database performance in a Laravel application that's starting to slow down?
**What you're listening for:** Real debugging experience. N+1 queries are the most common [Laravel performance](https://devlyn.ai/hire-laravel-developer) issue. A good developer can explain what they are, how to detect them, and how to fix them.
**Weak answer:** “I'd add indexes and optimize the queries.”
**Strong answer:** “The first thing I'd do is enable Laravel Debugbar or Laravel Telescope and look at the query log on the slow pages. Nine times out of ten, it's an N+1 problem you're loading a collection and then for each item, running an additional query for a relationship. The fix is eager loading with `with()`. Beyond that, I'd look at: missing database indexes (especially on foreign keys and columns you filter by), queries that could be cached with `remember()`, and any database calls happening inside loops. For a real performance problem, I'd also look at whether any expensive operations should be moved to a background job.”
## The Eloquent Questions
### 4. What's the difference between `with()` and `load()` in Eloquent, and when would you use each?
**What you're listening for:** This is a practical question about eager loading. `with()` is eager loading at query time. `load()` is lazy eager loading on a collection that's already been retrieved.
**Weak answer:** “I always use `with()` because it's faster.”
**Strong answer:** “`with()` runs the eager loading as part of the initial query you use it when you know upfront that you'll need the relationship. `load()` is useful when you have a collection that's already been retrieved and you conditionally need to load a relationship on it for example, in a service method that receives a model and needs to check something on a relationship that may or may not be loaded. Using `load()` avoids the N+1 problem without requiring you to always eager load everything.”
### 5. Have you ever used Eloquent scopes? Give me an example of when you'd reach for a global scope vs a local scope.
**What you're listening for:** Understanding of when scopes add value vs when they add confusion.
**Strong answer:** “Local scopes are great for reusable query conditions that you explicitly call something like `->active()` or `->published()` that you might use in several places. Global scopes are more powerful but also more dangerous they run automatically on every query for that model. The classic use case is soft deletes, which Laravel implements as a global scope. I'd use a global scope for tenant isolation every query on a tenant-scoped model should automatically filter by the current tenant, and requiring developers to remember to add that condition manually is a recipe for a security bug.”
## The Security Questions
### 6. What are the most common security mistakes you've seen in Laravel codebases?
**What you're listening for:** Practical security awareness. Not reciting Laravel's security documentation, but real things they've encountered.
**Strong answer mentions some of:** Mass assignment vulnerabilities from using `$fillable = [‘*']` or not defining `$fillable` at all, SQL injection from using raw queries without parameter binding, missing CSRF protection on custom routes, storing sensitive data in `.env` and committing it to Git, not validating file uploads properly (accepting executable file types), and exposing internal IDs in URLs instead of UUIDs.
### 7. How does Laravel's authorization work? When would you use Policies vs Gates?
**Weak answer:** “You can use `@can` in Blade templates.”
**Strong answer:** “Gates are for simple, one-off authorization checks that don't relate to a specific model things like ‘can this user access the admin area'. Policies are for model-specific authorization ‘can this user update this specific post'. I prefer policies for resource authorization because they're more organized, easy to test, and Laravel automatically discovers them if you follow the naming convention. I always register policies in the AuthServiceProvider and use `authorize()` in controllers rather than scattering `Gate::allows()` calls throughout the codebase.”
## The Queue & Async Questions
### 8. Walk me through how you'd implement an email notification that needs to be sent after a user places an order, without slowing down the checkout response.
**What you're listening for:** They should reach immediately for queued jobs. The order process should dispatch a job, return the response to the user, and the job handles the email asynchronously.
**Strong answer:** “I'd create a queued Mailable and dispatch it from within an event listener or directly from the controller after the order is saved something like `dispatch(new SendOrderConfirmation($order))`. The job would implement `ShouldQueue`, which means Laravel drops it onto the queue and returns the HTTP response immediately. I'd use Redis as the queue driver in production, and Laravel Horizon to monitor the queue workers. I'd also set up a retry policy say, three attempts with exponential backoff — and log failed jobs to the `failed_jobs` table so nothing silently disappears.”
### 9. What happens when a queued job fails? How do you handle it?
**Weak answer:** “It gets logged somewhere and you can retry it.”
**Strong answer:** “Laravel logs failed jobs to the `failed_jobs` table with the exception message, which is a good first step. From there, there are a few layers of handling: I'd configure retries on the job class itself with `$tries = 3` and `backoff()` for exponential backoff on transient failures. For more critical jobs, I'd implement the `failed()` method on the job class to send an alert or trigger a fallback — maybe a simpler notification path if the main one fails. I'd also set up Horizon alerts for queue lag and failure rates. For jobs that absolutely cannot be lost (like billing operations), I'd use a database queue driver rather than Redis for durability, since Redis can lose data on a crash.”
## The Testing Questions
### 10. How do you test a controller that sends an email and creates a record in the database?
**What you're listening for:** They should immediately mention faking the Mail facade. Good answer will also mention database assertions.
**Strong answer:** “I'd write a feature test using `Mail::fake()` at the top. This stops any real mail from being sent. Then I'd call the endpoint via `$this->post(‘/orders', $data)`, assert the database has the new record with `assertDatabaseHas()`, and assert the mail was dispatched with `Mail::assertSent(OrderConfirmation::class, function ($mail) use ($user) { return $mail->hasTo($user->email); })`. I'd also test the failure case — what happens if the required fields are missing, or if the database write fails.”
### 11. What's the difference between unit tests and feature tests in a Laravel context? Which do you write more of?
**Strong answer:** “Unit tests test individual classes or methods in isolation a specific service, a value object, a helper function. Feature tests test a full HTTP request cycle, including middleware, routing, controller, service layer, and database. In practice, I write far more feature tests because they give you confidence that the whole system works together, not just that each piece works in isolation. Unit tests are most valuable for complex business logic that would be painful to test through HTTP a pricing calculation engine, a document parser, that kind of thing.”
## The Architecture & Real-World Questions
### 12. Have you ever had to refactor a messy Laravel codebase you inherited? What was your approach?
**What you're listening for:** Patience, process, and pragmatism. The wrong answer is “I rewrote it from scratch.”
**Strong answer:** “The first thing I do is add tests to whatever I'm about to touch not the whole codebase, just the area I'm changing. That gives me a safety net. Then I make the change. Over time, the test coverage grows organically around the work. Trying to write tests for the entire codebase before changing anything is a good way to never ship anything. For structural refactoring moving logic out of fat controllers into services, for example I do it incrementally. Extract one service, make sure it works, move on. I avoid the ‘big bang refactor' because it's almost always how you introduce regressions.”
### 13. What do you think about using repositories in Laravel? Are they worth the overhead?
**What you're listening for:** Nuanced opinion, not dogma.
**Strong answer:** “It depends on the size and complexity of the project. For a small application, adding a repository layer is pure overhead — you're writing an interface, an implementation, and a binding in the service container just to wrap Eloquent calls that already work fine. For a large application where you have genuinely complex query logic, or where you want to make the code testable without hitting the database, repositories make sense. I'm comfortable with either approach. What I try to avoid is using repositories as a cargo cult adding them because ‘that's the right way to do it' rather than because they solve a real problem.”
## The Soft Skills Questions
### 14. Tell me about a time you disagreed with a technical decision made by your team or your client. How did you handle it?
**What you're listening for:** That they can advocate for their perspective professionally without being a roadblock, and that they can commit to a decision they didn't agree with when it's made.
### 15. How do you stay current with Laravel? What's something you've learned in the last few months that's changed how you work?
**What you're listening for:** Genuine engagement with the ecosystem. They should mention specific things Laracasts, the Laravel News newsletter, the changelog, Laracon talks, specific packages they've recently started using.
**Weak answer:** “I read the documentation.”
**Strong answer:** “I follow the Laravel News newsletter and Taylor's X account for announcements. Recently I started using Pest for testing instead of PHPUnit the syntax is so much cleaner for feature tests, and the architecture plugin makes it easy to enforce that service classes don't depend on Eloquent models directly. I also started using Laravel Pint for automatic code formatting in CI, which removed a bunch of style review comments from our pull requests.”
## A Note on Paid Trial Tasks
Interviews only tell you so much. The single best signal for a Laravel developer is a paid trial task a real, small, scoped piece of work at their quoted rate. You're not doing free work. You're paying for a high-quality signal.
Give them something realistic: a small feature addition to a test repository, or a code review of an existing piece of code. How they communicate, what questions they ask, and what they deliver tells you more than three hours of interviews.
If you'd rather skip the screening process entirely, Devlyn provides pre-vetted senior Laravel developers from India who've already passed technical assessments so your “interview” is more about culture fit and project alignment than proving basic competence.
