Laravel interview questions get recycled endlessly, and the lists you find online mostly reward memorising a definition. Interviewers are rarely impressed by that. What they are checking is whether you have shipped something: whether you know why the container exists, what happens to a job when the queue worker dies, and which of your own queries is about to melt the database. Here are the ones that come up again and again, with the answers that land.
Routing, requests and middleware
1. What happens between the browser and your controller? The request hits public/index.php, the framework boots, the request passes through global middleware, then the router matches it to a route and runs that route's middleware group, then the controller action, and the response travels back out through the same middleware in reverse. Being able to narrate this is the single most useful thing in a Laravel interview, because half the other questions are "where in that chain does X happen?"
2. What is middleware for, and give an example you wrote. Anything that should happen to many requests without repeating it in every controller: authentication, rate limiting, forcing HTTPS, setting the locale. The good answer names one you actually built — say, middleware that reads an Accept-Language header and calls App::setLocale() so a bilingual site serves the right strings.
3. Route model binding? Type-hint a model in the route or controller signature and Laravel fetches it by the route parameter, returning a 404 automatically when it does not exist. Route::get('/posts/{post}', ...) with function (Post $post) saves you a findOrFail in every action. Mention custom keys — {post:slug} — because a slug-routed site is the common real case.
The container and service providers
4. What is the service container? It resolves classes and their dependencies for you. When something type-hints an interface, the container looks up what that interface is bound to and constructs the whole dependency graph. The point is not magic: it is that your classes can depend on an interface instead of a concrete class, which is what makes them testable.
5. Where do you bind things? In a service provider's register() method. Use bind() for a fresh instance each time and singleton() for one shared instance. The rule that matters: register() only binds, boot() does everything else, because at register time other providers may not have run yet.
6. Facades or dependency injection? Facades are a static-looking front to a container binding; Cache::get() resolves the cache manager and calls the method. They read well and they are genuinely testable via Cache::shouldReceive(). Dependency injection makes the dependency visible in the constructor, which matters when a class quietly grows six of them. A sensible answer: facades in controllers and Blade, injection in services and anything with real logic — and the honest note that this is a team preference, not a correctness question.
Eloquent — where the real questions are
7. What is the N+1 problem? You fetch 50 posts, then loop and touch $post->author->name, and each iteration fires its own query: 1 + 50. Fix it with eager loading, Post::with('author')->get(), which makes it two queries. This is the single most common performance bug in Laravel applications, and the follow-up is usually how you would find it: Telescope, the Debugbar query count, or Model::preventLazyLoading() in your local environment, which turns every lazy load into an exception so the bug cannot reach production.
8. Explain the relationship types. hasOne and hasMany put the foreign key on the other table; belongsTo puts it on this one; belongsToMany uses a pivot table; morphTo and morphMany let one table relate to several others through a type column — comments on both posts and videos, say. Describing the direction of the foreign key is what separates someone who has designed a schema from someone who has read the docs.
9. Query scopes? Named, reusable query fragments on the model. A local scope, scopePublished($query), is called as Post::published(). A global scope applies to every query for that model automatically — useful for multi-tenancy, dangerous when someone forgets it exists and cannot work out why rows are missing.
10. What is the difference between a collection and an array? A collection wraps an array with a large set of chainable methods — map, filter, groupBy, sum — and Eloquent returns one from every multi-row query. The trap: chaining collection methods happens in PHP memory, so Post::all()->filter(...) loads the whole table first. Push the filtering into the query builder and let the database do it.
11. Migrations, seeders, factories — what is each for? Migrations version the schema so any machine can rebuild it. Seeders put known rows in, usually reference data like categories. Factories generate believable fake rows for tests. The question behind the question is whether you have ever had to rebuild a database from scratch and found out that someone changed a column by hand.
Requests, validation and security
12. Where does validation belong? In a form request class, not the controller. php artisan make:request StorePostRequest gives you authorize() and rules(); type-hint it in the action and the validation runs before your code does, redirecting back with errors automatically. It keeps controllers to a few lines and makes the rules testable on their own.
13. What does @csrf actually do? It emits a hidden token that Laravel compares against the one in the session, so a form posted from another site is rejected. Its absence is the usual cause of a 419 Page Expired — which, along with the other errors that trip up new Laravel developers, we covered in this piece. Expect a follow-up on how you would send it with an AJAX request: the X-CSRF-TOKEN header, read from a meta tag.
14. Sanctum or Passport? Sanctum for API tokens and for a JavaScript front end on the same domain — simple, session or token based, right for most apps. Passport is a full OAuth2 server, which you need when third parties authorise against your API. Choosing Passport when Sanctum would do is a common over-engineering tell, and interviewers ask this to see whether you reach for the bigger tool by default.
Queues, events and scheduling
15. Why put work on a queue, and what breaks? Anything slow that the user should not wait for: sending mail, resizing images, calling a third-party API. The job is serialised into a store — Redis, a database table — and a worker process picks it up. What breaks: the worker holds your code in memory, so after a deploy you must run queue:restart or it keeps running the old code. That detail is the answer interviewers are actually waiting for. Also know failed_jobs, tries and backoff.
16. Events and listeners? A way to let one thing happen without the code that caused it knowing about it. An OrderPlaced event with listeners that send the receipt and update the stock count keeps the checkout controller from growing forever. Listeners can be queued, which is usually what you want for anything touching the network.
17. How does the scheduler work? You define everything in the application's schedule, and the server has exactly one cron entry running schedule:run every minute. The benefit is that your scheduled work lives in version control instead of in a crontab nobody remembers editing.
Keeping current
18. What is new in the version you are using? A fair question, and a lot of candidates have no answer. Laravel 13 arrived on 17 March 2026 and needs PHP 8.3 or newer. The headline addition is a first-party AI SDK with one API for text generation, tool-calling agents, embeddings, audio, images and vector stores — before it, every team wired up its own HTTP client per provider. It also added queue routing, so default queue and connection rules for a job live in one place instead of being repeated at every dispatch. Laravel 11 is out of security support as of March 2026, and Laravel 12 stopped getting bug fixes in August 2026, which is worth knowing before you answer "which version should we upgrade to".
The question you should ask back
Near the end, ask what their slowest page is and why. The answer tells you more about the codebase than any amount of "what is our tech stack" — and asking it shows the sort of thinking the whole interview was trying to find.
