PHP-specific interview questions covering modern language features, frameworks, testing, and best practices.
Show a before/after: "Previously I used string constants for order status. Now I use a backed enum, which gives me type safety, autocomplete, and easy database serialisation."
Good answers explain that typed properties (PHP 7.4+) eliminate the need for manual type checks in setters and make code self-documenting. Enums (PHP 8.1) replace magic strings and class constants with proper type-safe values. Strong candidates give concrete examples: enums for status fields, typed properties in DTOs, and discuss how both improve IDE support and static analysis.
Tests awareness of modern PHP. Candidates stuck on PHP 5.x patterns are a concern. Look for practical understanding, not just feature awareness.
Mention the optimised autoloader for production: "In deployment, we run composer dump-autoload --classmap-authoritative to eliminate filesystem checks."
PSR-4 maps namespace prefixes to directory paths and loads classes on demand. Classmap scans directories and builds a static map of every class. PSR-4 is standard for application code. Classmap is useful for legacy code that does not follow PSR-4 naming. In production, running composer dump-autoload --optimize generates a classmap from PSR-4 mappings for faster loading.
Fundamental PHP ecosystem knowledge. Developers who cannot explain autoloading likely have gaps in understanding dependency management and project structure.
Show framework maturity: "Symfony compiles the container at build time so there is zero runtime resolution cost. Laravel resolves at runtime which is simpler but slightly slower."
Symfony uses a compiled container with explicit service definitions (YAML/XML/PHP attributes), autowiring by type-hint, and auto-configuration. Laravel uses a runtime container with simpler binding syntax, automatic resolution, and service providers. Strong answers discuss trade-offs: Symfony is more explicit and performant for large apps; Laravel is more convenient for rapid development. Best candidates have used both and can articulate when each approach shines.
Tests depth beyond surface-level framework usage. Candidates who only know one framework should still be able to discuss DI principles clearly. Red flag: confusion between service container and service locator pattern.
Lead with measurement: "I profiled with Blackfire, found 60% of request time was N+1 queries, added eager loading, and reduced response time from 800ms to 120ms."
Strong answers mention profiling tools (Xdebug, Blackfire, Tideways) before optimising. Common optimisations: OPcache tuning, database query optimisation (N+1 queries, missing indexes), caching layers (Redis/Memcached), reducing autoloader overhead, preloading (PHP 7.4+), and JIT (PHP 8.0+). Best candidates describe a specific scenario with measurable before/after improvements.
Senior-level question. Developers who optimise without profiling are guessing. Those who can show a systematic approach to performance work are valuable. Ask what tools they use and whether they have production-level profiling experience.
Show a clear philosophy: "I use exceptions for truly unexpected failures and result objects for expected business-logic outcomes like validation. This keeps the happy path clean."
Good answers distinguish between exceptional situations (database down, invalid state) that warrant exceptions and expected outcomes (validation failure, not found) that may use result objects or specific return types. Strong candidates discuss custom exception hierarchies, global exception handlers, error logging, and how frameworks handle this. They mention the difference between Error and Exception in PHP 7+ and the Throwable interface.
Tests code design maturity. Candidates who use exceptions for flow control or silently swallow errors are problematic. Look for a thoughtful, consistent approach.
Be specific: "I unit test service classes with mocked repositories, integration test repositories against a real test database, and use data providers for edge cases."
Strong answers describe a testing pyramid: many unit tests for business logic, fewer integration tests for database/API interactions, and minimal end-to-end tests. Candidates should mention mocking dependencies, test databases, data providers, and code coverage as a guide (not a target). Best answers discuss testing strategies for specific patterns like repositories, services, and controllers.
Tests professional development practices. Developers without testing experience or who only write trivial tests are a risk for code quality. Ask about a bug they caught through testing.
Frame it as a trade-off: "Eloquent is faster to develop with for simple CRUD. Doctrine is better when domain logic is complex and I need entities that are independent of the database."
Active Record (Eloquent): model classes map directly to tables, simpler for CRUD, but business logic can leak into models. Data Mapper (Doctrine): entities are plain objects, the mapper handles persistence separately, better separation of concerns but more setup. Strong candidates discuss testability, complex domain logic, and when the overhead of Data Mapper is justified.
Senior question testing ORM understanding beyond basic usage. Candidates who cannot articulate trade-offs likely have not worked on complex enough projects. Look for experience with at least one pattern in depth.
Pick 2-3 features you actually use and show the improvement: "Constructor promotion cut our DTO boilerplate by 60%. Readonly properties eliminated an entire class of setter-related bugs."
Key PHP 8.x features: named arguments, match expression, constructor promotion, union/intersection types, readonly properties, enums, fibers, first-class callables. Strong candidates describe a real refactoring: reducing boilerplate with constructor promotion, replacing switch statements with match, using readonly properties for value objects, or using enums for state machines.
Tests whether candidates keep up with the language. Those still writing PHP 7.x style code are not leveraging modern tooling. Ask for a specific file or class they refactored.
Show layered thinking: "I use parameterised queries, encode all output, set CSP headers, run composer audit in CI, and use Argon2id for password hashing."
Key concerns: SQL injection (parameterised queries/ORM), XSS (output encoding, CSP headers), CSRF (tokens), session security (httponly/secure flags, regeneration), file upload validation, password hashing (bcrypt/argon2), and dependency vulnerabilities (composer audit). Strong candidates mention security headers, input validation vs output encoding, and defence in depth.
Critical for any PHP developer. Those who only mention SQL injection are thinking too narrowly. Look for awareness of the full attack surface including session handling and dependency security.
Lead with pragmatism: "I would not rewrite it. I would add tests around the most critical paths, extract business logic into classes, and modernise module by module while shipping features."
Best answers describe a pragmatic, incremental approach: add characterisation tests first, then extract logic from templates, introduce autoloading, wrap global state in injectable services, and migrate one module at a time. Strong candidates discuss the Strangler Fig pattern, setting up CI early, and resisting the urge to rewrite from scratch. They balance technical debt reduction with delivering business value.
Tests real-world maturity. Junior developers often want to rewrite everything. Seniors know that incremental modernisation is safer and more sustainable. Ask what they would do first and why.