PHP Backend Developer Top 100 Interview Questions

Make checkout a sequence of explicit, recoverable steps: validate the cart, reserve stock, create the order, take payment and confirm. Each step must be safe to retry, and the slow or unreliable parts, such as payment confirmations and emails, are handled asynchronously.

flowchart TD
  A["Validate cart, prices and address"] --> B["Create pending order with idempotency key"]
  B --> C["Reserve stock atomically"]
  C --> D["Redirect to payment or confirm payment intent"]
  D --> E["Payment webhook received and verified"]
  E --> F["Mark order paid, commit"]
  F --> G["Queue emails, invoices and fulfillment"]
  D -->|"Payment fails or times out"| H["Release stock reservation"]

Key decisions:

1. Prices recalculated on the server, never trusted from the client.
2. Idempotency keys on order creation, so double submissions create one order.
3. Atomic stock reservation with conditional updates, plus expiry for abandoned checkouts.
4. Payment status from verified webhooks, not only from the browser redirect, which users can close.
5. State machine for orders, with allowed transitions such as pending to paid to shipped.
6. Money in integer minor units with explicit rounding.
7. Asynchronous side effects through a queue, recorded in the same transaction as the order change.

Let clients upload directly to object storage with short-lived signed URLs, record the upload in the database and process images in background workers. PHP web workers never handle large file bytes, so they stay available for normal requests.

flowchart LR
  A["Client requests upload URL"] --> B["PHP issues signed URL with limits"]
  B --> C["Client uploads directly to object storage"]
  C --> D["Storage event or client confirmation"]
  D --> E["Queue processing job"]
  E --> F["Worker validates, re-encodes and resizes"]
  F --> G["Store variants and update the record"]
  G --> H["Content delivery network serves images"]

Design points:

1. Signed URLs restrict size, content type and expiry, and use generated object names.
2. Validation in the worker: check the real file type from its content, reject oversized dimensions and re-encode images, which removes embedded scripts and metadata such as location.
3. Variants: thumbnails and sizes generated once and cached.
4. States: uploaded, processing, ready and failed, so the interface can show progress.
5. Retries and dead-letter handling for processing failures.
6. Cleanup: delete orphaned uploads that were never confirmed.
7. Privacy: private images served through short-lived signed download URLs.

Layer caches from the edge inward: cache public pages and API responses at a content delivery network, cache computed product data in a shared store and keep the database as the source of truth. Invalidate from the source when products change, so caches stay fresh without short lifetimes everywhere.

flowchart LR
  A["Users"] --> B["Content delivery network: pages and images"]
  B --> C["PHP application"]
  C --> D["Shared cache: product data"]
  D -->|Miss| E["Database"]
  F["Product updated in admin"] --> G["Invalidation event"]
  G --> B
  G --> D

Design points:

1. Cache keys by product and version, including language and currency, so variants never mix.
2. Edge caching for anonymous traffic, with personalized parts, such as cart counts, loaded separately.
3. Event-driven invalidation: an update publishes an event that purges the edge cache and deletes the shared cache entry.
4. Stampede protection when popular entries expire, by letting one request rebuild while others serve stale data briefly.
5. Warm the cache for the most popular products after deployments or purges.
6. Prices and stock often need shorter lifetimes or live lookups, since stale values cause real problems.

Measure hit rates at each layer, and set alerts when they drop.

Identify the tenant on every request, from the domain, a path segment or the authenticated user, store it in a request-scoped context and make every data access filter by it automatically. Choose the isolation model by compliance requirements, tenant size and operational cost.

Making isolation reliable:

1. Resolve the tenant once in middleware, and reject requests where the tenant cannot be determined.
2. Enforce filters centrally, in a repository base class, query builder scope or database row-level security.
3. Include the tenant in cache keys, file storage paths, queue jobs and logs.
4. Test isolation explicitly: automated tests that try to read another tenant's data.
5. Protect against noisy tenants with per-tenant rate limits and quotas.

PHP arrays preserve insertion order, so they can serve as both the lookup table and the recency list. On every read, remove the key and insert it again, so it moves to the end; when the cache is full, remove the first key, which is the least recently used.

Operations:

• get: if the key exists, unset it, set it again and return the value.
• set: unset any existing entry, add the new value at the end and remove array_key_first if the count exceeds the capacity.

