25 Laravel interview questions

Listen for: A strong answer starts with reproducing the request, checking logs, environment differences, config cache, database connection, migrations, permissions, queue workers, and third-party credentials. They should know to use Laravel logs, exception traces, Telescope if available, and safe read-only checks before guessing or editing production-like configuration.

Red flag: They immediately suggest changing code or clearing every cache without first identifying the failing layer.

Listen for: Look for separation of concerns rather than rigid rules. Good candidates put request validation and authorization in Form Requests or policies, keep controllers thin, avoid bloated models, use action or service classes for reusable workflows, and move slow or retryable work into jobs while keeping transaction boundaries clear.

Red flag: They say all business logic should always go in controllers or always go in models.

Listen for: They should mention policies or gates, route model binding, authenticated feature tests, positive and negative cases, and avoiding trust in request user_id fields. Strong junior candidates include validation, proper HTTP statuses, database assertions, and checking that another user cannot update or even infer unauthorized resources.

Red flag: They rely only on hiding buttons in Blade or the frontend to enforce access control.

Listen for: A good answer identifies N+1 queries, eager loading with constraints, selecting only needed columns, pagination, indexes, query logging, and using database explain plans. They should understand that API Resources can accidentally trigger lazy loading and that fixing performance should be verified with tests or measured query counts.

Red flag: They suggest caching the whole response before checking the query pattern or database indexes.

Listen for: Listen for feature tests around behavior, factories and seeders for setup, database refresh or transactions, assertions on outcomes rather than implementation details, faking mail, notifications, queues, and events where appropriate. They should test authorization and validation paths while avoiding over-mocking Laravel internals.

Red flag: They only test happy paths or assert exact HTML and private method behavior for every feature.

Listen for: They should discuss retries, idempotency, duplicate sends, job timeouts, failed_jobs, partial updates, transactions, external provider errors, and logging. A good junior answer notes that queue workers must be running with the right environment and that mail can be faked in tests.

Red flag: They assume a queued job either always completes once or simply disappears if it fails.

Listen for: Strong answers split upload, validation, storage, parsing, and processing. They use queues or batches, chunking, progress tracking, row-level error reporting, idempotency, and authorization. They avoid loading the whole file into memory and think about rollback strategy, duplicate detection, timeouts, and user feedback.

Red flag: They process the entire CSV synchronously inside the controller request.

Listen for: Look for a systematic path: confirm write success, transaction timing, read replica lag, cache keys and tags, model events, resource transformation, HTTP caching, and queued projections. Strong candidates discuss cache invalidation over blanket clearing and add tests around update-read behavior where possible.

Red flag: They clear all application cache on every update without considering scope or concurrency.

Listen for: A strong answer weighs coupling, observability, transaction boundaries, ordering, retries, and failure handling. They use direct calls for required synchronous work, events for decoupled domain reactions, observers carefully for persistence side effects, and queued jobs for slow or retryable work, with clear naming and monitoring.

Red flag: They use events for everything because it feels cleaner, even when the caller must know the result.

Listen for: They should combine Form Requests, policies, custom validation rules, after hooks, and service-level invariants. Good answers avoid duplicating rules across controller and frontend, guard against race conditions with database constraints or transactions, and produce clear validation messages without exposing sensitive data.

Red flag: They put all checks in JavaScript or assume validation alone can enforce business invariants under concurrency.

Listen for: Listen for transaction review, consistent lock ordering, smaller transaction scopes, proper indexes, retrying deadlocks safely, avoiding external calls inside transactions, and using database constraints. Strong candidates understand Eloquent can hide multiple queries and will inspect SQL logs or database monitoring, not only PHP code.

Red flag: They increase the PHP timeout or queue timeout without addressing locking behavior.

Listen for: Good answers include reading upgrade guides, checking PHP and Composer constraints, updating first-party packages, running tests, static analysis, deprecation fixes, config comparison, CI updates, and staged deployment. They mention Rector or Laravel Shift as aids, not substitutes, and plan rollback for production.

Red flag: They update composer.json directly on main and rely on manual clicking through the app afterward.

Listen for: They should clarify latency needs, clients, auth, fan-out, persistence, and fallback behavior. Strong answers compare database notifications, broadcasting with Reverb or Pusher-compatible services, queues, private channels, and email or push fallbacks. They consider local development, testing, monitoring, and operational cost in complexity terms.

