Salesforce developer interview questions

What a Salesforce developer interview should reveal

The best salesforce developer interview questions reveal whether a candidate can build reliable business applications inside Salesforce’s execution, security, and data-model constraints. Knowing Apex syntax is useful; recognizing when not to write Apex, preventing a bulk import from failing, and protecting sensitive records are stronger hiring signals.

For MyDiscussions readers designing a hiring process, the goal is to evaluate platform judgment alongside implementation ability. A developer may deliver polished Lightning Web Components yet struggle with transaction boundaries. Another may know Service Cloud configuration deeply but need support with automated testing and Git-based delivery.

Start with the work the person will actually own. An internal CRM developer, an integration specialist, and a managed-package engineer need overlapping—but different—interview questions.

Define the role before selecting questions

Use the job’s production responsibilities to choose interview depth. Avoid turning every opening into an architect examination.

Ask candidates which Salesforce products and execution environments they have used. Experience with Sales Cloud does not automatically imply expertise in Salesforce Industries, Experience Cloud, or Agentforce.

Certifications can support screening, but they do not replace implementation evidence. Evaluate demonstrated capability, not credential count.

Apex and data-access interview questions

1. How would you make an Apex trigger safe for bulk operations?

Present a concrete case: an Opportunity trigger updates related Accounts when opportunities close. It works for one record but fails during a large import.

A strong answer should cover:

• Collecting relevant Account IDs from the trigger records.
• Querying related data in sets rather than inside loops.
• Building maps for efficient lookups.
• Performing collection-based DML.
• Handling multiple opportunities referencing the same account.
• Testing both single-record and bulk execution.

Probe beyond “no SOQL in loops.” Ask whether the calculation reflects all relevant opportunities or only those in the current trigger invocation.

Salesforce governor limits apply across the transaction, including other automation. Candidates should understand shared resource consumption, not merely memorize limits. The official Apex governor limits reference is appropriate documentation to allow during an exercise.

Weak signal: assuming a trigger always receives exactly one record or that bulkification eliminates all performance risks.

2. When would you choose a before trigger, an after trigger, or Flow?

A useful answer connects the choice to the required operation:

• Use a before trigger for efficient changes to fields on the triggering records.
• Use an after trigger when required system-populated values or related-record operations make that context appropriate.
• Consider record-triggered Flow for maintainable declarative automation when its capabilities fit the requirement.
• Use Apex when complexity, control, reuse, or scale justifies code.

Before-save Flow is also a strong option for straightforward same-record updates.

The important trade-off is not “Flow versus code” in isolation. It is ownership, transaction behavior, testability, and the interaction of all existing automation.

Ask how the candidate would inventory flows, triggers, validation rules, and other automation before introducing a change.

3. Why might a SOQL query become slow as an org grows?

Look for discussion of selectivity, indexes, data skew, filters, relationship traversal, and query shape.

A practical follow-up is: “This query is fast in a sandbox but times out against production-scale data. What do you inspect first?”

Strong candidates examine representative data volumes, use Salesforce’s Query Plan tooling, and question broad filters or leading-wildcard searches. They distinguish between returning fewer rows and finding those rows efficiently.

Do not demand an index recommendation without data distribution. A selective filter for one customer may be ineffective in another org.

4. How do you prevent automation recursion?

Reject blanket answers such as “use a static Boolean.”

A transaction-wide Boolean can suppress legitimate processing later in the transaction. Better answers start with whether relevant fields actually changed, whether the operation is idempotent, and how repeated execution should behave.

Static sets or other transaction-scoped tracking can help, but candidates should explain their scope and limitations. Ask how the design behaves when Flow and Apex update each other’s records.

Salesforce security interview questions

5. Does with sharing enforce all Salesforce permissions?

The correct answer is no. with sharing addresses record-level sharing; it does not automatically enforce object permissions or field-level security.

A strong candidate separates:

• Record access.
• Object-level permissions.
• Field-level permissions.
• Apex class access and the execution entry point.

Ask how they would secure an Apex method called by an LWC. Relevant approaches include user-mode database operations, Security.stripInaccessible(), and explicit checks where appropriate.

The trade-off matters: should inaccessible fields cause the operation to fail, or should the application remove them and continue with a clear user experience? Salesforce’s official Secure Apex Classes guidance provides a useful evaluation baseline.

6. How would you investigate a suspected data exposure?

Use a scenario: a support agent can view a sensitive field through a custom component but not through the standard record page.

A good investigation checks the component’s data-access path, Apex execution context, field-level security enforcement, and returned payload. Hiding a field in JavaScript is not authorization.

Senior candidates should also consider immediate containment, audit evidence, affected users, and regression tests. Avoid rewarding a purely theoretical security answer that never addresses incident handling.

Lightning Web Components interview questions

7. When should an LWC use Lightning Data Service instead of Apex?

For supported record operations, Lightning Data Service and UI API-based adapters reduce custom server code and handle sharing, object permissions, and field-level security.

Apex remains useful for complex business operations, specialized queries, and transaction logic that standard adapters do not cover.

Ask candidates to explain:

• Reactive reads with wire adapters.
• Imperative calls for user-driven operations.
• Loading, empty, and error states.
• Cache behavior and refreshing stale data.
• Why client-side validation does not replace server-side enforcement.

Strong signal: choosing the simplest supported data-access mechanism rather than routing every interaction through a custom Apex controller.

8. How would you design a reusable, accessible record-search component?

Look for a clear public API, custom events, debouncing where appropriate, and separation between presentation and data access.

The candidate should discuss keyboard navigation, labels, focus handling, and understandable error feedback. Salesforce Lightning Design System patterns and base Lightning components are useful starting points.