Points to know:

1. Integer-like string keys become integers, which still works but can surprise when keys are printed or merged.
2. Each worker has its own cache, and in the request-per-process model it disappears at the end of the request, so this structure suits per-request memoization or long-running workers.
3. Use a shared cache for data that must survive across requests.
4. Capacity by count is simple; very different value sizes may need a memory-based limit.

Loop once over the records, build a summary keyed by the grouping field, accumulate counts and totals and then sort the summary for presentation. A single pass is clearer and faster than repeated filtering for each group.

Steps:

1. Initialize each group's entry the first time it is seen, with ??=.
2. Add counts and totals, and track nested breakdowns, such as revenue per product within each region.
3. Sort groups with uasort and a comparison using the spaceship operator <=>.
4. Pick the top item within each group with arsort and array_key_first.

When to do it in SQL instead: for large data, GROUP BY in the database is far more efficient, since only the summary travels to PHP. Use PHP grouping for data already in memory, such as API results, or small sets.

Typing tip: for anything beyond simple reports, convert rows into small value objects, so field names are checked and the summary code is easier to read.

Lowercase the text with multibyte functions, replace every run of characters that are not letters, combining marks or digits with a single hyphen and trim hyphens from the ends. Using Unicode character classes in the regular expression keeps letters from every script.

Details that matter:

1. The u modifier makes the regular expression work on UTF-8 characters instead of bytes.
2. \p{L}, \p{M} and \p{N} match letters, combining marks and digits in any language; leaving out \p{M} breaks scripts that use combining vowel signs.
3. mb_strtolower lowercases non-English letters correctly.
4. Uniqueness: check the database, and append a short suffix when a slug is already taken.
5. Transliteration to plain ASCII is optional; it needs the internationalization extension and loses meaning for some languages.

Stability: once published, a slug is part of a URL that users and search engines remember; keep old slugs as redirects when titles change.

Wrap the operation in a loop that catches retryable exceptions, waits for an exponentially growing delay with random jitter and gives up after a fixed number of attempts, rethrowing the last exception. Injecting the sleep function makes the logic easy to test without real waiting.

Design points:

1. Retry only transient failures, such as timeouts and 503 responses, by catching specific exception types.
2. Exponential delay: base × 2^(attempt − 1), capped at a maximum.
3. Jitter: randomize part of each delay with random_int, so many workers do not retry together.
4. Total time budget: in web requests, stop retrying long before the request's own timeout.
5. Idempotency: retry only operations that are safe to repeat, or use idempotency keys.
6. Background jobs are often a better place for retries than web requests, since they can wait longer.

Use reflection to read a class's constructor parameters, resolve each typed dependency recursively from the container and create the object. Bindings map interfaces to concrete classes, and created services are stored, so each one is shared.

How autowiring works:

1. Look up a binding for the requested type, or use the type itself if it is a concrete class.
2. Read the constructor's parameters with ReflectionClass.
3. For each class or interface type, resolve it from the container.
4. For scalar parameters, use the default value, or fail with a clear message naming the parameter.
5. Create the instance with the resolved arguments, and cache it.

Production considerations:

• Compile or cache the resolution in production, since reflection on every request is wasteful.
• Support factories for services that need configuration values or complex setup.
• Detect circular dependencies and report them clearly.
• Keep the container out of business code: only the composition root asks it for services.

Store counters in shared storage and update them atomically in a single statement. A fixed-window limiter counts hits per key per time window; an upsert that increments and returns the new count avoids race conditions between workers.

Algorithm:

1. Compute the current window: intdiv(now, window length).
2. Insert a row for the key and window with one hit, or increment the existing row, and return the new count, all in one statement.
3. Allow the request if the count is within the limit; otherwise reject it with status 429 and a Retry-After header.
4. Delete old windows periodically.

Choosing the store: an in-memory cache server is the usual choice for speed, using its atomic increment with an expiry; a database table works for moderate traffic and keeps the example simple.

Limits of fixed windows: a client can send twice the limit around a window boundary; sliding windows or token buckets smooth this when it matters.

Modernize incrementally while the application keeps running: add tests around critical behavior, introduce structure at the edges and replace old patterns one area at a time. Big-bang rewrites of large PHP applications usually take far longer than planned and reintroduce fixed bugs.

