“CMS expert” is one of those job titles that describes two quite different people. One knows a product: the admin screens, the plugin ecosystem, how to get a site live. The other knows how to model content so the site still makes sense after three years of editors using it. Both are valuable. Hiring the first when you needed the second is expensive, and the cost does not appear for about eighteen months.
The distinction, made concrete
Suppose you sell training courses. A configurer will build a Course page type with fields for title, description, price, date, city and instructor. It works, it launches, everyone is pleased.
A modeller asks what happens when the same course runs in four cities on six dates with three instructors. Because in the first design, that is 24 near-identical pages, all competing with each other in search, each needing its description updated by hand when the syllabus changes, and none of them able to answer “which courses are running in Pune next month”.
The modeller separates Course from Session, links them, and generates the listings. Same CMS, same effort in week one, an entirely different situation in year two.
That is the skill you are usually hiring for, and it is not on anybody’s CV under that name.
What the role really covers
- Content modelling. What the types are, what relates to what, what is reused and what is duplicated.
- The editing experience. Field ordering, help text, sensible defaults, and validation that prevents an editor breaking a page at 6pm on a Friday.
- Permissions and workflow. Who drafts, who approves, who publishes, and what happens when the approver is on leave.
- Migration. Bringing existing content in with its URLs, its relationships and its media intact. This is frequently the largest part of the job and the part least often discussed at interview.
- Extending the platform without forking it, so updates remain possible.
- Performance and caching, because content sites are read-heavy and this is where they fall over.
- Governance: what happens to content nobody has touched in three years.
Questions that separate the two
Skip the platform trivia. Anyone can look up a hook name; the point is to hear how someone thinks about structure.
- “Here is a real content problem from our business. How would you model it?” Use the course example or your own. Listen for whether they ask what changes over time, who edits it and how it is found. The questions matter more than the answer.
- “How do you handle the same content appearing in three places?” Copy-paste, a reusable block, or a reference. All three are legitimate and the reasoning is what you are assessing.
- “Tell me about a migration that went wrong.” Anyone who has done several has one. Listen for URLs, redirects and media, which is where migrations actually hurt.
- “What would you refuse to build in the CMS?” A strong answer exists: complex application behaviour, anything transactional, anything that belongs in a separate service. Someone who thinks the CMS should do everything will build you a slow, fragile everything.
- “How do you keep a site upgradable?” Custom code in the right places, patches managed rather than applied by hand, no core modifications.
- “What do you do when an editor asks for a field that should not exist?” This is a communication question wearing technical clothes, and it predicts a great deal about the next two years.
Do you need an expert, a developer or an architect
Three different hires, and the mismatch is the most common hiring mistake in this area.
A CMS developer builds what has been specified: templates, components, integrations. Right when the model already exists and the work is delivery.
A CMS expert owns the platform: the model, the editorial experience, the upgrade path, the migration. Right for a site that will be edited by many people for years.
An architect decides whether you should be on this CMS at all, how it fits with the other systems, and whether the front end should be decoupled. This is a decision, not a role, and it usually needs days rather than months.
Many teams advertise for the third and hire the first, then wonder why the structural problems persist.
Contract, employee or agency
The honest split. A single site build with a defined end is contract or agency work; hiring permanently for it means finding something for that person to do in month five. A platform serving several brands, edited daily, with a roadmap, justifies a permanent hire, and the continuity is worth more than the flexibility. A migration is the strongest case for bringing in someone who has done a dozen: it is intense, finite, and unforgiving of learning on the job.
Whichever route, insist on one thing: the model gets written down. A diagram of the content types and their relationships, kept current. It is an hour of work and it is the difference between a successor understanding the system in a day and reverse-engineering it for a month.
A practical exercise instead of a technical test
Coding tests are a poor filter for this role, because the job is judgement rather than syntax. A better exercise takes an hour and predicts far more.
Give the candidate a genuine, messy content problem from your business, with the awkward parts left in: the exception that breaks the pattern, the two things that are nearly the same but not quite, the legacy set of pages that does not fit. Ask for a model, drawn however they like, and a walkthrough.
What you are watching for: do they ask who edits this and how often; do they ask what happens when it changes; do they notice the exception and say what they would do about it; can they explain the model to a non-technical person in the room. Someone who produces a tidy diagram without asking a question has told you a great deal.
What to give them in the first month
The commonest way a good hire underperforms in this role is being handed a backlog of field requests. That is configuration work and it buries the person you hired for structure.
A first month that pays for itself: an inventory of the existing content types and how many entries each actually has; a list of the types nobody uses; the editorial pain points, gathered by sitting with the people who publish; and one written recommendation with the trade-offs stated. Everything after that is better informed, including the backlog.
The signs you hired the wrong one
They show up gradually and they are recognisable, which means they can be caught in the first quarter rather than the second year.
- New content types appear every month. A model that grows a type for each new page is not a model, it is a folder structure. Ask why the existing types could not carry it.
- Editors ask developers to publish things. If the CMS needs a developer to add a page, the editorial layer has failed and the site will silently stop being updated.
- The same paragraph exists in nine places. Somebody will be asked to change it and will find seven of the nine.
- Nobody can update the platform. Custom code in the wrong places is how a CMS becomes frozen at the version it launched on, and that is a security position rather than a technical preference.
- Every request is answered with a plugin. Each one is a dependency, an update path and a potential vulnerability. Sometimes it is the right answer; always is not.
None of these is a reason to replace a person. All of them are a reason to have the structural conversation early, while the model is still small enough to change.
We staff CMS and platform roles on our own client work, which is the same pool we place from: our PHP and CMS engineers and the wider roles we place. If you are unsure which of the three hires above you actually need, describe the content problem and we will tell you.