"Salesforce developer" is the most ambiguous job title in enterprise software. Behind those two words sit at least four distinct jobs: the admin who configures, the developer who writes Apex, the consultant who translates, and the architect who designs the whole landscape. A generalist recruiter runs the phrase through a CV database, gets hundreds of keyword matches, and delivers a shortlist drawn from all four, usually weighted towards admins, because admins are by far the most numerous.

I run Salesforce searches for hiring managers who've already been burnt by exactly that. This guide is the checklist I work through before a single CV goes out: which of the four jobs the role actually is, and how to test for depth once you know.

TL;DR: The Salesforce economy is projected to add 11.6 million jobs between 2022 and 2028, yet only 0.8% of developers report working extensively in Apex (Stack Overflow Developer Survey 2024). Decide first whether you need an admin, a developer, a consultant, or an architect. Then screen for governor limits, clicks-versus-code judgment, and Lightning Web Components, and treat certifications as a floor: they prove study, and the interview has to prove the rest.

Why the title stretched to cover everyone near the platform

Because the platform is everywhere, the label followed it. Salesforce was ranked the number one CRM provider by IDC for the 13th consecutive year, holding 20.0% of the worldwide CRM market in 2025 (IDC's 2026 ranking). When one vendor holds a fifth of a market that size, almost every enterprise career brushes against it somewhere.

The scale keeps compounding. An IDC study estimates the Salesforce economy, powered by AI, will create a net gain of 11.6 million jobs and 2.02 trillion dollars in business revenues between 2022 and 2028. Millions of people can now truthfully write "Salesforce" on a CV: report builders, Flow admins, functional consultants, integration engineers, solution architects. The word tells you someone works near the platform. It tells you nothing about whether they've ever shipped a line of production Apex, and a keyword search can't tell the difference either.

Admin, developer, consultant, architect: the four jobs on one title

Salesforce itself splits the work into four careers, and the split matters more than any CV keyword. Per Trailhead's career paths:

• Admin configures, automates, and optimises Salesforce with the platform's declarative tools.
• Developer writes custom code in Apex and builds user interfaces with Lightning Web Components.
• Consultant bridges customer challenges and business goals.
• Architect maps how systems, data, and AI agents work together across the estate.

The classic mis-hire follows from ignoring that taxonomy. A consultant with eight years of Salesforce on the CV, who has gathered requirements and configured orgs but never shipped production Apex, gets sold as a developer because the keyword matches. Six weeks in, the integration work stalls and everyone wonders why. Nobody did anything wrong except the person who wrote the search string.

Each role has a proper home. If the work is automation and configuration within standard objects, you want an admin. If it's custom logic at scale, integrations, and bespoke UI, you want a developer. If it's shaping requirements across stakeholders, a consultant. If it's the data model and the wider estate across multiple clouds, an architect. Getting this sentence right before the search starts is most of the battle, and it's the foundation of any serious software engineering screen.

The scarcity math nobody runs

Only 0.8% of respondents in the Stack Overflow Developer Survey 2024 reported working extensively in Apex. Set that against the IDC projection above and you have an ecosystem adding jobs by the millions, drawing on a language that less than one developer in a hundred actually writes.

What does that do to a search? It kills post-and-pray. A job ad for a genuine Apex developer mostly harvests the admins and consultants described above, because they're the bulk of the keyword pool. The people you want are a thin layer inside a huge crowd, and most of them are employed, delivering, and not reading job boards. You have to go to them, and you have to verify the work rather than the word. It's the same divergence between label and skill I wrote about in hiring Go developers and hiring iOS developers, amplified by a far bigger crowd wearing the label.

Where the real ones actually are: inside implementation partners and in-house Centres of Excellence, active in the Trailblazer Community and local user groups, and one referral away from developers already trusted with a production org. Ecosystem events and partner alumni networks out-produce job boards on this search every time. That's sourcing work, and it's precisely the work a keyword search skips.

I've seen this ratio in practice. A Salesforce search I closed in 2024 placed a developer into a multinational's Salesforce Centre of Excellence, working Service Cloud and Experience Cloud customisations. The longlist looked generous. The subset who had genuinely built and shipped Apex against real governor limits was a small fraction of it, and the final shortlist came out of carefully screening that fraction.

What genuine Salesforce engineering depth looks like

Three areas separate a production Salesforce engineer from a keyword match, and you can probe all three in conversation without a line of code on a whiteboard.

Governor limits and bulkification

This is my favourite screening territory because the platform makes it unfakeable. Apex runs on shared, multi-tenant infrastructure, so it strictly enforces per-transaction limits to stop runaway code monopolising resources, and exceeding one throws an exception your code cannot catch or handle. A concrete example from Salesforce's Apex documentation: a synchronous transaction gets a maximum of 100 SOQL queries. Bulkification, meaning code designed to process records in bulk rather than one at a time, is the official guidance for living within those limits.

Ask the candidate what happens when a trigger fires during a 200-record data load and the logic queries the database inside a loop. A genuine developer immediately talks about limit exceptions, moving queries out of loops, collecting records into maps keyed by ID, and processing the whole batch in a handful of statements. Someone who has only read about Apex describes the happy path and never mentions limits at all.

Clicks-versus-code judgment

Salesforce engineering has a discipline most stacks lack: the platform expects you to evaluate declarative, native features before writing code, and the ecosystem's own debate about clicks versus code has run for years on SalesforceBen. A developer who reaches for Apex by default is fighting the platform.

So ask a candidate to describe something they refused to build in Apex because Flow could do it. The strong answer comes with a real example and a reason: maintainability, admin ownership, upgrade safety. The equally strong answer knows the other failure mode, because sprawling, undocumented Flows generate technical debt just as surely as bad code does. What you're testing is judgment about where each tool belongs, and that judgment only comes from having lived with the consequences.

Lightning Web Components, not Aura

Salesforce officially recommends Lightning Web Components for all new development, and the LWC developer guide documents Aura as the legacy framework. A CV that's heavy on Aura components with no recent LWC work is telling you when that person's front-end experience effectively stopped.

Ask what they've built in LWC in the last year and how they'd approach migrating an old Aura component. You're listening for familiarity with modern web standards, since LWC is built on them, and for a considered migration view; a shrug is its own answer.

Two questions that date a Salesforce CV instantly

You can separate current practitioners from people coasting on old org experience in about five minutes, with two recent platform shifts.

First: "How would you migrate our Process Builders to Flow?" Workflow Rules and Process Builder reached end of support on December 31, 2025, per Salesforce's end-of-support notice. Existing automations keep running, but they're unsupported, and Flow is the go-forward automation tool. Most mature orgs are carrying unsupported automation right now, which makes this question pure due diligence: whoever you hire will almost certainly inherit some of it. A current developer has a migration opinion, knows the assessment tooling exists, and asks about your org's automation inventory. A dated one hasn't noticed the deadline passed.

Second: "What have you done, or what are you watching, with Agentforce?" Agentforce, Salesforce's autonomous AI agent layer, went GA in October 2024, and by the quarter ended January 2026 it had reached roughly 800 million dollars in annual recurring revenue, up 169% year over year (Salesforce's Q4 FY26 results). Agent-adjacent skills are entering briefs faster than the market can supply them, so the pool that genuinely has them is even thinner than the Apex pool. Nobody expects an Agentforce veteran; they barely exist yet. What the question checks is whether the candidate tracks the platform they claim to specialise in.