A practical sequence:

1. Upgrade PHP to a supported version, fixing deprecations along the way.
2. Add a dependency manager and autoloading, replacing manual require chains.
3. Add characterization tests that record the current behavior of important pages and endpoints, before changing them.
4. Introduce a front controller that routes new URLs to new code while old scripts keep working.
5. Extract business logic from mixed templates and scripts into typed, tested classes.
6. Replace unsafe patterns: string-built SQL with prepared statements, unescaped output with escaped templates and globals with injected dependencies.
7. Add static analysis with a baseline, so new code is clean and old issues shrink over time.
8. Automate deployment with atomic releases.

Keep measuring: error rates and performance before and after each change, so improvements are visible and regressions are caught early.

Know what you depend on, update it regularly, check it automatically for known vulnerabilities and limit the risk any one package can cause.

Practices:

1. Commit the lock file and install from it in every environment, so versions are exactly what was tested.
2. Audit in continuous integration: the dependency manager can check installed packages against vulnerability advisories and fail the build on known issues.
3. Update on a schedule, such as weekly for patch releases, with automated pull requests and tests.
4. Review new dependencies before adding them: maintenance activity, security history, size and transitive dependencies.
5. Remove unused packages, since every package is code you must keep patched.
6. Be careful with install scripts, which run code during installation, and disable them where not needed.
7. Mirror packages for builds, so removed or tampered packages cannot break or poison deployments.
8. Update PHP and extensions too, since the runtime itself receives security fixes.

Also consider abandoned packages: a package with no recent releases may not get fixes; plan to replace it before a vulnerability forces a rushed change.

Separate all user-visible text from code, format numbers, dates and currencies with locale-aware functions and store everything as UTF-8. The internationalization extension provides formatting and plural rules for every locale.

Key pieces:

1. Translation catalogs: message keys mapped to translations per locale, loaded through a translation function in templates and code.
2. Placeholders and plurals: messages with named placeholders and plural rules, because languages have different plural forms, such as one, few and many.
3. Formatting: number, currency and date formatters for the user's locale, never hand-written formats.
4. Locale selection: from the user's profile, then the browser's language preference, with a default.
5. Time zones: store UTC and display in the user's time zone.
6. Collation and search: sort and compare text with locale-aware rules where order matters.

Practical tips:

• Do not build sentences by concatenating translated fragments; word order differs between languages.
• Leave room in layouts, since translations can be much longer.
• Support right-to-left scripts in templates where needed.
• Keep translations in version control, and check for missing keys in continuous integration.

Design resources around business concepts, keep a consistent style for URLs, errors, pagination and filtering and make changes additive, so existing clients keep working as the API grows.

Consistent conventions:

1. Resource-oriented URLs: /orders, /orders/{id}, /orders/{id}/items, with standard methods.
2. Status codes used correctly: 201 for creation with a Location header, 204 for successful deletion, 4xx for client errors and 5xx for server errors.
3. One error format with machine-readable types and field-level validation messages.
4. Cursor-based pagination with a maximum page size.
5. Explicit filters and sorting from allowlists.
6. Idempotency keys for operations that create or charge.

Evolving safely:

• Additive changes: new optional fields and new endpoints, never renamed or removed ones.
• Tolerant clients and servers: ignore unknown fields where safe, and document it.
• Versioning only for genuinely breaking changes, with old versions running during migration.
• Deprecation process: announce, add warning headers, track usage and remove only when traffic is gone.

Separate API data from storage: map database rows to response objects explicitly, so schema changes do not leak into the API.

Return a response to the user quickly and do the slow work elsewhere. PHP offers a simple option, finishing the response before continuing, and a robust one, handing the work to a queue processed by background workers.

Designing the queued approach:

1. Return 202 Accepted with a link to check the job's status, for long tasks such as reports.
2. Save the job and the business change together, or use an outbox, so no job is lost or orphaned.
3. Make jobs idempotent and retry with backoff.
4. Notify the user when the work finishes, by email, a notification or status polling.

Collect three kinds of signals: structured logs, metrics and distributed traces, all tagged with a request ID and release version. In the request-per-process model, each request is short-lived, so signals must be sent or written quickly without slowing the response.

