Salesforce Developer Interview Questions and Answers

What interviewers are testing: Whether you understand the developer boundary across Apex, LWC, automation, data access, integrations, testing, and release ownership—not whether you can list Salesforce products.

A Salesforce developer builds and maintains custom behavior on the platform—Apex, triggers, LWC, integrations, and the declarative/programmatic boundary—not only clicking through setup.

Typical ownership:

Not the same as Data Engineer: Pipeline/SQL/Data Cloud depth lives in the data engineer interview guide.

A strong answer is:

A Salesforce developer builds and maintains custom behavior on the platform—Apex, triggers, LWC, integrations, and the declarative/programmatic boundary—not only clicking through setup.

Indian SI vs product company: Services firms may weight declarative/admin knowledge more; product teams often go 70%+ code (Apex, LWC, integration).

A strong answer is:

"I expect platform fundamentals first, then Apex and trigger design, LWC, integrations and security, and usually a live or scenario exercise. Senior loops add architecture, production incidents, release decisions, and stakeholder trade-offs."

Hands-on: use a Developer Edition or scratch org; complete relevant Trailhead trails, but prioritize writing code over badge count.

Cross-skill: Java interview basics help with Apex OOP; Git for Salesforce DX workflows.

A strong answer is:

"I spend the first two weeks on SOQL, limits, and bulk Apex, then add async processing, LWC, integrations, security, and mocks. I prioritize coding in an org over collecting Trailhead badges."

What interviewers are testing: Whether you choose Flow or code from maintainability, transaction complexity, expected volume, testability, and ownership rather than personal preference.

2026 default: Record-triggered Flow for maintainable automation; Apex when CPU, bulk, callouts, or test complexity demand code.

A strong answer is:

"I prefer Flow for straightforward, admin-maintainable automation. I choose Apex when volume, CPU, transaction control, complex reusable logic, or integration requirements make programmatic control safer and easier to test."

What interviewers are testing: whether you demonstrate solid command of production judgment—the trap is textbook recall without production context.

Seniors are judged on production judgment, not syntax alone:

• Bulk-safe design before the first deploy
• Trigger framework and recursion control
• Security: understand API-version-dependent Apex access modes, explicit WITH USER_MODE / WITH SYSTEM_MODE, sharing boundaries, and stripInaccessible() where graceful degradation is needed
• Async selection with operational ownership
• LWC performance (wire vs imperative, list virtualization)
• Integration contracts and credential hygiene
• Agentforce / invocable Apex awareness in 2026
• Mentoring, code review, release discipline

A strong answer is:

"Senior Salesforce developers are expected to defend architecture choices: bulk behavior, automation ownership, security boundaries, async design, integration failure handling, testing, and release safety—not merely write valid Apex."

What interviewers are testing: Whether you can connect governor limits to concrete design choices such as bulk queries, collection-based DML, bounded CPU work, and transaction boundaries.

Governor limits cap per-transaction resource use on the multitenant platform so one org cannot starve others.

Key concept: Governor limits apply to an execution transaction. Trigger work performed during the original save shares that transaction's limits; asynchronously started Queueable or Batch executions run in separate transactions with their own applicable limits.

A strong answer is:

Governor limits enforce fair multitenant usage. I design bulk collections, one query per object per transaction, and async when sync limits are insufficient.

What interviewers are testing: whether you define lookup, master-detail, and self-relationship. and connect it to Lookup in production—not textbook definitions only.

SOQL impact: Child-to-parent uses dot notation (Contact.Account.Name). Parent-to-child uses subquery (SELECT Id, (SELECT Id FROM Contacts) FROM Account)—subquery rows count toward query limits.

A strong answer is:

Lookup is optional with independent sharing; master-detail is tightly coupled with rollup support. I pick based on lifecycle, sharing, and whether native rollups are required.

What interviewers are testing: whether you define the Salesforce release model and connect it to three major releases per year in production—not textbook definitions only.

Salesforce ships three major releases per year (Spring, Summer, Winter). Sandboxes preview releases weeks before production.

