Hire Salesforce developers

Salesforce development happens inside a platform with hard limits and three release cycles a year, and hiring for it means finding someone who designs within those constraints.

What Salesforce actually is

Salesforce is a hosted customer relationship and application platform. Beyond the sales and service products it is a development environment in its own right, with a proprietary language, its own data model, a declarative automation layer and a large ecosystem of installable applications. A great deal of enterprise business logic lives inside it.

The defining technical characteristic is governor limits. Because the platform is multi-tenant, Salesforce enforces hard limits on what any piece of code may consume: the number of database queries, the number of records processed, the amount of processing time. Exceed one and the transaction is terminated. These are not guidelines; they are enforced, and designing around them is most of what makes Salesforce development different from ordinary application development.

The second defining fact is that Salesforce releases three times a year and you cannot opt out. Changes arrive on the platform's schedule and customisations must keep working across them. This creates a continuous maintenance obligation that organisations frequently do not budget for, and it means Salesforce estates decay quietly when nobody owns them.

The part that separates seniors from mid-levels

Bulkification is the first concept and it is non-negotiable. Code must handle many records in one transaction, which means never issuing a query or an update inside a loop. A trigger written for one record works perfectly in testing and fails the moment somebody imports a thousand rows. This is the single most common Salesforce defect and the first thing to test for in an interview.

The second area is the balance between declarative configuration and code. Much of what Salesforce does can be built through point-and-click automation rather than written, and the platform's guidance favours that where possible. Good developers know where the line sits: declarative tools for straightforward automation that administrators should own, code where the logic is complex, needs testing, or would hit limits. Estates where everything is code are expensive; estates where complex logic is spread across many overlapping declarative rules are worse.

The third is that the platform imposes a testing requirement. Code cannot be deployed to production without a minimum level of test coverage, which is unusual and has a predictable consequence: some organisations write tests that assert nothing in order to satisfy the requirement. A developer who writes meaningful assertions, and who tests bulk behaviour specifically, is doing something the platform requires and many do not.

Where Salesforce is used

The label “Salesforce developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Sales and service operations

The core products, extended with custom objects, automation and integrations.

Custom business applications

Applications built on the platform because the organisation is already there and the data lives in it.

Systems integration

Connecting Salesforce to enterprise resource planning, billing, marketing and data warehouses, which is where much of the complexity sits.

Customer portals

External-facing communities and portals built on the platform.

Managed packages

Applications built for distribution on the marketplace, a distinct discipline with its own constraints.

Data migration and consolidation

Moving into Salesforce or consolidating several instances after a merger.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Support status of the tools in this stack

Salesforce releases three times a year on a fixed schedule that customers cannot opt out of, so keeping customisations working across releases is a permanent obligation rather than an occasional project.

Salesforce itself is not versioned as a single product, so the useful equivalent is the support status of the tools a Salesforce developer works with daily. The table is read from public release data rather than written by hand, so it states what is supported now. It is worth having in front of you during an interview: asking which of these a candidate has upgraded, and what broke, gets you further than asking how many years they have used each.

Source: endoflife.date public release data, read 2026-09-25. A tool with no published end-of-life dates sets its support boundary by ecosystem practice rather than by policy.

The practical use of this is in judging an estate rather than a person. A team running several of these past their support dates is usually not behind by accident; it is behind because upgrades were never anyone's job. That is worth knowing before you hire, because it tells you whether the first six months will be building new things or paying down what was deferred.

The toolchain around it

Nobody hires for Salesforce alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Apex

The platform's proprietary language, syntactically similar to Java and constrained by governor limits.

SOQL and SOSL

The query languages. Query count is a governed resource rather than merely a performance concern.

Lightning Web Components

The modern front-end framework, based on web standards.

Flow

Declarative automation, now the primary point-and-click tool and increasingly capable.

Salesforce DX with version control

Source-driven development. Its absence is a strong signal about how an estate is run.

Sandboxes

Development and testing environments, with refresh cycles that need planning.

Platform events and the API layer

Integration mechanisms, including asynchronous patterns that avoid limits.

A deployment pipeline

Automated deployment with tests, rather than change sets moved by hand.

Related skills that frequently appear on the same specification: Java, .NET, JavaScript, SQL, AWS.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Governor limits and bulkification

The defining constraint. Anyone who has shipped Salesforce code has hit them.

