30 Laravel Interview Questions to Check Seniority (2026)

Most Laravel interviews test memorised facts: "what is middleware", "name the artisan commands". They filter out people who never opened the docs, but they do not separate a mid-level developer from a senior — and that is exactly the distinction that decides whether your project ships or stalls.

This is the question set I would use (and the one I answer as a candidate). Thirty questions, grouped by area, with what a strong answer sounds like. Use 8–12 of them per interview, not all thirty.

Hiring through an interview loop is one option; the alternative is hiring a ready senior Laravel developer who has already been through this filter many times. Either way, the questions below will help you evaluate what you get.

How to structure the interview

• 60–90 minutes total: 10 minutes of context, 40–50 minutes of questions, 15 minutes for the candidate's questions.
• Start from their own projects, not from trivia. "Walk me through the last thing you deployed" tells you more than twenty definitions.
• Ask "why", not "what". Anyone can list queue drivers; seniors explain when a queue is the wrong answer.
• One whiteboard-style problem is enough. Watch the reasoning, not the syntax.

PHP and language fundamentals (1–6)

1. What changed in PHP 8.x that affects how you write Laravel code? Strong answer: constructor promotion, named arguments, enums, readonly properties, match expressions, union/intersection types, nullsafe operator. Bonus: they mention the PHP 7.4 → 8.x upgrade of an existing codebase and what broke. See the wider context in the PHP migration guide.

2. When would you use an enum instead of class constants?

• Strong answer: when the set of values is closed and the values carry behaviour (labels, transitions, validation). Mentions backed enums for database storage and casts in Eloquent.

3. What is the difference between == and ===, and where has it bitten you?

• Strong answer: type juggling, "0" == false style surprises, why strict comparison matters in authorization checks and cache keys.

4. How do generators work and when do they matter?

• Strong answer: memory-efficient iteration for large datasets, yield, lazy collections in Laravel (cursor(), lazy()).

5. What are readonly properties for?

• Strong answer: immutability of DTOs/value objects, preventing accidental state changes, interaction with serialization.

6. When is a trait the wrong tool?

• Strong answer: traits as hidden dependencies, conflicts, why composition (services, strategies) usually beats model traits.

Laravel framework depth (7–14)

7. Explain the service container in one sentence, then with an example from your code.

• Strong answer: dependency resolution and lifecycle management; example: binding an interface to an implementation so a payment gateway can be swapped in tests.

8. When do you reach for a queue, and when is a queue the wrong answer?

• Strong answer: queues for slow, retryable, non-blocking work (emails, webhooks, exports). Wrong when the result is needed synchronously or when ordering matters and no ordering guarantee is designed.

9. How do you make a webhook handler idempotent? Strong answer: idempotency keys stored with unique constraints, upserts instead of inserts, status machines that ignore repeated transitions. This is the #1 e-commerce bug class — the story of duplicate orders is told in this integration case study.

10. Livewire, Inertia or a classic API?

Justify for a specific project. Strong answer: Livewire for form-heavy internal tools, Inertia for SPA feel with Laravel routing, API when a mobile app or third parties consume the backend. A senior names trade-offs, not favourites — see Inertia.js vs Livewire.

11. How do Eloquent relationships behave with soft deletes and global scopes?

• Strong answer: withTrashed on relations, scope leakage, withoutGlobalScopes risks, and testing the queries rather than assuming.

12. What are events and listeners for — and when do they create problems?

• Strong answer: decoupling side effects; problems when listeners do critical work synchronously without retries or when event chains become invisible.

13. How would you implement scheduled work that must run exactly once?

• Strong answer: onOneServer() with a shared cache, unique job locks, overlap protection (withoutOverlapping), monitoring of the scheduler.

14. Where do you put business logic, and why not in controllers?

• Strong answer: actions/services for use cases, thin controllers, domain rules testable without HTTP. Mentions the failure mode: fat models with hidden side effects.

Database and performance (15–20)

15. A page got slow. Walk me through your investigation.

• Strong answer: measure first (Telescope, Debugbar, slow query log), find N+1s, check indexes with EXPLAIN, then cache/queue — not "add Redis".

16. What is an N+1 and how do you catch it in review?

• Strong answer: eager loading (with), preventLazyLoading in non-production, looking for loops that touch relations.

17. How do you approach a missing index?