Developer implications:

• Regression-test triggers, Flows, and LWC in preview sandboxes
• Watch release notes for governor limit, API, and security changes
• Deprecations (Workflow Rules, Process Builder → Flow) affect migration planning

A strong answer is:

Three seasonal releases; I validate custom code in preview sandboxes and read release notes for breaking changes before production cutover.

What interviewers are testing: Whether you understand enough of the save lifecycle to predict when Flow and Apex run, diagnose recursion/double updates, and assign one automation owner to each responsibility.

At a high level:

1. Initial system validation
2. Before-save record-triggered Flows
3. Before Apex triggers
4. Custom validation and duplicate processing
5. Record write to the database
6. After Apex triggers
7. Assignment/auto-response rules and any applicable legacy workflow automation
8. After-save record-triggered Flows and later actions

Salesforce documents before-save flows as running immediately before Apex before triggers. The full sequence has additional steps, so for production debugging I consult Salesforce's current Order of Execution reference rather than memorizing every intermediate rule type.

Why seniors care: Duplicate automation (Flow + trigger) causes recursion, double updates, and CPU timeouts.

Pattern: One trigger per object → handler class; consolidate Flow vs Apex ownership per object/event.

A strong answer is:

Validation and before-save flows precede before triggers; after triggers precede after-save flows. I avoid duplicate automation paths that recurse or fight over the same fields, and I verify the exact sequence against current Salesforce docs when debugging production saves.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

In API 67.0+, an Apex class with no sharing declaration defaults to enforcing sharing. Salesforce still recommends explicitly declaring the intended sharing model for maintainability across API versions. Database operations also default to user mode, which enforces the running user's object permissions, FLS, and record-level access. Triggers remain system-mode entry points, so security-sensitive trigger logic should be delegated to classes where access mode and sharing behavior are explicit.

A strong answer is:

"OWD establishes baseline record access; role hierarchy and sharing mechanisms open access from there. In current Apex I make sharing and database access mode explicit, and I remember triggers still run in system mode."

What interviewers are testing: whether you show collection-based DML and SOQL—not SOQL or DML inside a loop.

Bulkification means writing triggers and Apex to handle up to 200 records per transaction without per-record SOQL/DML.

// WRONG: SOQL in loop — fails at scale
for (Opportunity o : Trigger.new) {
    Account a = [SELECT Industry FROM Account WHERE Id = :o.AccountId];
    if (a.Industry == 'Technology') o.Description = 'Tech deal';
}

// RIGHT: query once, map, loop
Set<Id> accountIds = new Set<Id>();
for (Opportunity o : Trigger.new) accountIds.add(o.AccountId);
Map<Id, Account> accountsById = new Map<Id, Account>(
    [SELECT Id, Industry FROM Account WHERE Id IN :accountIds]
);
for (Opportunity o : Trigger.new) {
    Account a = accountsById.get(o.AccountId);
    if (a != null && a.Industry == 'Technology') o.Description = 'Tech deal';
}

The bulk pattern mirrors standard collection processing—you query once, build a map, then iterate.

A strong answer is:

Bulkification collects ids, runs one query and one DML batch per object where possible, and never puts SOQL or DML inside a loop over trigger records.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

Undelete: after undelete for recovery workflows.

Handler pattern:

trigger OpportunityTrigger on Opportunity (before insert, before update, after update) {
    OpportunityTriggerHandler.handle(Trigger.operationType, Trigger.new, Trigger.oldMap);
}

A strong answer is:

Before triggers for same-record validation and defaults; after triggers for related updates and async work. I keep one trigger per object delegating to a handler class.

What interviewers are testing: Whether you prevent recursive work without accidentally suppressing legitimate records or later trigger invocations in the same transaction.

Common techniques:

A single static Boolean is easy to demonstrate but is often too coarse for production recursion control.

Interview trap: A Flow updates a field that re-fires the trigger—fix ownership, not only a flag.

A strong answer is:

I use a handler framework with re-entry guards, metadata bypass for loads, and eliminate duplicate Flow/trigger paths that cause recursion.

What interviewers are testing: whether you define an Apex interface and why use one and connect it to without implementation in production—not textbook definitions only.

Interfaces declare methods without implementation—classes promise to implement them.

Common examples:

• Database.Batchable<SObject> for batch jobs
• Queueable for async jobs
• Schedulable for cron-style runs
• Custom interfaces for strategy pattern / test doubles

A strong answer is:

Interfaces define contracts—platform interfaces like Batchable or custom seams for swappable implementations and cleaner tests.

What interviewers are testing: whether you define required to deploy Apex to production and connect it to compiles in production—not textbook definitions only.

Production deployment gates:

1. Successful validation under the selected deployment test level
2. ≥ 75% aggregate Apex code coverage
3. Every trigger must have some test coverage
4. All Apex compiles

Senior point: Coverage is not quality—write bulk tests with edge cases, not empty Test.startTest stubs.

A strong answer is:

Production needs 75% coverage, passing tests, and compiled code. I write meaningful bulk tests—not coverage-padding no-ops.

What interviewers are testing: Whether you evaluate Flow vs Apex from expected record volume, complexity, ownership, callout/transaction boundaries, observability, and testing—not from a blanket "declarative first" rule.

Clarify requirements:

• How many objects touched per save?
• Need synchronous callout?
• Expected volume (bulk)?
• Who maintains after launch?

A strong answer is:

I start with Flow when rules are simple and admin-maintainable. I move to a bulkified Apex handler when CPU, recursion, callouts, or complex tests demand code.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

// Queueable: async callout after DML
public class SyncJob implements Queueable, Database.AllowsCallouts {
    public void execute(QueueableContext ctx) { /* callout */ }
}

Rule: DML then callout in same sync transaction fails—use @future, Queueable, or callout from batch with AllowsCallouts.

A strong answer is:

Queueable for smaller async work and callout chains; Batch for large data volumes; Schedulable to kick off jobs on a schedule.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

A strong answer is:

Queueable is generally preferred for new asynchronous Apex because it provides richer payloads, job IDs, chaining, and newer controls. @future remains available for simpler existing use cases.

What interviewers are testing: whether you walk through a structured approach to update 2 million contact records nightly—design approach.—naming checks before fixes.

1. Batch Apex implementing Database.Batchable<Contact>
2. Selective query on indexed fields (LastModifiedDate, status flag)
3. Stateful only if aggregating across chunks (watch heap)
4. Schedulable wrapper for nightly cron
5. Governor-safe execute: choose an appropriate batch scope; 200 is a common starting point, not a requirement; no SOQL in loop
6. Error handling: partial success logging, email on failure
7. Use a narrow, auditable automation bypass only when the data-maintenance process explicitly requires it; do not disable validation/business logic indiscriminately

A strong answer is:

Nightly Batch with selective SOQL, bulk execute logic, schedulable entry point, error logging, and optional trigger bypass for controlled data fixes.

What interviewers are testing: Whether you recognize the uncommitted-work transaction boundary and can redesign integration work asynchronously without losing retry/idempotency guarantees.

Platform rule: callout after DML in the same sync transaction throws CalloutException unless using proper async separation.

Fix patterns:

• Queueable with Database.AllowsCallouts enqueued after DML
• @future(callout=true) (legacy)
• Batch with callouts in execute (mind limits)

A strong answer is:

"I avoid holding uncommitted Salesforce work while making an external call. If the workflow requires DML first, I separate the callout into an asynchronous transaction such as Queueable and design retry/idempotency around the external operation."

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

A strong answer is:

SOQL for structured filters on known objects; SOSL for cross-object search using the search index—not leading-wildcard SOQL hacks.

What interviewers are testing: Whether you think about production data volume and query plans instead of assuming every indexed field automatically makes a SOQL query selective.

On large objects, non-selective queries fail or time out.

Selective filters:

• Indexed fields: Id, Name, external IDs, audit fields, custom indexed fields
• Selectivity depends on index type, object cardinality, filter operators, and optimizer statistics. Instead of memorizing one percentage threshold, use the Query Plan and verify that filters can use a selective index at production volume

Avoid: leading % wildcards, !=, NOT, non-deterministic formula filters at scale.

Tool: Query Plan in Developer Console.

A strong answer is:

Filter on indexed fields returning a small row fraction. I check the Query Plan when a query works in sandbox but fails in production volume.

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

// UNSAFE
String q = 'SELECT Id FROM Account WHERE Name = \'' + userInput + '\'';

// SAFE: bind variable
String name = userInput;
List<Account> rows = Database.query(
    'SELECT Id FROM Account WHERE Name = :name'
);

For dynamic field names: whitelist via Schema.describe—never trust raw user strings.

A strong answer is:

Bind variables first; escape only when binding is impossible; whitelist dynamic field/object names from Schema describe.

What interviewers are testing: Whether you understand the current Apex user/system-mode model and how class sharing declarations interact with database access mode.

In API 67.0+, Apex database operations default to user mode, enforcing the running user's object permissions, FLS, and record-level access. WITH USER_MODE can still make that intent explicit. WITH SYSTEM_MODE deliberately elevates the database operation. Class with sharing / without sharing remains important for the broader class execution and sharing context.

Related tools:

• WITH USER_MODE / explicit user-mode database operations
• Security.stripInaccessible() — removes inaccessible fields when graceful degradation is desired
• Explicit system mode only when justified

WITH SECURITY_ENFORCED has been retired for API 67.0 code and does not compile in API 67+.

A strong answer is:

"In API 67+, database operations default to user mode for object permissions, FLS, and record access. I still state access mode explicitly in security-sensitive code, use stripInaccessible() when graceful degradation is required, and opt into system mode only for a deliberate privileged operation."

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

Answer: Build new with LWC; use Aura only for unsupported interop or legacy wrap.

A strong answer is:

LWC is the default for new development. I maintain Aura where needed but migrate or wrap with LWC when possible.

What interviewers are testing: Whether you distinguish reactive wired Apex from explicitly invoked Apex and understand the caching/refresh behavior rather than equating @wire with Lightning Data Service.

Refresh strategy depends on the data source—for example refreshApex() for wired Apex data and LDS notification APIs when records changed outside LDS.

import { wire } from 'lwc';
import getOpps from '@salesforce/apex/OpportunityController.getOpen';

@wire(getOpps, { accountId: '$recordId' })
wiredOpps;

A strong answer is:

"I use @wire for reactive reads from cacheable=true Apex methods. I use imperative calls when execution must be explicit, including mutations; imperative reads can also call cacheable Apex methods."

What interviewers are testing: whether you define Lightning Data Service (LDS) and connect it to UI API wire adapters in production—not textbook definitions only.

LDS provides UI API wire adapters (getRecord, updateRecord, etc.) for CRUD on records without custom Apex when needs are simple.

Benefits: automatic cache sharing across components, built-in FLS/CRUD respect.

Use Apex when: multi-object joins, complex logic, callouts, or bulk server processing.

A strong answer is:

LDS handles simple record CRUD with caching and security. I add Apex when queries or business logic exceed what LDS adapters support.

What interviewers are testing: Whether you treat an LWC-accessible Apex method as a server-side security boundary and enforce class access, record sharing, object/field permissions, and input validation there.

1. Expose only required methods with @AuraEnabled; ensure users have Apex class access
2. Make the class sharing model explicit even though API 67 entry-point behavior is safer by default
3. Use explicit user-mode database operations where user permissions must apply; opt into system mode only intentionally
4. Use stripInaccessible() where graceful field filtering is desired
5. Validate all untrusted client input server-side

Authenticated and guest users can invoke an @AuraEnabled method only when their profile or permission set grants access to the Apex class.

A strong answer is:

AuraEnabled methods with explicit sharing and access mode, stripInaccessible where needed, and server-side validation—client controls are UX only, not security.