• Strong answer: Never queries or updates inside a loop, designs for bulk from the start, and can describe a limit exception they diagnosed.
• Warning sign: Writes single-record logic, which will fail on the first data import.

Declarative versus code

Determines whether an estate is maintainable and who can own it.

• Strong answer: Has a clear position, uses Flow for straightforward automation and code where logic is complex, and can explain the boundary.
• Warning sign: Codes everything, or has complex business logic spread across many overlapping Flows.

Testing practice

The platform mandates coverage, which produces meaningless tests where nobody cares.

• Strong answer: Writes meaningful assertions, tests bulk scenarios and negative cases, and treats the coverage requirement as a floor.
• Warning sign: Writes tests that create records and assert nothing to satisfy the deployment gate.

Release management

Change sets moved by hand are a sign of an estate nobody has modernised.

• Strong answer: Uses source-driven development with version control and automated deployment.
• Warning sign: Deploys with change sets and has no version control.

Integration patterns

Where most Salesforce complexity and most limit problems live.

• Strong answer: Uses asynchronous patterns and platform events appropriately, and handles failure and reconciliation.
• Warning sign: Makes synchronous callouts from triggers, which is a reliable way to hit limits and cause failures.

Handling three releases a year

A continuous obligation that organisations under-budget.

• Strong answer: Tests against preview sandboxes, tracks deprecations, and treats it as planned work.
• Warning sign: Discovers platform changes when something breaks.

Technical debt in an inherited org

Most Salesforce work is on estates with years of accumulated customisation.

• Strong answer: Audits what exists, finds unused and conflicting automation, and can prioritise remediation.
• Warning sign: Adds new automation without examining what already runs on the same object.

Warning signs in a Salesforce codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Queries or updates inside loops

• What you see: A SOQL query or a database operation within a for loop.
• What it costs: Governor limit exceptions as soon as record volume rises, terminating the transaction and usually a business process with it.
• The fix: Query once, work with collections, and perform a single bulk operation. This is the foundational Salesforce discipline.

Tests that assert nothing

• What you see: Test methods creating records purely to satisfy the coverage requirement.
• What it costs: The deployment gate passes while nothing is actually verified, which is worse than no tests because it looks like protection.
• The fix: Assert real outcomes, including bulk and negative cases. Treat the coverage minimum as a floor rather than a target.

Overlapping automation on one object

• What you see: Triggers, Flows and older process automation all acting on the same object.
• What it costs: Unpredictable execution order, recursive updates and behaviour nobody can trace.
• The fix: Consolidate. One trigger per object delegating to handler classes, with Flow used deliberately rather than accumulated.

Synchronous callouts from triggers

• What you see: External web service calls made during a record save.
• What it costs: Slow transactions, limit exceptions, and record saves failing because a third-party system was unavailable.
• The fix: Use asynchronous patterns so external systems cannot block a business process.

Change sets and no version control

• What you see: Deployments assembled by hand through the interface.
• What it costs: No history, no review, no reproducibility, and no reliable way back.
• The fix: Adopt source-driven development with version control and an automated pipeline.

Hardcoded identifiers

• What you see: Record identifiers written into code.
• What it costs: Code that works in one environment and fails in another, discovered during deployment.
• The fix: Use custom metadata or custom settings so values are configuration rather than code.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Salesforce developer.

Junior

Configures and builds simple automation. Needs review on anything that will process records in bulk.

Mid-level

Writes Apex and components correctly with bulk handling and meaningful tests. Understands where declarative tools are the better answer.

Senior

Owns solution architecture, the declarative and code boundary, integration patterns and release management. Can audit and remediate an inherited estate.

Staff

Owns the platform's role in the enterprise architecture, governance across teams, the integration estate, and the case for what should not be built in Salesforce at all.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Custom application on the platform

• Usual team: One to two developers plus an administrator.
• What governs it: Data model design is the critical early work, as with any platform.

Integration build

• Usual team: One developer plus the other system's owner.
• What governs it: Where most complexity lives. Asynchronous patterns and reconciliation are the substance.

Technical debt remediation

• Usual team: One senior developer.
• What governs it: Auditing overlapping automation on inherited estates. Frequently finds a great deal that is unused or conflicting.

Release management modernisation

• Usual team: One developer with pipeline experience.
• What governs it: Moving from change sets to source-driven deployment. High value and commonly deferred.

Data migration or org consolidation

• Usual team: Two developers plus data owners.
• What governs it: Common after mergers. The data model reconciliation is the project, not the movement.

