25 PHP interview questions

Listen for: A strong answer starts with logs, request IDs, error reporting configuration, and reproducing the failing path with safe test data. They should mention checking recent deploys, environment differences, dependencies, database state, and stack traces. Good candidates avoid guessing and describe narrowing the issue while protecting production data.

Red flag: They jump straight to editing code in production or enabling verbose errors for users.

Listen for: Listen for separation between client-side convenience and server-side enforcement, use of framework validation, normalization, unique constraints, password hashing with password_hash or framework defaults, CSRF protection, and clear error messages. They should understand that validation, authorization, and persistence are separate concerns.

Red flag: They rely mainly on JavaScript validation or manually concatenate user input into SQL.

Listen for: Good candidates consider query count, N+1 queries, missing indexes, excessive template work, and unnecessary API calls. They may mention Laravel Debugbar, Symfony Profiler, database logs, EXPLAIN, and pagination. The answer should show they measure before optimizing and know common PHP application bottlenecks.

Red flag: They propose caching everything before checking database queries or measuring the problem.

Listen for: A solid answer keeps controllers thin: request parsing, authorization calls, invoking application services, and returning responses. Business rules, coordination, transactions, and integrations belong elsewhere. They should avoid rigid patterns for simple CRUD but recognize when duplication, testability, or complexity justifies extracting services.

Red flag: They say all logic should either live in controllers or always be hidden behind services without context.

Listen for: Look for a mix of feature tests around the HTTP or command boundary and unit tests only where logic is nontrivial. They should mention database transactions or refreshes, factories/fixtures, faking mail or queues, asserting side effects, and keeping tests deterministic in PHPUnit or Pest.

Red flag: They only test private methods or say manual testing in the browser is enough.

Listen for: They should inspect composer.json and composer.lock changes, read the dependency error, check PHP extension and version constraints, and use targeted updates where possible. Strong juniors know not to delete files randomly and can explain lock files, semantic version ranges, and when to ask for review.

Red flag: They delete the lock file and vendor directory every time without understanding the dependency change.

Listen for: Strong answers isolate provider-specific code behind an interface or adapter, handle retries and idempotency, verify webhooks, log correlation IDs, and model payment states explicitly. They discuss secrets management, sandbox testing, failure modes, and how to avoid coupling business logic directly to the provider SDK.

Red flag: They put provider SDK calls directly in controllers and assume successful responses are final.

Listen for: Listen for understanding of transaction boundaries around related writes, rollback behavior, deadlocks, isolation concerns, and keeping transactions short. They should know how Laravel DB::transaction or Doctrine transactions behave. Good answers avoid external HTTP calls inside transactions and plan for after-commit events or outbox patterns.

Red flag: They wrap entire request flows in transactions, including API calls and email sending.

Listen for: They should discuss idempotent job design, unique job keys, deduplication records, checking retry and backoff configuration, poison queues, and making side effects safe. Strong candidates inspect logs and payloads, distinguish transient from permanent errors, and add observability instead of only increasing retry counts.

Red flag: They disable retries completely without addressing why duplicates happen.

Listen for: Good answers include inventorying dependencies, running static analysis, upgrading Composer constraints, using Rector or PHP-CS-Fixer, running tests under the new runtime in CI, checking deprecations, and staging rollout. They should mention extensions, Docker images, framework compatibility, and rollback planning.

Red flag: They treat a runtime upgrade as just changing the Docker tag on production.

Listen for: Look for measurement: slow logs, request duration, worker settings, CPU and memory, upstream latency, database time, cache hit rate, and queue offloading. They may discuss pm.max_children, opcache, timeouts, load shedding, and horizontal scaling, but should avoid tuning blindly before identifying bottlenecks.

Red flag: They only increase max_children without checking memory, downstream dependencies, or request latency.

Listen for: Strong candidates mention clear module boundaries, coding standards, static analysis with PHPStan or Psalm, automated tests, API contracts, ownership of shared libraries, and incremental refactoring. They understand when to use packages or bounded contexts and how to prevent framework conventions from becoming hidden coupling.

Red flag: They rely on code reviews alone and have no strategy for boundaries or automated feedback.

Listen for: Listen for a concrete production problem, the signal that revealed it, the root cause, and changes such as better validation, idempotency, timeouts, retries, logging, metrics, tests, or runbooks. Strong answers include trade-offs and how they verified the feature stayed reliable after release.

