Sylius developer documentation: what to ask a candidate
The official Sylius developer documentation is one of the best hiring tools available, because it shows which methods a competent developer should know: architecture layers, Symfony customization, plugins and the API. Use its public pages to prepare interview questions, even if you are not technical. A strong candidate can explain why the documentation recommends a method and what happens at upgrade time, rather than merely reciting features.
A word on my position: I am a freelance Sylius developer, so I can be one of the options you consider instead of hiring. This article is meant to be useful whichever route you take, and it was checked against the documentation on 1 November 2026.
What the official documentation covers, and how to access it
The documentation home splits its path into evaluating, installing and building. Public pages include when and why to choose Sylius, the architecture and the release cycle. It marks The Book as requiring a login, and in November 2026 the customization pages redirected me to a sign-in step when I opened them directly. Create an account if you plan to prepare seriously, and do not assume that a page's absence from search results means the topic is undocumented.
The home page also mentions Sylius Academy video courses, and experimental AI tools such as a documentation MCP server, which gives assistants access to the documentation. A candidate who uses such tools should still be able to explain the result without them.
Architecture questions: test their mental model
Start with an open question: "How would you explain the difference between a Sylius component, a bundle and the core?" The architecture page gives the reference answer. Components are standalone packages, bundles integrate them with Symfony, and the core ties them together, for example by making a product variant taxable. Someone who has really worked with Sylius will soon give examples of where they extended each layer.
Follow with: "Your store needs a business rule that changes the price calculation. Where do you put it, and how do you test it?" There is no single answer to memorise. You are listening for a developer who locates the existing service, extends it cleanly and mentions automated tests. Vague replies such as "I would modify the code" deserve one more question.
Symfony and customization questions
Ask: "How do you change a shop template in Sylius 2?" According to the customization guide, Twig hooks are the recommended approach, using priorities in YAML configuration, and overriding templates is discouraged, especially in plugins. Then ask what happens to an overridden template during an upgrade. The right response mentions comparing it with the new original.
Next: "How do you add a field to an existing form?" The forms guide recommends extensions rather than overriding whole forms. A good candidate may also mention how the data is stored, validated and displayed, showing they think about the entire flow.
| Topic | Interview question | Good sign in the answer |
|---|---|---|
| Architecture | Component, bundle, core: what is the difference? | Clear definitions and a real example |
| Templates | How do you change a shop template in Sylius 2? | Twig hooks, and why overrides cost more later |
| Payments | How would you add a payment provider? | Payment Request, Symfony Messenger, testing failures |
| API | How do you limit what the API exposes? | Shop and admin contexts, removal of unused endpoints |
| Plugins | How do you choose a plugin? | Maintenance, version support, exit plan |
| Versions | How would you plan an upgrade from 1.14? | Inventory, official guide, tests, rollback |
Plugin and API questions
Plugins reveal judgment. Ask: "A client wants a feature that exists on the Addons marketplace. What do you check before installing it?" Look for the maintainer, compatible versions, code quality, and what would happen if the plugin were abandoned. Then ask how they would add a payment provider. The payment gateway guide describes the Sylius 2 Payment Request system, which handles actions through Symfony Messenger, and the Sylius 2.3 release says this API is no longer experimental.
For the API, ask how it is organised. The architecture page explains that it is built on API Platform, with separate shop and admin contexts, and the API customization guide covers removing or renaming endpoints through YAML. Ask too about security: which endpoints are public, and how are permissions tested? On a store, an unnecessary endpoint is an unnecessary risk.
The upgrade question reveals the most
I would finish with a real case: "Our store runs Sylius 1.14. What do you do first?" The facts are public. Security support ends on 31 December 2026, version 2.3 requires PHP 8.3, and there is an official upgrade guide. Listen for an inventory of plugins and customizations, then a plan with tests and a way back. Be wary of a fixed promise before anyone has seen the code. Also check whether they follow security releases, such as those of October 2026.
Ask candidates to separate what they have delivered from what they have only read. Honest answers like "I have not done that migration myself, but here is how I would approach it" are more reassuring than confident generalities, including when you are talking to a freelancer like me.
When this interview is not what you need
If your store is standard and you simply need updates, a long technical interview is excessive: ask for a maintenance plan and references. If your problem is urgent, such as an inherited store with no documentation, you may first need an audit rather than a hire. And if you need a full team with several specialists, a partner agency from the official directory may suit you better than any individual recruit.
A simple next step is to pick four questions from the table and write down what a good answer would mean for your own store. If you would like help preparing them, or would rather compare hiring with a freelance assignment, you can reach me through my Sylius developer page. I reply within 24 working hours, and you talk to the person who writes the code.