Migration work you may actually be hiring for

A large share of Salesforce work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

Change sets to source-driven development

• Why teams do it: Version control, review, reproducible deployment and a route back when something fails.
• What to watch: Retrieving an existing org into source is the first task and usually reveals customisation nobody documented. Expect that to take longer than setting up the pipeline.

Older process automation to Flow

• Why teams do it: Salesforce has retired the older declarative tools, so this is a platform requirement rather than a preference.
• What to watch: Migrate one object at a time and consolidate rather than translating each rule directly. Objects with several overlapping automations are the opportunity to simplify.

Synchronous integrations to asynchronous patterns

• Why teams do it: External systems should not be able to fail a record save or consume a transaction's limits.
• What to watch: Reconciliation becomes your responsibility once calls are asynchronous. Build the retry and failure visibility before switching, not after.

Ungoverned customisation to an audited estate

• Why teams do it: Overlapping automation produces behaviour nobody can predict or trace.
• What to watch: Inventory what runs on each object before changing anything. A good deal of what you find will be unused, and confirming that safely is most of the work.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Salesforce developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Whether the work is configuration, development, or both, since administrators and developers are different hires.
• What automation already exists on the main objects, because inherited estates carry years of it.
• Whether the org uses source-driven development or change sets.
• Which integrations exist, since this is where most complexity concentrates.
• Who owns testing against the three annual platform releases.
• Whether the work is new development or remediation of accumulated debt.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Salesforce work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Salesforce developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Salesforce developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Salesforce frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Administrator experience presented as development. Configuration and Apex development are different skills. Both are valuable and they are not interchangeable.

No bulk thinking. The defining constraint. Ask directly about processing a thousand records, because this failure is guaranteed to surface.

Inherited estates with years of debt. Establish what automation already exists before hiring, since remediation is a different brief from new development.

Under-budgeted platform maintenance. Three releases a year is a continuous obligation. Confirm who owns it, because frequently nobody does.

Hiring Salesforce developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Salesforce developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Do we need a Salesforce developer or an administrator?

An administrator for configuration, automation through declarative tools, user management and reporting, which covers a great deal. A developer when logic is complex enough to need code, when integrations are involved, or when you are building custom applications on the platform. Many organisations need both, and hiring a developer for work an administrator should own is an expensive way to get less maintainable results.

What are governor limits and why do they matter so much?

Hard limits the platform enforces on what any transaction can consume: queries, records processed, processing time. Exceed one and the transaction is terminated. Because the platform is multi-tenant, these are enforced rather than advisory, and designing around them shapes how all Salesforce code is written. Code that ignores them works in testing and fails on the first real data volume.

Should we build it in Salesforce or elsewhere?

In Salesforce when the data already lives there and the functionality is genuinely about your customer or sales processes. Elsewhere when the workload is computationally heavy, needs data structures the platform handles poorly, or would fight governor limits continuously. Building a general-purpose application on Salesforce because the licences exist is a common and expensive decision.

How do we handle three releases a year?

Treat it as planned recurring work. Salesforce provides preview sandboxes ahead of each release so you can test customisations against what is coming. Organisations that use them handle releases routinely; those that do not find out when something breaks. The obligation is unavoidable and the surprise is optional.

Why is our Salesforce org so slow and fragile?

Usually accumulated overlapping automation: triggers, Flows and older process builders all acting on the same objects in an order nobody controls, often with recursive updates. Estates that grew over years without governance reach this state predictably. An audit typically finds a great deal that is unused, duplicated or conflicting.

Is the coverage requirement a good thing?

In intent, yes, since it forces some testing onto a platform where it might otherwise be skipped. In practice it produces tests that create records and assert nothing wherever nobody cares about quality, which satisfies the gate and verifies nothing. The requirement is a floor. Whether it is useful depends entirely on whether the tests assert real outcomes.

What does a well-run Salesforce estate look like?

Source-driven development with everything in version control, automated deployment with tests rather than change sets moved by hand, one trigger per object, deliberate use of declarative automation, and someone who owns the three annual releases. That description excludes a large share of the estates we see, which is why remediation is such a common engagement.

Are Salesforce developers expensive?

Yes, comparably to other specialised enterprise platforms, because the skills are platform-specific and demand from large organisations is steady. The experience does not transfer readily in either direction, which keeps the pool distinct. Certifications are common and, as elsewhere, tell you about familiarity rather than judgement.