• Strong answer: read EXPLAIN, check selectivity and cardinality, consider composite index order, measure the write cost of the new index.

18. When do you denormalise?

• Strong answer: only with a measured need (reporting, hot paths), and with a plan to keep data consistent.

19. Migrations on a table with millions of rows — what changes?

• Strong answer: no blocking alters, separate deploy steps, backfills in batches, feature flags for schema transitions.

20. How do transactions and queues interact?

• Strong answer: dispatch after commit (afterCommit), outbox pattern, why a job may run before the transaction commits and what breaks.

Testing, CI/CD and security (21–26)

21. What do you test in a Laravel app, and what do you deliberately not test?

• Strong answer: feature tests on critical flows (auth, payments, orders), unit tests for domain rules, no tests for framework glue. Mentions factories and database transactions between tests.

22. Pest or PHPUnit — and does it matter? Strong answer: preference with reasons; the point is that tests exist and run in CI, not the runner. See CI/CD and DevOps for Laravel.

23. Describe your CI pipeline for a Laravel project.

• Strong answer: tests, static analysis (PHPStan/Larastan), lint, build, deploy on tag — with staging before production and a rollback path.

24. A dependency has a critical CVE. What happens next?

• Strong answer: assess exposure first, patch plan, composer audit in CI, and the habit of keeping versions current.

25. How do you handle secrets in a Laravel project?

• Strong answer: .env outside the repo, secret managers in production, rotation, never in config caches committed anywhere.

26. What does a security review of a Laravel app cover? Strong answer: OWASP Top 10 mapped to Laravel specifics — mass assignment, IDOR in policies, XSS in Blade ({{ }} vs {!! !!}), CSRF, file uploads, rate limiting, signed URLs. Deep dive: Laravel security and OWASP.

Architecture and collaboration (27–30)

27. How do you decide to refactor vs rewrite? Strong answer: almost always incremental refactoring behind tests (strangler pattern); rewrites only when the domain changed fundamentally. The legacy modernization guide is the long version.

28. Tell me about a production incident you caused and what you changed afterwards.

• Strong answer: specifics — what broke, the blast radius, the fix, and a process change (monitoring, tests, review rule). Candidates without such a story have either not operated systems or are not telling the truth.

29. How do you estimate work?

• Strong answer: decomposition, ranges instead of points, explicit assumptions, buffer for unknowns, historical data from their own past estimates.

30. How do you work with a client or PM who keeps changing priorities?

• Strong answer: a visible backlog, a definition of "done", the cost of context switching named out loud, and a simple rule for what enters the sprint mid-way.

How to read the answers

• Junior: defines terms, needs the second question to get concrete, avoids production stories.
• Mid: solid framework knowledge, solves known problems, weaker on trade-offs and estimation.
• Senior: starts from constraints, names trade-offs unprompted, has incident stories with lessons, asks you about the business.

A candidate's questions to you are signal too: seniors ask about users, data, deadlines and who owns decisions — not only about the tech stack.

What not to ask

• Brain teasers and algorithm puzzles irrelevant to product work.
• "Name all the artisan commands" — autocomplete territory.
• Trick questions with no real-world counterpart.
• Anything about age, family plans or nationality — illegal in many jurisdictions and useless everywhere.

Frequently asked questions

How many interview stages does hiring a Laravel developer need?

• Three: a 30-minute screening, a 60–90 minute technical conversation using the questions above, and a short paid test task with a review. Anything longer loses good candidates; anything shorter leaves seniority unverified.

Should the technical interview include live coding?

Only as a small, realistic exercise (a function, a query, a review of a flawed snippet) — and never with an audience. Take-home paid tasks produce better signal for product work. Live coding tests under pressure select for interview skill, not engineering skill.

What are the biggest red flags in a Laravel interview?

No production incident stories, "I rewrite everything", no opinions about trade-offs, inability to explain their own recent project's architecture, and silence about testing and CI. Any two of these together justify a pass.

Is it worth testing Laravel-specific knowledge at all?

Yes — but through behaviour, not trivia. Ask what they would not use a tool for, how they upgraded a major version, how they found an N+1. Framework depth shows up in constraints, not in definitions.

How do these questions differ for a contractor vs a full-time hire?

• For a contractor, add: ownership habits (whose repo, whose infra), communication cadence, availability windows and how they hand over work. Contractors must leave systems other people can operate — the interview should test for that explicitly.