How to Hire a Salesforce Developer in 2026: Apex, Flow, and the CRM Skills That Matter

Salesforce is the world’s most widely deployed CRM platform, used by over 150,000 companies across sales, service, marketing, and commerce. For any company running Salesforce as a core business system, the developer who customizes it holds unusual leverage: bad decisions made inside the platform accumulate as tech debt that you can’t migrate away from without significant cost. There is no “rewrite in a different CRM” exit that costs less than the years it would take.

Hiring a good Salesforce developer is different from hiring a general software engineer. The platform has its own language (Apex), its own front-end framework (Lightning Web Components), its own automation tooling (Flow), its own data model conventions, and its own unique runtime constraints (governor limits). Someone who is an excellent Java developer with no Salesforce experience will spend the first six months learning the platform’s constraints before becoming productive.

Three specializations that share a title

Apex developer writes server-side code in Salesforce’s Java-like language. Apex runs inside Salesforce’s execution model, which means it operates under governor limits, in a managed runtime, and with access to SOQL (Salesforce Object Query Language) for interacting with Salesforce data. Apex developers write triggers, batch jobs, scheduled jobs, Visualforce controllers, REST/SOAP web services, and custom platform event handlers. This is the closest Salesforce gets to traditional back-end engineering.

Lightning Web Components (LWC) developer builds custom UI that runs inside Salesforce. LWC is Salesforce’s modern web component framework, built on the W3C Web Components standard with some Salesforce-specific extensions. An LWC developer writes JavaScript, HTML, and CSS in a component model similar to React or Angular. They can build custom record pages, home page components, and embedded apps that surface Salesforce data in ways the standard UI can’t provide.

Declarative developer / Salesforce admin with automation depth uses Salesforce’s configuration tools: Flow Builder for process automation, validation rules and formula fields for data quality, approval processes for workflows, and custom objects and page layouts for data modeling. The line between “developer” and “advanced admin” blurs here — the best declarative Salesforce professionals can build surprisingly complex automation without writing a line of code. But they hit walls when the logic requires iterative processing, complex error handling, or callouts to external systems.

Most Salesforce developers work across all three layers, but depth varies. Know which layer is your primary need.

The governor limits question

Governor limits are Salesforce’s enforcement mechanism for its multi-tenant architecture. Every piece of Apex code runs in a transaction, and every transaction has hard limits. Hitting them causes exceptions that surface to end users.

Ask: “What are the governor limits that matter most for Apex triggers, and how do you write triggers to stay inside them?”

A developer who has worked with production Apex data volumes will immediately name:

• SOQL limit: 150 queries per transaction. A trigger that queries inside a for loop will hit this quickly in bulk operations.
• DML limit: 100 DML statements per transaction.
• CPU time limit: 10,000ms for synchronous, 60,000ms for async transactions.
• Heap size: 6MB synchronous, 12MB asynchronous.

More importantly, they will explain the pattern for handling them: bulkify everything. A trigger should never run a SOQL query inside a loop. Instead: collect all the IDs from Trigger.new into a set, run one SOQL query with WHERE Id IN :idSet, load results into a map, then iterate. This pattern is the foundation of governor-safe Apex.

A candidate who says “I haven’t run into governor limits” has not written Apex at production data volumes. That’s either an inexperienced candidate or one who has only worked on small implementations.

The trigger architecture debate

Ask: “How do you structure Apex triggers, and what’s your opinion on trigger frameworks?”

Salesforce allows multiple triggers per object, which creates a coordination problem: if three different developers each write a trigger on the Account object, the order of execution is unpredictable and interactions between them can cause bugs that are hard to diagnose.

The standard answer in serious Salesforce development is the “one trigger per object” pattern: each object has exactly one trigger file, and that trigger dispatches to a handler class. Handler logic is organized by event type (beforeInsert, afterUpdate, etc.) in a class that can be unit tested without firing the trigger.

Many teams use a framework (FFLIB, Trigger Framework by Kevin O’Hara, or a custom one) to standardize this. A candidate with strong opinions about framework choice — and who can explain why their preference is appropriate for your team size and customization complexity — has worked in enterprise Salesforce environments, not just simple implementations.

SOQL and data modeling

Salesforce uses SOQL (Salesforce Object Query Language) instead of SQL. It looks similar but has important differences: no JOINs (relationships are traversed through dot notation or subqueries), governor limits on how many rows you can return, and some data model concepts that don’t exist in traditional SQL (polymorphic lookups, formula fields, roll-up summary fields).

Ask a candidate to write a SOQL query to find all Opportunities in “Closed Won” stage for Accounts in a specific industry, where the Opportunity Amount is greater than $100,000, sorted by CloseDate descending. Then ask them to add a WHERE clause that filters by a parent Account field (one level up in a lookup relationship).

A competent SOQL writer handles the relationship traversal: Account.Industry in the WHERE clause for a lookup field. They also know about selective queries (SOQL limits to 50,000 rows by default, and certain query filters are “selective” in ways that affect index use).

Integrations

A significant portion of Salesforce work involves integrating Salesforce with external systems: sending order data to an ERP, syncing customer records with a marketing platform, receiving webhook events from payment processors. Ask about integration architecture.

Ask: “How would you integrate Salesforce with an external ERP to sync order status? What would you use, what would happen if the ERP is down, and how would you handle errors?”

A strong answer covers several options: REST callouts from Apex (direct sync), Platform Events for event-driven async processing, Salesforce Connect for virtual object access to external data, or a middleware like MuleSoft. It also addresses failure handling: what happens when the callout times out (42 seconds is the maximum callout timeout)? How do you implement retry logic for failed async processes? Where does the error go and who is alerted?

An answer that stops at “I’d do a REST callout” has not thought about what happens when things fail, which is when integration architecture actually matters.

Testing in Apex

Salesforce requires a minimum of 75% test coverage before code can be deployed to production. That sounds good. In practice, many teams write tests that manufacture fake code coverage without testing anything real.

Ask a candidate to describe their testing approach for a trigger that creates a Task record for every new Opportunity. Then ask: “How would you test that the Task is created with the correct subject, due date, and assigned user?”

A developer who writes real tests creates a test Opportunity with @isTest setup data, inserts it, then queries for Tasks created for that Opportunity and asserts that task.Subject == 'Follow up on ...', that the due date is correct, and that the assigned user is who the logic expects. A developer who writes poor tests creates the Opportunity, inserts it, and then asserts System.assert(true) because all they care about is the coverage percentage.

When to hire vs. when to use a Salesforce partner

For bounded projects (a new Sales Cloud implementation, one integration to build, a data migration), a Salesforce consulting partner often makes more economic sense than a full-time hire. Partners have deep bench depth, can staff different specializations, and scale down when the project ends.

For companies with ongoing customization needs — regular new features, continuous automation improvement, active integration maintenance — a full-time developer or small in-house team makes more sense. The breakeven is roughly when you’re generating more than one sprint’s worth of Salesforce work per month continuously.

Either way, the quality of the initial build determines the ongoing maintenance cost. See our guide on how to hire a vetted software developer for general principles that apply here too.

Rates in 2026

Mid-level Salesforce developers in the US (Apex, LWC, solid admin skills) run $100,000–$140,000. Senior developers with enterprise integration experience, CPQ depth, or Service Cloud/Experience Cloud specializations run $150,000–$210,000. Contract Salesforce developers bill $100–$175/hr at the senior end. Offshore developers from India with verified certifications and demonstrated production experience (not just Trailhead badges) run $25,000–$60,000 annually. Certifications are necessary but not sufficient — screen with real technical problems, not cert lists.