There is a type of Symfony interview question that produces no signal. “What does the final keyword do on a class?” “Name the four built-in argument resolvers.” “When was the autowiring attribute added?” These are search queries dressed up as questions. A candidate can prepare for them by spending one evening on the Symfony documentation site. They tell you who studied for the interview. They do not tell you who can ship.
We have run a lot of Symfony interviews, on both sides of the table, and the questions that produced the engineers we actually wanted to work with were never trivia. They were scenarios, debugging walks, and reading exercises. They forced the candidate to think out loud about tradeoffs in real code and real systems, with no single correct answer. A senior engineer with five years on the framework gives a different answer than a junior with six months, and both answers can be good. That is the point.
This is the question set we currently use, what each one is designed to surface, and what a thin answer versus a strong answer actually looks like. None of these are gotchas. All of them are questions a good engineer will enjoy thinking through, which is itself a useful signal.
Why trivia filters out the wrong people
Before the questions, a note on the failure mode this set is designed to avoid.
A trivia-heavy interview filters for two things: recent exposure to the framework, and willingness to study for interviews. Neither correlates with engineering quality. We have rejected senior architects who could not name a recent Symfony release date and hired engineers who had to look up the autowiring syntax in their own previous PRs. The first group could redesign an event bus on a whiteboard. The second group could ship working code by Friday. Both were the right call.
The questions below try to surface the things that actually matter when someone joins a Symfony codebase: how they reason about tradeoffs, how they debug, how they read unfamiliar code, how honest they are about what they do not know.
The questions
1. “A user reports the dashboard is slow. Where do you start?”
What a trivia-style answer sounds like. “I would add a Stopwatch component, profile with the Symfony Profiler, check Doctrine queries.” The candidate names tools without explaining when they would reach for each.
What a strong answer sounds like. The candidate starts by asking questions back. Slow for one user or all users? Slow always or intermittently? Slow first load or every load? Then they sketch a path: reproduce, narrow (is it the controller, a query, a third-party call, the template render, the asset payload), confirm with measurement, fix the narrowest thing that explains the symptom. They name tools as they need them, not before. They mention that the answer might be “not slow, just feels slow” and that they would check with the user before assuming.
What it reveals. Whether the candidate has actually debugged production systems or has only read about debugging. The strong answer is shaped like an engineer who has been wrong about the cause before and learned to gather evidence first.
2. “Walk me through what happens between a browser hitting /login and a session being established.”
What a thin answer sounds like. “It hits the security firewall, the form login authenticator runs, the user is loaded, a session is created.” A correct-sounding bullet list with no depth.
What a strong answer sounds like. The candidate traces it: kernel boots, request enters, router matches, security firewall configuration determines which authenticator runs, the authenticator reads credentials from the request, the user provider loads the user, the password hasher verifies, the token is created and put into the token storage, the session is written, the response is built, the session cookie is set on the way out, the browser sends it back on the next request. They mention where this can go wrong: the user provider can be the wrong one if a firewall config is misordered, the session handler can be misconfigured (for example, file storage in production when Redis was expected), the cookie can be missing the Secure flag on a misconfigured proxy.
What it reveals. Depth across the stack. A candidate who can narrate the login flow can probably narrate any flow.
3. “When would you choose a value object over a typed scalar?”
What a thin answer sounds like. “When you want to encapsulate validation.” Single bullet, no examples.
What a strong answer sounds like. The candidate gives a few cases. Email and money are the classic ones. They explain that the value object earns its keep when the type is used in many places, when validation is non-trivial, when the type has its own behaviour (equality, comparison, formatting), or when you want to forbid an invalid instance from existing at all. They counter with cases where a value object is overkill: a single use site, a primitive that already has the constraint at the database level, a place where the type is genuinely just a string. They might mention the cost: more files, more allocations, friction with libraries that expect scalars.
What it reveals. Whether the candidate has a position on design or just patterns memorised from blog posts. Both extremes (always use value objects, never use value objects) are red flags.
4. “Your Messenger queue is backing up. What do you check, in what order?”
What a thin answer sounds like. “Add more workers.” The answer that solves the symptom without diagnosing the cause.
What a strong answer sounds like. The candidate triages. Are messages being consumed at all, or has the worker died? Are they being consumed but slowly, or are they failing and going to retry? Is the queue size growing because consumption stopped or because production spiked? They name where they would look: worker logs, dead letter queue, the rate of message production from the producer side, any external service that the handler depends on. Only after diagnosis do they mention scaling workers, and they note that scaling without understanding the cause can make a slow third-party call worse (more concurrent calls, more rate limiting, more failure).
What it reveals. Whether the candidate has run a message queue in production. The “add more workers” answer is the new-grad answer. The “what changed and why” answer is the on-call answer.
5. “Read this diff out loud and tell me what concerns you.”
Hand them a deliberately bad PR. Something like a controller that takes a raw user-supplied ID, passes it directly into a Doctrine repository, returns the entity, and renders it with no authorisation check. Add a couple of stylistic issues, one real security issue, one performance issue.
What a thin answer sounds like. The candidate fixes the style (“this should be final readonly”, “logger should be last in the constructor”). They miss the authorisation gap.
What a strong answer sounds like. The candidate triages. They start with the security issue (anyone can request any entity’s ID and get it back). They name the performance issue (this will N+1 in the template). They mention the style issues last, as polish, not as the headline. They flag what they cannot see in the diff (is there an upstream firewall that already gates this? what does the template actually do with the entity?) and ask for the missing context rather than assuming.
What it reveals. Code review judgment. Whether the candidate prioritises the right axes (security, then correctness, then performance, then style) or treats all comments as equal. Also, whether they can hold “I do not have enough context to be sure” alongside “but here is what I would ask”.
6. “When is it correct to break the repository pattern and write raw SQL?”
What a thin answer sounds like. “Never, the ORM handles everything.” Or, equally thin, “Always, ORMs are slow.”
What a strong answer sounds like. The candidate gives the actual cases. Reporting and analytics queries that join many tables in shapes the ORM hydrates badly. Bulk updates that the ORM would do one row at a time. Window functions, CTEs, or vendor-specific features that the ORM does not model well. They mention the tradeoffs of going raw: harder to refactor, no type safety on the result, harder to test, easier to drop into SQL injection if they are sloppy. They might propose middle grounds: hydrating raw SQL through DTOs, using DBAL directly while keeping the entity layer for the write path, isolating the raw SQL behind a repository method so the caller still gets a typed result.
What it reveals. Pragmatism versus dogma. Whether the candidate treats the ORM as a tool with a fit window or as a religion.
7. “You inherit a 200-controller monolith with no tests. What is your first PR?”
What a thin answer sounds like. “Write tests for the controllers.” A non-answer that ignores the scale of the problem.
What a strong answer sounds like. The candidate refuses the framing. They ask what the codebase is for, what is currently broken, what the team’s pain points are. Then they propose a small, safe first PR: maybe a CI pipeline that runs php -l, composer validate, and a static analyser at a low level. Or a single characterisation test around one critical path, with the explicit goal of letting them refactor that path safely. They explicitly avoid the temptation to start with a big bang (“rewrite the test suite”, “introduce hexagonal architecture”, “add DDD”). They mention that the first PR is partly about earning trust from the existing team, not just about technical merit.
What it reveals. Whether the candidate has actually inherited a monolith, or has only built greenfield. The greenfield engineer wants to clean up. The legacy engineer wants to land safely and build a beachhead.
8. “Tell me about a time you shipped something that broke production. What did you do?”
What a thin answer sounds like. “I have not really broken production.” Either the candidate is junior enough that this is true (fair), or they are dodging.
What a strong answer sounds like. A specific incident, recounted without defensiveness. What they shipped, what broke, how they noticed, what they did first, what they did second, what they learned, what changed about how they ship afterwards. The post-incident learning is the part that matters most: did the candidate change a process, write a runbook, add a check, advocate for something organisationally?
What it reveals. Honesty, ownership, and learning. We will not hire someone who cannot tell us about a failure. The job will produce failures; we need to know how the candidate metabolises them.
9. “Where does final readonly class fit in Symfony, and where does it not?”
What a thin answer sounds like. “It works for everything, you should always use it.” Confident but wrong.
What a strong answer sounds like. The candidate separates current facts from old proxy folklore. In PHP 8.4+ and current Symfony, lazy services support final and readonly; current Doctrine can also use native lazy objects for final or read-only entities. Then they name the real limits: readonly is a bad fit for a service that caches request state and must clear it in reset(), for mutable entities or DTOs populated after construction, or for code that a library or test double genuinely needs to subclass on an older stack. They mention that the right rule is “use final readonly by default for stateless services and value objects, drop readonly when the object has a legitimate mutable lifecycle, and drop final only when extension is part of the contract.”
What it reveals. Whether the candidate can update rules of thumb when the platform changes, and whether they understand the difference between stateless services, mutable domain objects, and framework integration points.
10. “How would you decide between Symfony Workflow and a status column?”
What a thin answer sounds like. “Workflow is always better, it visualises the state machine.” Or “status column, workflows are overkill”. A single-bullet preference.
What a strong answer sounds like. The candidate names the dimensions. Number of states (a boolean does not need a workflow). Number of transitions (a strict linear flow does not need one either). Existence of guards and side effects on transition (this is where Workflow earns its keep). Whether the business actually cares about the diagram (workflows produce a visualisation that non-engineers can read). They mention that the choice is reversible and that starting with a status column and migrating to Workflow when the rules get complex is a fine path; the opposite is usually unnecessary churn.
What it reveals. Whether the candidate can resist the urge to introduce architecture for its own sake. The “Workflow is always better” answer often correlates with codebases that have a state machine library for a flag with two states.
What you skip with these questions
You skip the things you can verify in five minutes after the interview by looking at their public code or running a paired exercise. You do not need to ask whether they know how to wire a service in YAML versus attributes; you can see that. You do not need to ask whether they can write a working route; you can see that too. The interview is for the things you cannot see by reading code: judgment, calibration, communication, response to ambiguity.
If the candidate passes the questions above and you still want a code signal, give them a small paired exercise on a real piece of code from your codebase (with sensitive parts redacted). Watch how they navigate an unfamiliar repo, where they look first, what they ask for. That is more useful than any abstract coding test.
How to score
We do not score answers right or wrong. We score them on three axes after each question:
- Did the candidate engage with the problem, or recite a memorised answer? Recitation is a red flag even when the recitation is correct.
- Did they hold uncertainty well? “I do not know, but I would check X” is a strong answer. “It is definitely Y” with no qualifier on a question where the right answer is “it depends” is a yellow flag.
- Did they ask back? Strong candidates ask clarifying questions because real engineering is mostly about scoping the problem. Candidates who plunge into an answer without asking are often answering the wrong question.
A candidate who gives strong, evidence-shaped answers across most of this set is usually much more interesting than one who gives trivia-perfect answers without judgment.
A note on what to drop
If you are tempted to add more questions, drop the trivia ones first. Trivia takes interview time away from the questions that actually produce signal. We have removed all “name this thing” questions from our process and the hiring decisions have become both faster and more confident. The candidates who would have done well on trivia still do well on these. The candidates who would have hidden behind trivia get filtered out earlier, which is what we wanted.
If you are hiring for a Symfony team and the current pipeline keeps producing engineers who interview well and ship poorly, that is a process problem, not a candidate-supply problem. We help engineering leaders rebuild their interview loop so it produces engineers who can actually work in their codebase. The first session is usually a teardown of the existing questions and a working set tuned to the kind of work the team actually does.
References
- Symfony Security: Authenticators: the framework documentation for the login flow referenced in question 2.
- Symfony Messenger: the messaging component referenced in question 4, including worker, retry, and failure transport behaviour.
- Symfony Workflow Component: the workflow component referenced in question 10, including guards and the marking store.
- Doctrine ORM: the ORM whose hydration and proxying constraints come up in questions 6 and 9.
