Laravel developer interview - what do they actually test beyond basic CRUD?
I've got a mid-level Laravel developer interview coming up in 10 days and I'm trying to figure out what depth of knowledge they're looking for. I've been building with Laravel for about 2 years - I know Eloquent relationships, basic middleware, queues and jobs, and the usual MVC patterns. But interviews have a way of going deeper on framework internals that I've never needed to think about explicitly.
Last time I interviewed 8 months ago I got caught on a question about service container bindings and how dependency injection actually works under the hood. I answered it but not confidently. Same interview asked me to explain the difference between singleton and scoped bindings, which I fumbled. I've since learned both but it reminded me there's a lot of framework internals I use without really understanding.
What topics do Laravel interviews typically push into? I'm specifically wondering about service providers, event and listener patterns, testing with PHPUnit in Laravel, and newer features in Laravel 10 and 11. Is there a reasonable way to do targeted prep in 10 days or am I better off deepening a few areas rather than trying to cover everything?
Newer features like Folio, Volt, and the pipeline changes in L11 show up in cutting-edge teams but most companies are still on L10 at best. Deep knowledge of core concepts matters more than knowing the latest additions.
Event and listener patterns come up a lot because they're easy to get wrong in production. Know the difference between sync and queued listeners, when you'd use observers vs listeners, and how to test events with Event::fake(). Those are standard questions.
10 days is enough to solidify 4-5 areas if you're deliberate about it.
Testing is an underrated interview topic. A lot of candidates can't explain the difference between unit tests and feature tests in a Laravel context, or don't know how to use RefreshDatabase vs Transactions for test isolation. If you can speak fluently about testing it really stands out.
Service providers and the container are the most common deep-dive topics in mid-level interviews. If you can explain the boot vs register lifecycle clearly and give a real example of a custom binding, you'll be ahead of most candidates.
I was in a similar spot last year, working full-time and squeezing in prep during lunch breaks and after the kids went to bed. Honestly the areas that tripped me up most weren't CRUD at all -- it was service container binding, how the IoC container resolves dependencies, and being able to explain the difference between singleton and bind out loud without fumbling. They also went deeper on queues than I expected, like what happens when a job fails mid-execution and how you'd handle retries with backoff.
For the schedule thing, I'd just block off 45 minutes a night and pick one topic to go deep on rather than skimming everything. Ten days is actually enough if you're focused. Make sure you can talk through Eloquent observers, policy vs gate authorization, and how you'd structure a larger app with repositories or actions -- that's where mid-level interviews usually separate candidates who've only done tutorials from people who've shipped real stuff.
One thing that really helped me was going through practice questions and paying close attention to why the wrong answers are wrong, not just confirming what the right one is. Like with service containers and dependency injection, I kept getting tripped up until I stopped just memorizing "use the container to resolve classes" and actually understood what breaks when you don't. That shift made a huge difference for Eloquent stuff too, especially N+1 queries and eager loading where the wrong approach isn't obviously broken until you're under load.
For a mid-level interview they're probably going to push you on architecture decisions. It's not enough to know that queues exist. They want to know why you'd reach for a queue instead of handling something synchronously, and what happens when a job fails. I'd also brush up on how Laravel's auth and gate system actually works under the hood, because a lot of people use it but can't explain it. Understanding the "why" made me way more confident answering follow-ups I didn't expect.
Just went through this exact process last month and honestly the thing that tripped me up in earlier interviews wasn't the code itself, it was not being able to explain *why* Laravel does things a certain way. Interviewers kept asking about service container bindings, deferred providers, and how the event system actually works under the hood, not just how to fire an event. Once I drilled into the laravel professional standards competencies material and started focusing on the internals rather than just the API surface, everything clicked.
The other thing they hammered on was database performance, specifically N+1 issues and when to use eager loading vs lazy vs chunking on large datasets. It's one thing to know eager loading exists, it's another to reason through a query problem on the spot. So practice talking through your thought process out loud, not just writing the code.
Just went through this exact process last month and honestly the thing that caught me off guard was how deep they went on the service container and dependency injection. I knew how to use it, but I didn't really understand why it works the way it does — like what actually happens when Laravel resolves a binding out of the container. Once I dug into that, a lot of other things clicked, including how middleware, policies, and even queued jobs all tie back to the same mechanism.
The other thing that made a real difference for me was understanding database query optimization beyond just "use eager loading." They asked me to look at a slow query and explain it. N+1 is the obvious answer everyone gives, but knowing how to read the query log, when to use raw expressions, and how indexes actually affect Eloquent queries — that's what separated the mid-level candidates from the junior ones. It's worth spinning up Telescope or Debugbar before your interview just to get comfortable reading what's actually happening under the hood.