Red flag: They cannot describe any measurable or observable improvement beyond rewriting the code.

Listen for: A strong answer weighs team ownership, deploy cadence, data boundaries, failure isolation, operational maturity, and transaction complexity. They should not default to microservices. Look for strangler-style extraction, clear contracts, async integration where useful, and awareness that distributed systems add debugging and consistency costs.

Red flag: They recommend microservices mainly because the codebase is large or old.

Listen for: Listen for modeling a state machine, identifying invariants, adding idempotency keys, using transactions for local state, after-commit dispatch, outbox or saga patterns, and reconciliation jobs. Good seniors prioritize stopping data corruption first, then backfilling and improving observability around transitions.

Red flag: They propose manually fixing bad rows and adding more retries without changing the design.

Listen for: Strong answers go beyond generic OWASP lists. They cover authentication flows, authorization checks near sensitive actions, CSRF and session settings, SSRF risks in integrations, file upload handling, deserialization risks, dependency scanning, secret rotation, logging hygiene, and secure defaults in Laravel or Symfony.

Red flag: They focus only on SQL injection and assume the framework handles all other security concerns.

Listen for: They should describe starting with a baseline, choosing PHPStan or Psalm levels pragmatically, adding typed boundaries first, using Rector for mechanical changes, enforcing new code standards in CI, and creating a migration path. Strong answers balance safety with delivery and avoid large risky rewrites.

Red flag: They want to stop feature work until the entire legacy codebase is fully typed.

Listen for: Look for tracing, timeout budgets, circuit breakers, bulkheads, caching, async workflows, fallbacks, and clear SLO-style thinking without hand-waving. They should identify which calls are required for the response, which can be deferred, and how to avoid tying PHP-FPM workers to slow dependencies.

Red flag: They only suggest increasing request timeouts so the API has more time to finish.

Listen for: Strong seniors look at correctness, domain invariants, backwards compatibility, migration safety, test coverage at the right level, observability, failure behavior, and readability. They ask whether the change belongs in the chosen layer and whether the rollout plan protects existing customers and data.

Red flag: They review mostly style and formatting while ignoring behavior, data migration, and operational risk.

Listen for: Listen for humility, evidence, and leadership. A strong answer names the original constraints, what changed, how they gathered data, how they communicated the reversal, and how they reduced migration pain. Senior engineers should be comfortable revisiting decisions without blaming others.

Red flag: They cannot name a decision they reversed or frame every reversal as someone else's failure.

Listen for: Strong candidates define payment and subscription states, verify webhook signatures, use idempotency keys, persist raw events, and process state changes asynchronously. They discuss database transactions, after-commit jobs, reconciliation with the provider, dead-letter queues, audit logs, and how Laravel queues or Symfony Messenger would be operated.

Red flag: They assume webhooks arrive once, in order, and can directly grant access from the controller.

Listen for: Look for separation between source-of-truth data and read models, caching strategy, pagination, search engine use such as OpenSearch or Meilisearch, invalidation on product changes, and protection against expensive filters. They should mention profiling PHP endpoints, opcache, database indexes, and contract stability for clients.

Red flag: They propose one large SQL query for every request and rely only on vertical scaling.

Listen for: Strong answers cover upload validation, streaming reads instead of loading whole files, chunking, queue jobs, progress tracking, resumability, validation errors, transactional batch writes, and rate limits on downstream calls. They should address memory limits, timeouts, worker concurrency, and user-facing status reporting.

Red flag: They process the entire file synchronously in an HTTP request.

Listen for: Candidates should compare shared-schema, schema-per-tenant, and database-per-tenant approaches with operational trade-offs. Listen for tenant resolution, authorization, query scoping, migrations, backups, secrets, feature flags, and preventing cross-tenant cache leaks. Strong answers include tests or safeguards that catch missing tenant constraints.

Red flag: They add a tenant_id column but do not discuss enforcement, caching, or operational isolation.

Listen for: Strong candidates distinguish user sessions, API tokens, OAuth2/OIDC, service credentials, scopes, roles, and permission checks. They discuss token storage, rotation, CSRF for browser flows, rate limiting, audit logs, and framework support such as Symfony Security or Laravel Sanctum/Passport without blindly choosing one.

Red flag: They use one long-lived shared API key for all clients and rely on obscurity.