What interviewers are testing: whether you walk through a structured approach to lwc list feels slow with thousands of rows.—naming checks before fixes.

Tactics:

• Paginate or virtualize—do not render 5,000 DOM rows
• Use @wire with narrow field lists
• Server-side filters; selective SOQL
• Avoid @track on deep objects unnecessarily (modern reactivity is finer-grained)
• Lazy load details on row expand
• Check for N+1 imperative calls per row

A strong answer is:

Paginate or virtualize large lists, minimize fields, filter server-side, and eliminate per-row Apex calls—same spirit as bulkification on the server.

What interviewers are testing: Whether you separate endpoint/authentication configuration from Apex business logic and design callouts around transaction, retry, timeout, and credential boundaries.

Pattern:

1. Named Credential defines the callout endpoint and references an External Credential for authentication
2. HttpRequest / Http class in Apex
3. Parse JSON with JSON.deserialize
4. Run async if DML is involved in same business transaction

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_Named_Credential/resources');
req.setMethod('GET');
HttpResponse res = new Http().send(req);

Never hard-code credentials, tokens, or secrets in Apex or source control. Use Named Credentials and External Credentials for endpoint authentication; use Custom Metadata for non-secret configuration.

A strong answer is:

Named Credentials for endpoints and External Credentials for auth, Http classes for callouts, async when DML and callouts mix, and no hard-coded secrets in Apex.

What interviewers are testing: whether you demonstrate solid command of REST / Bulk / Composite APIs—the trap is textbook recall without production context.

Data engineers often consume the same CRM objects via API or CDC—see data engineer guide for pipeline angle.

A strong answer is:

External systems use REST/Bulk APIs with OAuth, or subscribe to CDC and Platform Events for push models—I design idempotent upserts and respect API limits.

What interviewers are testing: whether you know when to reach for this and the failure modes when you pick the wrong approach.

Named Credentials define the callout endpoint and reference authentication configuration. External Credentials model the authentication protocol, principals, and user mappings. Together they keep endpoint and auth details out of Apex and source code.

A strong answer is:

Named Credentials plus External Credentials hide secrets and simplify callout code—I avoid credentials in Apex source or Git history.

What interviewers are testing: Whether you understand current user-mode database operations and know when to fail on inaccessible data versus strip inaccessible fields gracefully.

Options:

• User-mode SOQL/DML (the API 67+ default—enforces CRUD, FLS, and record-level access; make it explicit when clarity matters)
• WITH USER_MODE / database user-mode APIs
• Security.stripInaccessible(AccessType.READABLE, records) when inaccessible fields should be removed gracefully
• Explicit WITH SYSTEM_MODE / system-mode DML only for deliberate privileged operations

A strong answer is:

I enforce FLS in queries and DML via user-mode operations and stripInaccessible—not only UI hiding fields.

What interviewers are testing: Whether you distinguish class sharing context from database access mode and understand that user-mode operations enforce CRUD, FLS, and record access together.

Only for narrow system processes—batch cleanup, integration user jobs, controlled admin utilities—with:

• Separate service classes (not entire app)
• Audit logging
• Input validation
• Documented business approval

Classes now enforce sharing by default in API 67+, but Salesforce still recommends making the sharing declaration explicit for maintainability across API versions. Use without sharing only when bypassing record sharing is an intentional, reviewed requirement. without sharing establishes a system sharing context for the class, but an explicitly user-mode query or DML operation still enforces the user's CRUD, FLS, and record access. Conversely, explicit system-mode database access can elevate that operation. Treat class sharing and database access mode as related security controls whose interaction must be intentional.

A strong answer is:

without sharing only for isolated system jobs with audits and tight scope—never as the default for user-driven features.

What interviewers are testing: whether you define Custom Metadata Types and connect it to metadata records in production—not textbook definitions only.

Developer-defined metadata records deployed with the app—config without hard-coding.

Uses: field mappings, strategy/configuration switches, integration mappings, and deployable environment configuration.

Unlike Custom Settings, metadata is deployable and version-friendly in DX pipelines.