What to collect:

1. Request metrics: rate, error rate and latency per route, from the web server, the process manager or the application.
2. Process manager health: active and idle workers, queue length and slow requests.
3. Dependency metrics: database query time, cache hit rate and external API latency and errors.
4. Traces: spans for the request, queries and outgoing calls, with trace context propagated to other services through headers.
5. Logs: JSON records with the request ID, user or tenant identifier where allowed and error details.
6. Background workers: job duration, failures, retries and queue age.

Implementation tips:

• Send telemetry to a local agent or collector over a fast local channel, so a slow backend does not slow requests.
• Use the process manager's slow log to capture stack traces of requests that exceed a threshold.
• Sample traces at high traffic, keeping all errors.
• Never include secrets or sensitive personal data in any signal.

Focus review time on security, correctness and maintainability issues that tools miss, and let formatters and static analysis catch style and type problems automatically.

Checklist:

1. Types: declare(strict_types=1);, typed parameters, returns and properties, and no loose comparisons.
2. SQL: prepared statements everywhere, no string-built queries and identifiers from allowlists.
3. Output: escaping for HTML and other contexts, no raw user data in templates.
4. Input: validation at the boundary, size limits and no trust in client headers.
5. Authentication and authorization: checks on every endpoint, including ownership of the resource being accessed.
6. Errors: exceptions instead of silent failures, no @ suppression and no sensitive details in responses or logs.
7. Resources and performance: no queries inside loops, streaming for large data and timeouts on external calls.
8. State: no global variables or request data in static properties, especially in long-running workers.
9. Dependencies: new packages justified and reviewed.
10. Tests: behavior and failure paths covered.

Interview tip: naming one dangerous function you always flag, such as unserialize on user input or extract, and explaining why, shows practical security awareness.

PHP is strong for web applications and APIs with a simple, robust execution model and very easy hosting. Other approaches can be better fits for long-lived connections, heavy computation or teams with different experience.

Questions that decide it:

1. What does the team already know and operate well?
2. Does the workload involve many long-lived connections or heavy computation?
3. Which existing systems, libraries and hosting options must it fit?

Modern PHP with strict types, static analysis and a good architecture is a solid choice for most web backends; the deciding factor is usually the team and the workload, not the language's reputation.

Tell one project as a story: what the system did, your role, the key decisions, a hard problem you solved and the measured results. Interviewers want to see that you write modern, secure PHP and understand how it runs in production.

1. Context: the application, its users and its scale, such as requests per minute or orders per day.
2. Your role: what you personally designed or built.
3. Decisions: how you structured the code, handled data access, secured the application, cached and used queues, and why.
4. A hard problem: an N+1 query issue, a memory limit in a batch job, duplicated webhooks, a session problem behind load balancers or a legacy migration, with the evidence that led to the fix.
5. Quality: tests, static analysis level and deployment process.
6. Results: numbers such as "checkout errors fell by 80%" or "the export now runs in 4 minutes instead of 2 hours".
7. Reflection: what you would change now.

What the interviewer is listening for:

• Modern practices: types, dependency injection, prepared statements and tests.
• Understanding of the execution model, process manager and caching.
• Pragmatic trade-offs and measurable impact.

Interview tip: if your experience includes legacy code, describe how you improved it step by step; interviewers value safe modernization highly.

Describe the incident from detection to prevention, focusing on how you restored service first and then found the cause with evidence such as logs, slow request traces, process manager status and database metrics.

1. Detection: the alert or customer report, and how quickly it arrived.
2. Impact: what users experienced, for how long and how many were affected.
3. Mitigation: rollback, disabling a feature, scaling workers or blocking abusive traffic, and why you chose it.
4. Diagnosis: for example, the process manager showing all workers busy, slow logs pointing to one query and the database showing a missing index after a deployment.
5. Root cause and contributing factors: such as a migration that dropped an index, or a missing timeout on an external call.
6. Fix: the change and the test or check that proves it.
7. Prevention: alerts on worker saturation, query reviews in deployment, timeouts by default and runbook updates.

What the interviewer is listening for:

• Clear priorities under pressure: users first, then root cause.
• Evidence-based investigation rather than guesses.
• Blameless, system-focused language.
• Lasting improvements, verified after the fix.