For testing, ask what belongs in Jest tests versus Apex tests or browser-level checks. Jest can validate component behavior with mocked dependencies, but it does not prove production permissions or end-to-end server behavior.

A useful follow-up concerns stale responses: what happens when an earlier search completes after a later search?

Integration and asynchronous Apex questions

9. How would you integrate Salesforce with an order-management system?

Give constraints: order creation must be reliable, the external API can become unavailable, and users need a visible status.

Strong answers address:

• Synchronous versus asynchronous user experience.
• Named Credentials and External Credentials for endpoint and authentication configuration.
• Queueable Apex, Platform Events, Change Data Capture, or middleware where appropriate.
• Idempotency keys and duplicate handling.
• Retry classification, backoff, and manual recovery.
• Correlation IDs and operational monitoring.

MuleSoft may suit broader orchestration and governance needs, but introduces cost and operational ownership. A direct integration can be simpler for a narrow workflow, provided failure handling is explicit.

Red flag: promising exactly-once business processing without explaining how duplicates are detected and neutralized.

10. When would you use Queueable Apex rather than Batch Apex?

Queueable Apex fits bounded asynchronous work, supports richer job state than future methods, and enables job chaining within platform constraints.

Batch Apex fits work that must be divided into scopes across separate transactions, such as processing large record populations. Candidates should understand that each scope can fail independently and that successful earlier scopes are not automatically rolled back.

Ask why moving code asynchronously does not make governor limits disappear. It changes execution boundaries and some limits; it does not remove resource constraints.

For event-driven designs, follow up on consumer recovery and replay strategy rather than assuming asynchronous delivery means guaranteed completion.

Testing, debugging, and delivery questions

11. What makes an Apex test valuable beyond code coverage?

Salesforce generally requires at least 75% aggregate Apex coverage for production deployment, and triggers require some coverage; deployment test settings can impose additional requirements. That threshold is a release gate, not a quality target.

Strong tests assert business outcomes and cover:

• Bulk input.
• Invalid or missing data.
• Relevant permission boundaries.
• Failure paths and duplicate requests.
• Asynchronous behavior using Test.startTest() and Test.stopTest().
• Callouts through appropriate mocks.

Candidates should prefer isolated test data over reliance on existing org records. Ask what System.runAs() actually tests: treating it as automatic enforcement of all object and field permissions is a warning sign.

12. How would you release a Salesforce change safely?

Look for a reproducible path from source control to production:

• Git-based review.
• Salesforce CLI validation and automated tests.
• Appropriate scratch orgs or sandboxes.
• Static analysis with Salesforce Code Analyzer.
• Dependency and permission checks.
• Deployment sequencing.
• Post-release verification and recovery planning.

GitHub Actions, Azure DevOps, Gearset, and Copado are relevant options; tool familiarity matters less than understanding the controls they provide.

Salesforce recovery is not always a simple code rollback. Data mutations, destructive metadata changes, and integration side effects may require separate remediation. The official Salesforce CLI command reference helps validate proposed deployment workflows.

A step-by-step Salesforce developer assessment

Step 1: Map responsibilities to evidence

Choose four or five competencies tied to the job. Define observable success criteria before interviewing, including which weaknesses require coaching and which are unacceptable.

Step 2: Use a structured technical discussion

Ask the same core questions across candidates for the same role. Allow clarifying questions and documentation access. Score reasoning separately from terminology recall.

Step 3: Run a bounded practical exercise

Provide an Apex trigger and handler containing SOQL inside a loop, duplicate updates, and a missing field-permission check in a companion controller.

Ask candidates to identify risks, fix one path, and outline tests. Supply business requirements, permission expectations, and a working environment rather than requiring account setup during the interview.

Step 4: Change one requirement

Introduce partial integration failure or a bulk import. Observe whether the candidate adapts the design thoughtfully instead of layering on ad hoc exceptions.

Step 5: Score independently before discussing

Use a shared rubric:

Require interviewers to record concrete observations, not impressions such as “seemed senior.”

Common hiring mistakes to avoid

• Overweighting trivia: memorized limits do not establish sound transaction design.
• Treating Apex as the default: unnecessary code adds maintenance and security obligations.
• Ignoring org complexity: automation interactions often matter more than an isolated algorithm.
• Accepting coverage as proof: tests need meaningful assertions and failure cases.
• Testing unrelated products: do not require deep Commerce Cloud expertise for an internal Service Cloud role without justification.
• Using unpaid production work: practical tasks should be synthetic, bounded, and consistently scored.

For related role-specific evaluation frameworks, browse more Interview questions topics.

Frequently asked questions

Which Salesforce developer interview questions should juniors answer?

Focus on collections, basic SOQL, bulk-safe trigger structure, simple LWC behavior, and meaningful Apex assertions. Junior candidates should recognize their knowledge limits and use documentation effectively. Do not require independent ownership of enterprise integration architecture.

How can interviewers distinguish mid-level and senior Salesforce developers?

Mid-level developers should implement bounded features safely. Senior developers should also identify cross-team dependencies, challenge unsuitable requirements, anticipate operational failures, and explain migration or recovery strategies. Increase scenario complexity rather than asking more obscure syntax questions.

Should Salesforce interviews include live coding?

Yes, when coding reflects the job and candidates receive a usable environment. Debugging or refactoring existing Apex often produces better evidence than writing boilerplate from memory. Offer consistent time limits and assess correctness, reasoning, and tests rather than typing speed.

How should Agentforce experience affect Salesforce developer hiring?

Evaluate it when the role actually involves agents. Ask about grounding, action permissions, evaluation datasets, auditability, and human escalation. Agentforce familiarity should complement—not replace—Apex, data security, integration reliability, and release discipline. Keep product-specific requirements aligned with the organization’s actual implementation plans.