A good Salesforce developer builds automation that scales quietly for years. A weak one leaves behind triggers that fail at 201 records, integrations nobody understands and test classes that exist only to reach coverage. The difference rarely shows up on a CV. It shows up six months after go-live.

If you plan to hire Salesforce developers, this guide walks through the full decision: whether you actually need a developer, which engagement model fits, the skills that separate strong candidates, interview questions with what a good answer sounds like, a practical assessment and the red flags to watch for.

Do you need a Salesforce developer, admin or consultant?

Many teams advertise for a developer when their real need is configuration or process design. Getting this right saves money and attracts better candidates.

If you are still choosing an implementation partner rather than an individual, read how to choose the right Salesforce consultant first.

Which engagement model should you choose?

For more on flexible models, see why IT staff augmentation matters for tech projects.

What skills should a Salesforce developer have?

Platform fundamentals

• Apex with a clear understanding of governor limits: for example, 100 SOQL queries and 150 DML statements per synchronous transaction.
• SOQL and SOSL, including relationship queries, selective filters and query plans for large data volumes.
• Trigger design using a one-trigger-per-object pattern and a handler or framework, with bulk-safe logic and recursion control.
• Asynchronous Apex: when to use Queueable, Batch, Schedulable and future methods.
• Flow, and the judgement to know when Flow is the better tool than code.

User interface

• Lightning Web Components, including the component lifecycle, wire adapters versus imperative Apex calls, events and Lightning Data Service.
• Modern JavaScript and accessibility basics.

Integration

• REST and SOAP callouts, Named Credentials and External Credentials, and handling timeouts and retries.
• Inbound integration with the Salesforce REST, Bulk and Composite APIs.
• Event-driven patterns with Platform Events and Change Data Capture.

Security

• Sharing keywords (with sharing, without sharing, inherited sharing).
• Enforcing object and field permissions with WITH USER_MODE or Security.stripInaccessible.
• Avoiding SOQL injection and exposing only what an integration user needs.

Quality and delivery

• Meaningful Apex tests with assertions, test data factories and @TestSetup, not just coverage.
• Git, the Salesforce CLI and a structured deployment approach rather than change sets alone.
• Static code analysis and peer review habits.

Which certifications matter?

Platform Developer I is the recognised baseline for Salesforce developers, and Platform Developer II indicates deeper design capability. JavaScript Developer I is valuable for component-heavy work, and Platform App Builder shows declarative strength. Trailhead ranks and badges show curiosity and continuous learning. None of these replace a practical assessment, because certifications test knowledge, not delivery under real constraints.

12 interview questions and what a strong answer covers

1. "A trigger works in testing but fails when 500 records are loaded. Why?" Look for SOQL or DML inside loops, non-bulkified logic, and how to fix it with collections and maps.
2. "How do you prevent a trigger from running recursively?" Static variables or a framework-level control, and awareness of the downsides of blunt static flags.
3. "When would you use a before trigger versus an after trigger?" Before for validating or changing fields on the same record without extra DML; after for work needing record IDs or related records.
4. "Queueable versus future method: which and why?" Queueable supports complex types, chaining and job IDs for monitoring; future methods are simpler but limited.
5. "How would you process two million records nightly?" Batch Apex with a selective query, sensible scope size, stateful tracking only if needed and error handling.
6. "What does with sharing actually enforce?" Record-level sharing, not object or field permissions, and how to enforce those separately.
7. "How do you call an external API securely?" Named Credentials, no hard-coded secrets, timeouts, retries and logging.
8. "Explain a Mixed DML error and how you avoid it." Setup and non-setup objects in one transaction, solved with asynchronous processing or System.runAs in tests.
9. "What makes a good Apex test?" Its own test data, positive and negative cases, bulk scenarios, assertions and no reliance on SeeAllData=true.
10. "In LWC, when would you use @wire versus imperative Apex?" Wire for reactive, cacheable reads; imperative for user-triggered actions or DML.
11. "How do you deploy changes between sandboxes and production?" Source-driven development with Git, the Salesforce CLI or DevOps Center, validation deployments and running tests.
12. "Tell me about a time you pushed back on a requirement." Evidence of judgement, such as proposing Flow or a standard feature instead of custom code.

A practical assessment that actually predicts performance

Keep it short, realistic and paid if it takes more than two hours. A good exercise:

• Provide a small scratch org or sandbox with an Account and a custom Invoice object.
• Ask the candidate to write a bulk-safe trigger that rolls up unpaid invoice totals to the Account, with tests covering insert, update, delete and 200-record scenarios.
• Add a simple Lightning Web Component that displays the total and refreshes after an update.
• Review the code together and ask what they would change for ten million invoices.

The conversation about trade-offs is often more revealing than the code itself.

Red flags to watch for

• SOQL queries or DML statements inside loops
• Cannot explain governor limits or why they exist
• Test classes that only reach coverage without assertions
• Uses without sharing by default "to avoid access errors"
• Hard-coded record IDs, credentials or URLs
• No experience with version control or any deployment process beyond change sets
• Reaches for Apex for everything, or refuses to write code when it is clearly needed
• Cannot describe the business outcome of past work

Onboarding: the first 30 days

1. Week 1: access, a tour of the org, data model and integration map, coding standards and deployment process.
2. Week 2: fix small, low-risk backlog items with code review.
3. Week 3: own a small feature end to end, including tests and deployment.
4. Week 4: review technical debt they have noticed and agree priorities.

Documenting your org as part of onboarding pays off twice. It speeds up every future hire and supports the kind of review described in our Salesforce org health check checklist.

How much does it cost to hire a Salesforce developer?

Cost depends on seniority, location and engagement model. A permanent senior developer in the US or UK is a significant annual commitment before benefits and recruitment fees, while offshore or blended teams can deliver the same capacity at a fraction of the cost with the right governance. Our offshore development buyer’s guide and Salesforce cost guide cover rates and models in more detail.

Hire vetted Salesforce developers through Groviya

Groviya provides pre-vetted Salesforce developers, admins and architects through staff augmentation and dedicated teams, with delivery from India and support across UK and US time zones. Every engineer is assessed on the practical skills in this guide before they join your team. Explore our IT staffing services or tell us who you need.