Certifications: what they prove and what they don't

Certifications prove structured study and commitment to the ecosystem. They don't prove production judgment. Salesforce offers more than 40 of them, catalogued in SalesforceBen's certification guide, and according to Mason Frank's hiring guide, 82% of Salesforce professionals hold at least one and report an average 18% salary increase after certifying.

Read those two numbers together and the recruiter's conclusion falls out. Certifying is economically rational for every single candidate, so nearly everyone does it, and a signal nearly everyone carries can't differentiate anyone. Treat certs as a floor. For the developer track specifically, Platform Developer I is the baseline and Platform Developer II is the meaningful step up. But in my experience, a PD I holder with two years of production war stories about limit exceptions beats a five-cert candidate who has never deployed to a live org. The interview decides; the certificates confirm.

How to screen a Salesforce developer before you hire

A good Salesforce brief starts before the job spec. This is the sequence I use:

1. Name which of the four jobs it is. Write one sentence using Trailhead's own taxonomy: admin, developer, consultant, or architect. If you can't, the search isn't ready, and any shortlist you receive will be noise.
2. Ask honestly whether you need a developer at all. If the requirement fits standard objects and automation, sometimes the answer is an admin plus Flow, not an Apex developer. A recruiter who never tells you that is selling, and this honesty is a large part of the case for boutique vs volume recruitment.
3. Put governor limits in the first technical screen. The trigger-on-a-bulk-load scenario takes ten minutes and separates production developers from keyword matches more reliably than anything else I've found.
4. Ask the two freshness questions. Process Builder migration and Agentforce awareness. Together they tell you whether the CV describes the platform as it exists in 2026 or as it existed in 2021.
5. Weight shipped evidence over certification count. Ask what they built, what broke, and what they'd do differently. The candidates worth hiring answer that question with visible relief.

Common questions about hiring Salesforce developers

What's the difference between a Salesforce admin and a Salesforce developer?

Admins work declaratively: per Trailhead's definitions, they configure, automate, and optimise the platform using tools like Flow, without writing code. Developers write custom Apex and build UIs with Lightning Web Components. They're different jobs, and treating the titles as interchangeable is the single most common Salesforce mis-hire I see.

Do Salesforce certifications matter when hiring a developer?

As a floor, yes; as a differentiator, barely. With 82% of Salesforce professionals holding at least one certification per Mason Frank's survey, certs mostly confirm that a candidate studied. Look for Platform Developer I and II on the developer track, then spend your interview time on production evidence: governor limits, deployments, things that went wrong.

Can a Java or C# developer switch to Apex?

Yes, and the syntax transition is quick, since Apex is deliberately Java-like. The hard part is the platform: governor limits, bulkification, and the discipline of evaluating declarative options before writing code at all. A strong object-oriented engineer picks up the language in weeks; the judgment about when to put the keyboard down takes a few production cycles.

Do I actually need a Salesforce developer, or an admin?

Start from Salesforce's own declarative-first guidance: if standard objects and Flow can meet the requirement, an admin may be the better and faster hire. You need a developer when the work involves integrations, complex logic at scale, or custom user interfaces in Lightning Web Components. If you're unsure, describe the problem to someone technical before writing the title into a job spec.

---

If you're hiring for a Salesforce role and want to know which of the four jobs you're actually briefing, tell me about the role. I'll give you a plain read on whether you need an admin, a developer, or an architect, and then a shortlist screened on what candidates have actually shipped. I run two to four active searches at a time, deliberately. Three CVs that fit beats thirty that don't.