Salesforce Developer Interview Questions and Answers

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.

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

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.

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

Seniors are judged on production judgment, not syntax alone:

• Bulk-safe design before the first deploy
• Trigger framework and recursion control
• Security: with sharing, FLS, WITH USER_MODE / stripInaccessible
• 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

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

Key concept: Limits reset per transaction. One user action may span trigger → queueable → batch—each gets fresh 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.

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.

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.

High-level save path (simplified):

1. Before-save record-triggered Flows (fast field updates)
2. Before triggers
3. System validation rules
4. Record save to database
5. After-save Flows
6. After triggers
7. Assignment rules, rollups, workflows (legacy), etc.

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:

Before-save Flows and before triggers run first; after-save Flows and after triggers follow persistence. I avoid duplicate automation paths that recurse or fight over the same fields.

Apex: with sharing respects sharing; without sharing ignores it (use sparingly for system processes).

A strong answer is:

OWD sets the floor; roles and sharing rules grant additional access. In Apex I use with sharing unless a narrow system process requires otherwise—and document why.

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.

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.

Common techniques:

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.

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.

Production deployment gates:

1. All Apex compiles
2. ≥ 75% org-wide test coverage
3. All tests pass
4. Each trigger has ≥ 1% coverage

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.

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.

// 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.

A strong answer is:

Queueable supports chaining, better monitoring, and richer payloads—@future is legacy except for very simple fire-and-forget tasks.

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: process 200 rows per chunk; no SOQL in loop
6. Error handling: partial success logging, email on failure
7. Bypass triggers during migration if needed (metadata flag)

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.

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:

Salesforce forbids callouts after uncommitted DML in the same transaction. I enqueue Queueable or use async batch to separate DML from HTTP work.

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.

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

Selective filters:

• Indexed fields: Id, Name, external IDs, audit fields, custom indexed fields
• Return small fraction of rows (platform thresholds ~10% / 5% rules on large tables)

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.

// 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.

WITH USER_MODE enforces CRUD and FLS for the running user at query time—preferred in modern secure Apex.

Related tools:

• WITH SECURITY_ENFORCED — throws if user lacks field access
• Security.stripInaccessible() — removes inaccessible fields from query results

A strong answer is:

USER_MODE and stripInaccessible enforce field- and object-level security in code—I do not assume SysAdmin access in user-facing Apex.

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.

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

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

A strong answer is:

@wire for reactive reads with caching; imperative when I need writes, explicit refresh, or non-cacheable server methods.

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.

1. Annotate with @AuraEnabled (cacheable=true for read-only wires)
2. Enforce sharing in Apex (with sharing)
3. Use USER_MODE / stripInaccessible on queries
4. Validate inputs—never trust client-side checks alone
5. Avoid exposing sensitive fields unnecessarily

A strong answer is:

AuraEnabled methods with sharing, USER_MODE or stripInaccessible, and server-side validation—client controls are UX only, not security.

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.

Pattern:

1. Named Credential stores endpoint + auth (preferred)
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 secrets in source—use Named Credentials or protected custom metadata.

A strong answer is:

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

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 platform events/CDC for push models—I design idempotent upserts and respect API limits.

Named Credentials centralize endpoint URL and authentication—Salesforce manages OAuth/password flows and keeps secrets out of code/repos.

Alternatives: protected Custom Metadata when Named Credentials do not fit.

A strong answer is:

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

Options:

• WITH SECURITY_ENFORCED on SOQL
• WITH USER_MODE (2026 preferred pattern in many codebases)
• Security.stripInaccessible(AccessType.READABLE, records)

A strong answer is:

I enforce FLS in queries and DML via USER_MODE or stripInaccessible—not only UI hiding fields.

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

User-facing controllers should use with sharing.

A strong answer is:

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

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

Uses: integration endpoints mapping, feature flags, field mapping tables, environment-specific settings.

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.

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.

@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.

Use Jest (sfdx-lwc-jest) for unit tests:

• 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.

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.

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.

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. Offer phased approach (Flow now, Apex if limits hit)

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.

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.

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.

A strong answer is:

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

Technical:

• Explain governor limits and bulkification with a before/after example
• Draw order of execution and where your trigger fits
• Compare queueable vs batch with one scenario each
• SOQL vs SOSL, selective queries, bind variables
• @wire vs imperative, LDS vs Apex in LWC
• Named Credentials, callout-after-DML rule
• with sharing, USER_MODE / stripInaccessible
• 75% tests + bulk test example

Cross-links:

• Salesforce Data Engineer if role blends data
• Java fundamentals for OOP/concurrency language
• Design patterns for handler/strategy vocabulary
• Git for DX workflows
• Interview Questions category

Behavioral: Two STAR stories—production limit fire, Flow vs Apex decision.

A strong answer is:

Final week I rehearse bulk trigger refactoring, LWC data flow, one integration diagram, and two production stories—not Trailhead trivia lists.