A strong answer is:

Custom Metadata stores configurable app behavior in version-controlled metadata—ideal for mappings and feature toggles across environments.

What interviewers are testing: whether you demonstrate solid command of master-detail—the trap is textbook recall without production context.

Native roll-up summary fields require master-detail. For lookup relationships:

• Flow rollups (record-triggered)
• Apex trigger aggregation
• Third-party rollup tools

Trade-off: trigger/Flow must stay bulk-safe.

A strong answer is:

Native rollups need master-detail; for lookup I use bulkified Apex or Flow—and watch governor limits on high-volume parents.

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

@IsTest
static void bulkUpdate_setsDescriptionForTechAccounts() {
  // insert 200 opps + accounts
  Test.startTest();
  update opps;
  Test.stopTest();
  System.assertEquals(200, [SELECT COUNT() FROM Opportunity WHERE Description = 'Tech deal']);
}

A strong answer is:

I test bulk behavior, async boundaries, and assertions—not empty tests that only chase 75% coverage.

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

Use Jest with Salesforce's LWC testing utilities for component unit tests (@salesforce/sfdx-lwc-jest):

• Mock @salesforce/apex imports
• Test user interactions and conditional rendering
• Complement with Selenium/Playwright for critical E2E flows

A strong answer is:

Jest unit tests with mocked Apex for component logic; selective E2E for critical user journeys.

What interviewers are testing: Whether you design agent-callable actions as secure, deterministic application contracts rather than exposing arbitrary Apex methods to an AI layer.

Developers expose trusted actions Agentforce can invoke:

A strong answer is:

I build invocable, bulk-safe, well-tested actions with clear inputs/outputs and secure data access—agents are only as good as the platform code behind them.

What interviewers are testing: whether you give a structured narrative with decisions and trade-offs—not a bullet list without context.

STAR example angles:

• SOQL-in-loop trigger taking down Monday imports
• CPU timeout from recursive Flow + trigger
• Callout-after-DML failure in integration

Structure: impact → root cause → bulk/async fix → regression test → monitoring.

A strong answer is:

I describe the limit error, traced it to per-record SOQL, refactored to maps and bulk queries, added a 200-row test, and watched limit dashboards after deploy.

What interviewers are testing: Whether you resolve a Flow-vs-Apex disagreement using requirements, ownership, expected scale, risk, and evidence rather than seniority or tool preference.

1. Clarify maintenance owner and change frequency
2. Estimate volume and limit risk
3. Prototype both if cheap
4. Document decision in ADR or team wiki
5. Choose the simplest maintainable implementation that meets the expected volume, complexity, ownership, and observability requirements; establish measurable thresholds that would justify revisiting the design

A strong answer is:

I decide on maintainability, volume, and limit risk—not preference—I make trade-offs visible and pick Flow when admins can safely own it.

What interviewers are testing: Whether your motivation connects naturally to platform development, customer/business impact, continuous learning, and the type of engineering work the role actually involves rather than certification or salary alone.

Connect to:

• Platform scale and continuous releases
• Mix of declarative + code problem solving
• Customer impact on sales/service workflows
• Ecosystem demand for LWC + integration skills

Tie to Trust (security, data handling) if interviewing at Salesforce.

A strong answer is:

I enjoy shipping business-critical features on a managed platform where good design—bulk Apex, secure LWC, solid tests—directly protects customer data and uptime.

What interviewers are testing: Whether you treat certifications as evidence of baseline platform knowledge while recognizing that coding, debugging, architecture judgment, and production experience are stronger engineering signals.

Certs (Platform Developer, JS Developer, Architect paths) signal baseline knowledge but do not replace hands-on org experience.

Interviewers still ask you to read code, design triggers, and explain limits.

A strong answer is:

Certs help show foundation; I pair them with real projects where I deployed bulk-safe code and integrations—not badge collecting alone.

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

A strong answer is:

Debug logs for production-like issues; Replay Debugger locally—I always check the limit usage section of the log.