Red flag: They immediately choose WebSockets for every notification without asking whether real time is actually required.

Listen for: A senior answer prioritizes incremental refactoring with safety. They identify seams, introduce feature tests, extract workflows into actions or services, standardize query objects or scopes where useful, improve factories, and reduce test suite drag. They balance cleanup with delivery and avoid imposing architecture for its own sake.

Red flag: They propose a rewrite or a new framework before mapping risks and business priorities.

Listen for: Look for policies, gates, scoped route model binding, tenant-aware queries, role-permission packages only where justified, auditability, and deny-by-default behavior. Strong candidates separate authentication from authorization, test cross-tenant access thoroughly, and consider admin impersonation, invitations, ownership transfer, and background job permissions.

Red flag: They trust tenant_id or role values submitted by the client.

Listen for: Strong answers separate queues by priority and risk, tune workers with Horizon or supervisor, define retries and backoff, use idempotency keys, monitor failed jobs and lag, and avoid mixing critical payment jobs with low-value analytics. They discuss poison messages, alerting, deployments, and graceful worker restarts.

Red flag: They treat queues as fire-and-forget and do not plan for duplicate or delayed execution.

Listen for: A good answer starts with team boundaries, deployment pain, data ownership, scaling bottlenecks, and operational maturity. They should favor a well-structured modular monolith until independent lifecycle needs justify services. They discuss APIs, events, contracts, shared authentication, failure modes, and the cost of distributed transactions.

Red flag: They say microservices are automatically more scalable or that a monolith is always simpler.

Listen for: Listen for measurement first: APM traces, Pulse, database metrics, slow query logs, cache hit rates, queue lag, and load tests. Strong candidates consider eager loading, indexes, response shape, pagination, Redis caching, Octane suitability, PHP opcache, Horizon tuning, and database connection limits before changing architecture.

Red flag: They jump straight to Octane or more servers without identifying the bottleneck.

Listen for: They should cover twelve-factor configuration, encrypted secrets or a secrets manager, config caching, clear environment parity, CI validation, least privilege credentials, safe rotation, and avoiding secrets in logs. Good answers include documenting required variables and detecting missing or stale config during deployment.

Red flag: They commit .env files or rely on copying production credentials into developer machines.

Listen for: Strong answers focus on behavior, maintainability, security, data integrity, and operability, not style nits already handled by Pint or static analysis. They ask about tests, authorization, migrations, queues, and failure modes. They also explain trade-offs, mentor respectfully, and distinguish blocking issues from preferences.

Red flag: They mainly enforce personal style and rewrite other engineers’ code without explanation.

Listen for: Expect clear boundaries between synchronous checkout and asynchronous webhook processing. Strong answers include signed webhook verification, idempotency, event logs, queued processing, state machines or explicit statuses, retries, audit trails, and access decisions based on local trusted state. They avoid relying on redirect success alone.

Red flag: They grant subscription access immediately after the browser returns from checkout without verifying provider events.

Listen for: Good answers compare single database with tenant_id, separate schemas, and separate databases based on isolation, reporting, cost, and operations. They cover tenant resolution, scoped queries, policies, migrations, queues, cache keys, file storage paths, testing cross-tenant leakage, and admin support workflows.

Red flag: They add tenant_id columns but do not enforce scoping consistently across queries, jobs, and authorization.

Listen for: Strong candidates define what events matter, who performed them, before and after values, request metadata, retention, privacy, and tamper resistance. They discuss model events versus explicit domain events, queued writes, transaction timing, searchable storage, redaction, and how audits are tested and reviewed.

Red flag: They rely only on generic application logs for audit requirements.

Listen for: Look for Laravel notifications, database channels, queues, broadcast channels, Reverb or managed WebSocket options, user preferences, digesting, rate limits, retries, and unsubscribe rules. Strong answers plan channel-specific templates, delivery status, backpressure, and graceful degradation when real-time delivery is unavailable.

Red flag: They send every notification synchronously during the user request.

Listen for: Strong answers consider read models, scheduled aggregation, queued jobs, materialized tables, cache invalidation, database indexes, and separating OLTP from analytical queries where needed. They define freshness requirements, drill-down behavior, authorization, export handling, and monitoring for long-running jobs or lock-heavy queries.

Red flag: They run complex aggregate queries directly against production tables on every dashboard page load.