Lesson 1 of 5
What PHP Interviews Probe
"The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function." — F. Scott Fitzgerald, The Crack-Up (1936)
A PHP interview asks two different kinds of question and rarely says which is which. Some are trivia — comparison tables, reference semantics, the behaviour of empty() — testing whether you have memorised a list of quirks. Others are about the machine: what happens between a socket and a response, why the framework caches four different things, what survives between requests and what does not.
You need both, for different reasons, and confusing them is the mistake. This chapter separates them.
The trivia, answered by the runtime
Click Run to execute the code.
Every answer there came from the runtime rather than from memory, which is the only way to be sure about a list like this — several entries changed in PHP 8, and material written before 2020 will tell you 'abc' == 0 is true.
The honest assessment is the last block. Most of this does not predict whether somebody can build software; it persists because it is cheap to ask and cheap to mark. But a few entries earn their place because they cause real bugs: '0' being empty, foreach by reference leaving a dangling alias, strlen counting bytes rather than characters.
So learn it — an interviewer who asks is not going to be talked out of the question — and do not mistake learning it for preparation.
Think about the difference between a driving theory test and a driving test. The theory test asks what a particular sign means and what the stopping distance is at 50mph — facts with exact answers, cheap to mark, and genuinely useful, since a driver who does not know the sign is dangerous. It also does not tell you whether somebody can drive. The practical test cannot be marked by a machine, takes an examiner an hour, and measures something the theory test cannot reach: whether you notice the cyclist, whether you commit to a gap or dither in it, whether you recover from a mistake. Every licensing authority runs both, because each catches what the other misses, and nobody thinks the theory test is the real one. Technical interviews are the same pair without the labels. Some questions have exact answers and are cheap to ask; some require watching you work. The mistake candidates make is preparing only for the first kind, and the mistake interviewers make is believing the first kind is sufficient.
What separates a junior answer from a senior one
Click Run to execute the code.
Three answers, all correct, differing only in coverage. That is worth stating plainly because it changes what preparation means: you are almost never trying to avoid being wrong, you are trying to go further before stopping.
The rubric generalises beyond this question. Naming a problem shows you have met it; explaining the mechanism shows you are not reciting; knowing when the standard fix is the wrong fix shows you have watched it cause harm; and being able to measure it means a disagreement ends in a number rather than seniority.
The practical form is four sentences — name it, explain it, give the trade, say how you would verify. Most answers stop after two.
PHP's interview culture carries the marks of its reputation, and the reputation has a specific origin. For roughly a decade from the late 1990s, PHP was the language you could learn by viewing source and editing a file over FTP, which made it extraordinarily successful and produced an enormous body of terrible code written by people who were not programmers and did not claim to be. By 2005 "PHP developer" had a connotation, and the widely-read essay that crystallised it — Eevee's PHP: a fractal of bad design in 2012 — is a fair critique of PHP 5 that is now substantially obsolete, since a large fraction of its complaints were fixed in PHP 7 and 8. The interview consequence is that PHP candidates are still screened for competence in a way that, say, Go candidates are not: the trick questions exist partly to filter out people who learned PHP from a 2009 tutorial and never updated. That is worth understanding rather than resenting, because it tells you what a strong answer does. Demonstrating that you know when a behaviour changed — that 'abc' == 0 was true before PHP 8 and is false after, that mysql_* was removed in PHP 7, that password_hash arrived in 5.5 — does something no correct answer alone can: it proves you have been paying attention to a moving language rather than memorising a snapshot of it.
The thing that is actually PHP-specific
Click Run to execute the code.
This is the question a PHP interview exists to ask, and the one candidates most often underprepare.
A static variable persists within a request and vanishes between requests, because the process either dies or is reset. Everything operationally distinctive about PHP follows: sessions exist because state has to live outside the process, config and routes are cached to disk because they would otherwise be rebuilt every time, opcache exists because compilation would otherwise repeat, and a queue is a table because there is no in-process background thread.
The corollary is the part worth saying out loud in an interview. Shared-nothing forgives a whole class of bug — a singleton holding request state, a transaction left open by a throw, an unbounded static cache — right up until something long-lived runs your code. Naming that pattern signals that you have operated PHP rather than only written it.
Writing the trivia block, I predicted every answer before running it and got all of them right — which felt like confirmation until I noticed that I had also written the note "PHP 8: string vs int compares as STRING" from memory, and that the note is the part I would have been wrong about five years ago. The answers are stable; the reasons move. 'abc' == 0 was true for PHP's entire history until 8.0 changed the comparison rules in 2020, and anybody who learned the old behaviour and never revisited it is carrying a confident wrong answer with a confident wrong explanation attached. That is a specific hazard of trivia: a fact you memorised and never re-derived has no way of telling you it has expired. It is the same shape as the stale note about opcache I caught in the previous chapter, and the same shape as a cached value with no invalidation — which is, I notice, the third time in this volume that my own errors have turned out to be instances of the thing the chapter was about. I have stopped treating that as coincidence and started treating it as evidence that the failure modes we build systems to survive are the same ones our knowledge has.
The framework layer, which is one idea five times
Click Run to execute the code.
Five framework components, one architecture. Each reads a declaration you wrote, generates something executable, caches it, and checks a timestamp before reusing it — the container's resolution plan, the router's match table, Blade's compiled PHP, the merged config array, the event discovery map.
Which means they produce one family of bug five times, and it is the family where the source you are reading is correct and a generated artefact is what runs.
The interview value is in giving the general answer rather than five specific ones. "These are all generated artefacts, so before reading the source I would check what is actually executing" demonstrates that you have the shape rather than a memorised list of symptoms — and it is also, as this volume kept finding, the diagnostic that actually works.
Should you prepare for interviews by studying, or by building? The question is usually posed as if one must be wasted effort, and the honest answer is that they produce different things and most people need the one they are not doing. Building generates the material that makes senior answers possible — you cannot say "I have watched eager loading cause a memory problem" unless you have, and no amount of reading substitutes for having been on call when a cache flush took the site down. But building alone reliably leaves gaps in exactly the places your particular codebase never went: if you have never run a queue worker, no amount of shipping features will teach you that it holds old code across a deploy. Studying fills those gaps cheaply and produces knowledge with a characteristic weakness — it is unanchored, so it comes out as recitation, and an interviewer can tell within one follow-up question. The combination that works is to study in order to notice: read about the thing, then go and find it in a system you have access to, even if the system is a toy. That is what this entire volume has been doing, and the reason every chapter measures rather than asserts is that a fact you have seen behave has a different quality in your mouth than a fact you have read. If you have limited time before an interview, the highest-return activity is not more reading and not more building — it is taking the three things you already half-know and running them until they surprise you.
Knowing which room you are in
Click Run to execute the code.
Four formats asking four different questions, and the failure modes differ: vagueness kills a screening call, memorised patterns kill a design round, over-engineering kills a take-home, and silence kills live coding.
The universal-versus-specific table is the one to plan preparation around. N+1, at-least-once delivery, cache invalidation, injection and idempotency transfer to every stack you will ever work in, so time spent there is never wasted. The PHP-specific rows are what a PHP interview is for, and shared-nothing is the one that most reliably separates people who have used PHP from people who have understood it.
And the four sentences are the whole of the technique. Name it, explain it, give the trade, say how you would verify. The rest of this Part is four chapters of applying that to progressively harder situations.
The most common interview failure I have seen is not a wrong answer — it is an answer that stops at the first correct thing. Asked why a page is slow, a candidate says "probably N+1" and waits. That is very likely right, and it ends the conversation at the point where it was about to become informative, because the interviewer learns only that the candidate knows a term. The candidates who do well treat the first answer as an opening: "probably N+1, which I would confirm by counting queries rather than timing, because the count is the same in every environment; if it is, eager loading fixes it, though not if the page only needs a count, in which case with() would fetch every row and an aggregate is cheaper." That is thirty seconds and it covers recognition, verification, remedy and the remedy's limits. What makes it hard is not knowledge but a habit of stopping — the instinct that a question has been answered once something true has been said. In an interview the question is not "do you know the answer" but "how far can you go", and nobody will prompt you to continue. The practical fix is to decide in advance that every technical answer gets at least the four sentences, and to treat a pause after one sentence as a bug in your delivery rather than politeness.
Common Mistakes
Preparing only trivia. The comparison table is cheap to ask and does not predict whether you can build software. Learn it; do not mistake it for preparation.
Quoting pre-PHP-8 behaviour.
'abc' == 0wastrueuntil 8.0 changed it. A memorised fact has no way of telling you it has expired.Stopping at the first correct thing. "Probably N+1" is right and ends the conversation exactly where it was becoming informative.
Never mentioning the trade. Knowing when the standard fix is the wrong fix is the clearest available signal of having done this for real.
Being unable to say how you would verify. An answer that ends in a measurement settles disagreements; one that ends in an assertion needs you to be believed.
Treating shared-nothing as trivia. It is the one structural fact that makes PHP different, and almost everything about operating PHP follows from it.
Memorising five cache gotchas instead of the shape. Container, router, Blade, config and events are one architecture, and the general answer is worth more than the list.
Not noticing which format you are in. Vagueness fails a screening call, memorised patterns fail a design round, over-engineering fails a take-home, silence fails live coding.
Neglecting the universal topics. N+1, idempotency, invalidation and injection transfer to every stack, so that preparation is never wasted.
Silence while thinking in live coding. The format is explicitly measuring how you think, and thinking invisibly scores zero.
Interview Corner
'abc' == 0 in PHP, and why is that a slightly unfair question?false in PHP 8 and later. It was true for PHP's entire history before that, because a non-numeric string was cast to 0 before comparison; PHP 8.0 changed the rules so a number compared against a non-numeric string is compared as a string instead. It is slightly unfair because the answer depends on a version boundary rather than on understanding, and material written before 2020 confidently gives the opposite answer. The defensible thing to say is both the current answer and when it changed — which demonstrates that you have followed a moving language rather than memorised a snapshot.route:cache produces a compiled table, and if one exists it is what runs regardless of what the source says. So the first question is whether a cached route file is present and when it was written. The same reasoning covers a family of symptoms — a config value that is null in production because config:cache ran and env() was called outside config/, a Blade change that does not appear because the compiled file has a newer timestamp, a container binding that is not resolving. Container, router, views, config and events are all the same architecture: read a declaration, generate something executable, cache it, check a timestamp. Which means "read the code" stops being a diagnostic until you know which code is executing, and the general habit is to ask the running system what it currently believes rather than deducing it from files.Hands-on
Model the interview rules this chapter measured. Implement answerLevel, the coverage rubric; survivesRequest, shared-nothing; isGenerated, the artefact family; topicScope, PHP-specific against universal; and formatFailure, what sinks each round. A stub scores zero, so a passing run means the model is real.
Click Run to execute the code.
Summary
- PHP interviews ask two kinds of question: trivia with exact answers, and questions about the machine. Both matter, for different reasons.
- Several trivia answers changed in PHP 8 —
'abc' == 0and'' == 0are nowfalse— so a memorised fact may have expired without telling you. - The trivia worth knowing is the subset that causes real bugs:
'0'is empty,foreachby reference leaves a dangling alias,strlencounts bytes. - Answers differ by coverage, not correctness. Name it, explain the mechanism, give the trade, say how you would verify — most stop after two.
- The two senior signals are knowing when the standard fix is wrong, and being able to measure. Neither is about knowing more; both come from having watched advice fail.
- Shared-nothing is the PHP-specific fact. Sessions, opcache, config caching and table-backed queues all follow from it.
- It also forgives a class of bug — request state in a singleton, a transaction left open — until something long-lived runs your code.
- Container, router, Blade, config and events are one architecture: read a declaration, generate, cache, check a timestamp.
- Which produces one family of bug five times, where the source is correct and a generated artefact is what runs.
- Formats fail differently: vagueness, memorised patterns, over-engineering and silence each sink a different round.
Next: the request lifecycle at the whiteboard — narrating the path from socket to response, and the follow-up questions that separate a rehearsed answer from an understood one.
There is something uncomfortable about writing an interview chapter for a volume that has spent thirty-five chapters insisting on measurement, because interviews are the least measurable thing in software. Almost every claim here is a generalisation from experience rather than a number, and the runnable blocks model the interview rather than testing it — which is a weaker form of evidence and I would rather say so than dress it up. What I do think survives the scrutiny is the coverage rubric, because it is falsifiable in a useful way: the difference between a junior and a senior answer to the same question is not a disagreement about facts but a difference in how much territory gets covered before stopping, and that is something you can check against your own answers. The wider observation is that this Part exists because knowing something and being able to demonstrate knowing it are genuinely different skills, and pretending otherwise does candidates no favours. The volume's method — go and run it until it surprises you — happens to produce exactly the material that makes strong interview answers possible, not because it is designed for interviews but because "I have seen this behave" and "I have read about this" come out of your mouth differently, and everybody on the other side of the table can hear which one it is.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.