Preparing for a Salesforce developer interview can be challenging, especially when interviewers move beyond basic definitions and ask you to solve real-world problems. These Salesforce developer interview questions are designed to test practical skills in Apex, triggers, SOQL, LWC, debugging, governor limits, integrations, and Salesforce architecture.

Instead of simply asking “What is Apex?” or “What is a trigger?”, this guide focuses on situations you may actually encounter during a Salesforce development project. You’ll find scenario-based questions, coding challenges, debugging problems, architecture decisions, and senior-level questions that help you prepare for a technical Salesforce developer interview.

Whether you’re a fresher preparing for your first Salesforce developer role or an experienced developer targeting a mid-level or senior position, these questions can help you understand what interviewers are really looking for.

1. Your trigger works for one account but fails when 200 accounts are updated. What would you investigate?

This is primarily a bulkification problem.

I would first look for:

• SOQL queries inside loops
• DML statements inside loops
• Nested loops
• Logic that assumes only one record exists
• Repeated processing of the same related record

For example, this is problematic:

for (Account acc : Trigger.new) {
    List<Contact> contacts = [
        SELECT Id
        FROM Contact
        WHERE AccountId = :acc.Id
    ];
}

A better approach is to collect Account IDs first and query Contacts once.

Set<Id> accountIds = new Set<Id>();

for (Account acc : Trigger.new) {
    accountIds.add(acc.Id);
}

List<Contact> contacts = [
    SELECT Id, AccountId
    FROM Contact
    WHERE AccountId IN :accountIds
];

What the interviewer is testing: Whether you understand that a trigger must be designed for collections, not individual records.

2. An Account trigger updates Contacts whenever the Account Industry changes. How would you prevent unnecessary processing?

First, compare the new and old values.

for (Account acc : Trigger.new) {

    Account oldAcc = Trigger.oldMap.get(acc.Id);

    if (acc.Industry != oldAcc.Industry) {
        // Process Account
    }
}

Then collect only the Account IDs that actually changed. This avoids processing Contacts for Accounts where nothing relevant changed.

What the interviewer is testing: Trigger context and efficient processing.

3. You discover five different Flows and two Apex triggers updating the same Account field. What would you do?

I would not immediately add another piece of automation.

I would first map the existing automation:

1. Identify what each automation does.
2. Determine which automation owns the field.
3. Check for duplicate logic.
4. Review execution order.
5. Identify recursive updates.
6. Determine whether some automation can be consolidated.
7. Decide whether the new requirement belongs in Flow, Apex, or an existing framework.

The goal is to reduce unnecessary automation rather than continuously adding more.

What the interviewer is testing: Platform architecture and maintainability.

4. A business requirement can be implemented using either Flow or Apex. How do you decide?

I would first determine whether Flow can satisfy the requirement cleanly.

Flow may be preferable when:

• The logic is relatively straightforward.
• Admin maintainability is important.
• Standard automation capabilities are sufficient.

Apex may be appropriate when:

• Logic is complex.
• Advanced processing is required.
• Complex integrations are involved.
• Sophisticated transaction control is required.
• Code provides a clear architectural benefit.

The best answer isn’t “always use Apex” or “always use Flow.”

The solution should match the complexity and long-term maintenance requirements.

5. A customer asks you to update 500,000 Salesforce records overnight. Would you create a trigger?

Not necessarily. I would first understand the requirement.

Potential approaches could include:

• Batch Apex
• Bulk API
• Data Loader
• Queueable processing
• Apex cursors where appropriate
• A combination of platform capabilities

If the operation is a data migration rather than ongoing business logic, introducing a trigger may create unnecessary complexity.

What the interviewer is testing: Whether you choose the appropriate platform tool rather than automatically writing Apex.

6. A trigger updates an Account, which causes another automation to update the Account again. How would you troubleshoot it?

I would investigate the complete automation chain. I would look for:

• Trigger recursion
• Flow-triggered updates
• Workflow/legacy automation
• Process automation
• Unnecessary DML
• Multiple components modifying the same records

I would use debug logs and transaction details to determine which automation is causing the repeated update.

A static recursion guard may be useful in some architectures, but I wouldn’t use it as a substitute for understanding the root cause.

7. An Apex transaction suddenly starts hitting CPU time limits after a new Flow is deployed. What would you do?

I would not assume that the Apex code alone is responsible. I would examine the complete transaction:

• Apex execution
• Flow execution
• Trigger execution
• Other automation
• Loops
• Queries
• DML
• Repeated updates

Then I would identify the expensive operations and determine whether the automation can be consolidated or optimized.

Key point: CPU time is consumed across the transaction, so Apex and declarative automation need to be considered together.

8. A developer proposes adding an Apex trigger because a Flow is “too slow.” What would you ask first?

I would ask:

• What specifically is slow?
• How many records are processed?
• Where does the transaction spend time?
• Is the Flow doing unnecessary queries or loops?
• Is Apex actually expected to perform better?
• Can the Flow be optimized?
• Are multiple automations interacting?

Moving logic from Flow to Apex doesn’t automatically make it faster. The actual bottleneck should be identified first.

9. A production integration starts failing because an external API occasionally takes too long to respond. How would you redesign it?

I would avoid making the Salesforce user transaction depend directly on a slow external system whenever possible.

I would consider an asynchronous integration architecture using appropriate Salesforce integration mechanisms.

The design could include:

• Queueable Apex
• Named Credentials
• Retry handling
• Logging
• Error status on the Salesforce record
• Monitoring
• Idempotency

The exact design depends on whether the integration is synchronous by business requirement or can tolerate asynchronous processing.

10. Your trigger works correctly in a sandbox but fails in production. What would you compare?

I would compare:

• Metadata
• Custom settings/custom metadata
• Permissions
• Profiles/permission sets
• Record sharing
• Field-level security
• Validation rules
• Flows
• Other triggers
• Data volume
• API versions
• Integration configuration

The production dataset and automation environment may be very different from the sandbox.

11. Write Apex to identify Accounts whose Industry changed during an update.

A clean approach is:

Set<Id> changedAccountIds = new Set<Id>();

for (Account acc : Trigger.new) {

    Account oldAcc = Trigger.oldMap.get(acc.Id);

    if (acc.Industry != oldAcc.Industry) {
        changedAccountIds.add(acc.Id);
    }
}

The important part isn’t just the syntax. The solution correctly handles multiple records.

12. Write a bulkified solution that updates Contacts when their Account’s Industry changes.

Set<Id> accountIds = new Set<Id>();

for (Account acc : Trigger.new) {

    Account oldAcc = Trigger.oldMap.get(acc.Id);

    if (acc.Industry != oldAcc.Industry) {
        accountIds.add(acc.Id);
    }
}

if (!accountIds.isEmpty()) {

    List<Contact> contacts = [
        SELECT Id, AccountId
        FROM Contact
        WHERE AccountId IN :accountIds
    ];

    for (Contact con : contacts) {
        con.Description = 'Account Industry Changed';
    }

    if (!contacts.isEmpty()) {
        update contacts;
    }
}

The solution avoids SOQL and DML inside loops.

13. You need to find Accounts for a list of Account IDs. Which Apex collection would you use?

A Map<Id, Account> is usually the most useful structure.

Map<Id, Account> accountMap =
    new Map<Id, Account>([
        SELECT Id, Name
        FROM Account
        WHERE Id IN :accountIds
    ]);

You can then retrieve an Account efficiently:

Account acc = accountMap.get(accountId);

14. Write a SOQL query to retrieve Contacts and their Account names.

List<Contact> contacts = [
    SELECT Id,
           FirstName,
           LastName,
           Account.Name
    FROM Contact
    WHERE AccountId != null
];

This demonstrates a child-to-parent relationship query.

15. Write a SOQL query to retrieve Accounts and their Contacts.

List<Account> accounts = [
    SELECT Id,
           Name,
           (SELECT Id, FirstName, LastName
            FROM Contacts)
    FROM Account
];

This demonstrates a parent-to-child relationship query.

16. How would you prevent DML from occurring inside a loop?

Collect records into a list first.

Bad:

for (Account acc : accounts) {
    update acc;
}

Better:

List<Account> accountsToUpdate = new List<Account>();

for (Account acc : accounts) {
    acc.Description = 'Updated';
    accountsToUpdate.add(acc);
}

if (!accountsToUpdate.isEmpty()) {
    update accountsToUpdate;
}

17. How would you write a test for a trigger that modifies Account.Description?

Create the record, insert it, query it again, and assert the expected result.

@isTest
private class AccountTriggerTest {

    @isTest
    static void testDescriptionUpdate() {

        Account acc = new Account(
            Name = 'Test Account'
        );

        Test.startTest();
        insert acc;
        Test.stopTest();

        Account result = [
            SELECT Id, Description
            FROM Account
            WHERE Id = :acc.Id
        ];

        System.assertEquals(
            'Created by automation',
            result.Description
        );
    }
}

The important part is the assertion. Simply executing the code isn’t enough.

18. Write a Queueable Apex class that receives Account IDs.

public class AccountProcessingJob implements Queueable {

    private Set<Id> accountIds;

    public AccountProcessingJob(Set<Id> accountIds) {
        this.accountIds = accountIds;
    }

    public void execute(QueueableContext context) {

        List<Account> accounts = [
            SELECT Id, Description
            FROM Account
            WHERE Id IN :accountIds
        ];

        for (Account acc : accounts) {
            acc.Description = 'Processed';
        }

        if (!accounts.isEmpty()) {
            update accounts;
        }
    }
}

Then:

System.enqueueJob(
    new AccountProcessingJob(accountIds)
);

19. How would you make an Apex callout from asynchronous Apex?

A Queueable class can implement Database.AllowsCallouts.

public class ExternalCalloutJob
    implements Queueable, Database.AllowsCallouts {

    public void execute(QueueableContext context) {

        HttpRequest request = new HttpRequest();

        request.setEndpoint(
            'callout:My_Named_Credential'
        );

        request.setMethod('GET');

        Http http = new Http();

        HttpResponse response =
            http.send(request);
    }
}

For production integrations, use appropriate authentication and credential-management mechanisms rather than hardcoding credentials.

20. You need to process records in chunks. How would you choose between Batch Apex and Queueable Apex?

I would look at the processing model.

Batch Apex is appropriate when the requirement naturally involves processing a large dataset in separate batches.

Queueable Apex is useful for asynchronous jobs, chaining jobs, and more focused units of work.

For very large data volumes, I would also consider whether Salesforce APIs or newer platform capabilities provide a better solution.

21. Find the problems in this trigger.

trigger AccountTrigger on Account (after update) {

    for (Account acc : Trigger.new) {

        List<Contact> contacts = [
            SELECT Id
            FROM Contact
            WHERE AccountId = :acc.Id
        ];

        for (Contact con : contacts) {
            con.Description = acc.Name;
            update con;
        }
    }
}

There are multiple problems.

Problem 1: SOQL inside a loop

The query executes repeatedly.

Problem 2: DML inside a loop

Each Contact is updated individually.

Problem 3: Poor bulkification

The code isn’t designed for large batches.

Better approach

Collect Account IDs, query Contacts once, modify them in memory, and perform one bulk update.

22. A SOQL query returns 50,000 records and the transaction fails. What would you investigate?

I would investigate:

• Number of queried rows
• Whether all records are actually required
• Query selectivity
• Whether processing should be asynchronous
• Whether Batch Apex or another large-data approach is more appropriate
• Whether pagination or chunking is needed

The solution shouldn’t simply be “increase the limit.”

The data-processing architecture may need to change.

23. Your Apex method throws NullPointerException intermittently. How would you troubleshoot it?

I would identify which object is null before dereferencing it.

For example:

if (acc != null && acc.Owner != null) {
    // Process Account
}

But I wouldn’t simply add null checks everywhere.

I would determine why the value is unexpectedly null.

Possible causes include:

• Missing relationship
• Optional field
• Query not returning the required field
• Incorrect assumptions about data
• Different execution paths

24. A query works in Developer Console but fails when called from LWC. What would you check?

I would investigate:

• Apex method visibility
• @AuraEnabled
• Parameters
• Return type
• Sharing
• CRUD/FLS
• User permissions
• Apex errors
• JavaScript error handling
• Whether the method is wired or called imperatively

I would inspect the actual error rather than guessing.

25. An LWC displays old data after another component updates the record. What would you investigate?

I would check:

• How the data was retrieved
• Whether Lightning Data Service is involved
• Wire adapters
• Cache behavior
• Whether the component needs a refresh
• Whether the record was changed outside the component’s current data context

The solution depends on how the component obtains and modifies the data.

26. Your Apex code passes unit tests but fails with real production data. Why can this happen?

Possible reasons include:

• Tests use unrealistic data volumes.
• Tests don’t cover bulk operations.
• Tests don’t cover null values.
• Tests don’t reproduce complex automation.
• Tests don’t cover permission differences.
• Tests don’t cover integration failures.
• Tests don’t test negative scenarios.
• Test data doesn’t represent production relationships.

High code coverage doesn’t guarantee a robust solution.

27. Your trigger causes “Too many SOQL queries.” What is your first step?

I would identify every SOQL operation executed in the transaction.

Then determine:

• Which query is inside a loop.
• Whether multiple classes execute queries.
• Whether automation causes additional execution.
• Whether queries can be consolidated.
• Whether data can be cached in Maps.

I would optimize the transaction rather than simply moving one query without understanding the complete execution path.

28. Your Apex method is consuming excessive heap memory. What would you examine?

I would look for:

• Large queried datasets
• Unnecessary fields
• Large strings
• Large collections
• Duplicate data stored in multiple structures
• Excessive processing in memory

I would retrieve only the data required and avoid retaining unnecessary objects.

29. Would you put all business logic directly inside an Apex trigger?

No.

A trigger should ideally remain lightweight.

For example:

trigger AccountTrigger on Account (before update) {

    AccountTriggerHandler.handleBeforeUpdate(
        Trigger.new,
        Trigger.oldMap
    );
}

The handler/service layer can contain the business logic.

This makes the solution easier to test, maintain, and extend.

30. How would you design a Salesforce application with multiple triggers on the same object?

Ideally, I would avoid uncontrolled trigger proliferation.

I would consider:

• One trigger per object
• Trigger-handler architecture
• Service classes
• Clear separation of responsibilities
• Centralized automation decisions
• Consistent testing

The architecture should make execution behavior understandable to future developers.

31. A Salesforce application needs to integrate with three external systems. How would you design it?

I would first determine:

• Synchronous vs asynchronous requirements
• Data ownership
• Integration direction
• Authentication
• Error handling
• Retry requirements
• Volume
• Monitoring
• Idempotency
• Data transformation

I would avoid embedding integration-specific logic throughout triggers and controllers.

A dedicated integration/service layer can make the architecture easier to maintain.

32. When would you use a Named Credential?

Named Credentials are appropriate for managing endpoint and authentication configuration for callouts without hardcoding sensitive connection details into Apex.

They also provide a cleaner separation between code and environment-specific integration configuration.

33. How would you design an Apex integration that can safely retry failed requests?

I would consider:

1. Logging the integration attempt.
2. Storing the external request/reference ID where appropriate.
3. Recording failure status.
4. Implementing controlled retry logic.
5. Avoiding duplicate external transactions.
6. Using asynchronous processing when appropriate.
7. Monitoring persistent failures.

The external system’s API must also support an idempotent strategy where duplicate requests are possible.

34. An application is becoming difficult to maintain because the same business rule exists in Apex, Flow, and LWC JavaScript. What would you do?

I would establish a clear ownership model.

Business rules should not be duplicated unnecessarily across layers.

I would determine:

• Where the rule belongs.
• Which layer should be authoritative.
• Whether duplicated logic can be removed.
• Whether shared server-side logic is needed.

This reduces inconsistent behavior.

35. How would you design for large data volumes?

I would consider:

• Selective queries
• Efficient indexing
• Bulkification
• Maps and Sets
• Asynchronous processing
• Batch processing
• Bulk APIs
• Reduced automation
• Data archiving strategies
• Query optimization

Large-data-volume design should be considered before the system reaches the point where performance becomes a production problem.

36. An LWC needs to retrieve Accounts. Would you always create an Apex controller?

No.

First, I would determine whether Lightning Data Service or an appropriate UI API capability can provide the required data.

If standard platform capabilities satisfy the requirement, custom Apex may be unnecessary.

I would introduce Apex when the requirement genuinely needs server-side logic that standard services don’t provide appropriately.

37. An LWC needs to retrieve filtered Accounts whenever a search box changes. How would you approach it?

I would determine whether the requirement is suitable for a reactive wire-based approach or requires explicit imperative calls.

I would also consider:

• Debouncing user input
• Avoiding unnecessary server calls
• Query selectivity
• Error handling
• User experience
• Security

The goal isn’t simply to call Apex every time a key is pressed.

38. An Apex method returns records that the current user should not be able to access. What would you investigate?

I would check:

• Class sharing behavior
• User permissions
• Object-level access
• Field-level security
• Database operation mode
• API version
• Whether elevated access was intentionally used

For newer API-version behavior, Salesforce has introduced changes around user-mode database operations and sharing defaults, so API version should be part of the investigation.

39. A developer uses dynamic SOQL with a value supplied by a user. What security concern should you raise?

Potential SOQL injection.

Avoid unsafe string concatenation where possible.

For example:

List<Account> accounts = [
    SELECT Id, Name
    FROM Account
    WHERE Name = :userInput
];

If dynamic query construction is genuinely required, the developer should appropriately validate and sanitize input and carefully construct the query.

40. An external system sends Salesforce a request containing customer information. What security questions should you ask?

I would ask:

• How is the external system authenticated?
• What data is being transmitted?
• Is sensitive information involved?
• How is authorization handled?
• How is the request validated?
• Where are credentials stored?
• Is the integration using secure endpoints?
• What data is logged?
• Who can access the integration logs?

Security needs to be considered at both the API and data levels.

41. Your Salesforce org has 20+ automations on Opportunity. A new requirement requires another automation. What is your approach?

I would stop and assess the existing architecture first.

I would create an automation inventory showing:

• Trigger
• Flow
• Object
• Fields modified
• Entry conditions
• Dependencies
• Integration effects
• Owner

Then determine whether the new requirement can be incorporated into an existing automation framework.

Adding another automation may be technically easy but architecturally wrong.

42. A developer says, “The code has 95% test coverage, so it’s production ready.” Do you agree?

No.

Coverage measures how much code is executed by tests. It doesn’t prove that the code behaves correctly under all important scenarios.

I would look for:

• Assertions
• Bulk tests
• Negative tests
• Security tests
• Exception handling
• Large-data scenarios
• Integration behavior
• Boundary conditions

A 95% coverage number can still hide poor tests.

43. A customer wants a synchronous integration because “the user needs the result immediately.” What would you consider?

I would determine whether immediate response is truly required.

If synchronous processing is necessary, I would evaluate:

• API response time
• Timeout risk
• Failure handling
• User experience
• Governor limits
• External API reliability

If asynchronous processing is acceptable, it may provide a more resilient architecture.

The business requirement should drive the design.

44. A developer suggests using a static Boolean to prevent trigger recursion. Would you approve it?

Not automatically.

A static guard can sometimes be useful, but it can also hide architectural problems.

I would first determine:

• Why recursion occurs.
• Which automation is causing it.
• Whether unnecessary DML can be eliminated.
• Whether automation can be consolidated.
• Whether the trigger design needs restructuring.

Then I’d determine whether a recursion guard is appropriate.

45. Your Apex solution works today but processes 10x more data next year. How would you design for that?

I would avoid designing only for today’s volume.

I would evaluate:

• Query selectivity
• Algorithm complexity
• Bulkification
• CPU usage
• Heap usage
• Asynchronous processing
• Data growth
• Indexing
• API limits
• Automation interactions

A scalable design should account for expected growth.

46. A business asks for a custom Salesforce solution, but you believe a standard Salesforce feature can solve it. What would you recommend?

I would demonstrate the standard capability first.

Custom code introduces:

• Maintenance
• Testing
• Deployment complexity
• Technical debt
• Security considerations

If the standard capability meets the requirement, it may be preferable.

If it doesn’t, then custom development can be justified.

A strong Salesforce Developer doesn’t write Apex simply because they know Apex.

47. You inherit an Apex class containing 2,000 lines of code. It works, but nobody wants to modify it. What would you do?

I wouldn’t rewrite everything immediately.

I would:

1. Understand the existing behavior.
2. Add or improve tests.
3. Identify logical responsibilities.
4. Separate unrelated concerns.
5. Refactor incrementally.
6. Deploy changes in manageable pieces.

The first objective is to make the code safe to change.

48. Production is experiencing a Salesforce performance problem. The business wants a fix immediately. What do you do?

I would separate:

Immediate mitigation

from

Permanent solution.

First identify the failing transaction and reduce the immediate impact where possible.

Then perform root-cause analysis.

A rushed workaround shouldn’t create a larger architectural problem.

49. Two Salesforce Developers propose completely different solutions to the same requirement. How would you decide which one is better?

I would compare them against objective criteria:

• Functional correctness
• Security
• Performance
• Scalability
• Maintainability
• Testing complexity
• Platform limits
• Deployment complexity
• Operational support
• Future requirements

The shortest code isn’t automatically the best solution.

The best solution is the one that meets the requirements with the appropriate long-term trade-offs.

50. The interviewer gives you an unfamiliar Salesforce requirement. How should you approach it?

Don’t immediately start writing Apex.

Use a structured process:

Step 1 — Clarify the requirement

What exactly needs to happen?

Step 2 — Identify the data

Which objects and relationships are involved?

Step 3 — Check standard capabilities

Can Salesforce already do this with standard functionality?

Step 4 — Consider Flow

Can the requirement be implemented cleanly using declarative automation?

Step 5 — Determine whether Apex is necessary

If custom code is required, determine where it belongs.

Step 6 — Consider scale

How many records could be involved?

Step 7 — Consider security

Who can access and modify the data?

Step 8 — Consider failures

What happens if something goes wrong?

Step 9 — Design for testing

How will the solution be tested?

Step 10 — Explain trade-offs

A senior developer should be able to explain not only what solution they selected, but why they rejected the alternatives.

How to Answer Salesforce Scenario Questions

When you encounter a difficult Salesforce interview scenario, use this framework:

R → S → D → T → E

R — Requirement

Understand exactly what the business needs.

S — Scale

Ask how many records/users/transactions are involved.

D — Design

Choose the appropriate Salesforce capability.

T — Test

Explain how you would validate the solution.

E — Exceptions

Explain what happens when something fails.

This framework prevents you from jumping directly into Apex code.

Salesforce Developer Interview: 10 Red Flags Interviewers Look For

Avoid these answers:

1. “I’ll put the SOQL inside the loop.”
2. “I’ll use Batch Apex for everything.”
3. “I’ll always use Apex instead of Flow.”
4. “95% coverage means the code is good.”
5. “I’ll just add a static Boolean.”
6. “I’ll hardcode the API credentials.”
7. “I’ll query all records and process them.”
8. “I’ll add another trigger.”
9. “Sharing doesn’t matter because Apex runs in system context.”
10. “I’ll write the code first and figure out the requirements later.”

Instead, demonstrate platform thinking.

Final Salesforce Developer Interview Checklist

Before your interview, make sure you can explain:

Apex

• Classes
• Interfaces
• Collections
• Exception handling
• DML
• Transactions

SOQL

• Relationship queries
• Aggregate queries
• Dynamic SOQL
• Selectivity
• Large data volumes

Triggers

• Context variables
• Before vs after
• Bulkification
• Recursion
• Trigger handlers

Performance

• Governor limits
• CPU time
• Heap
• SOQL optimization
• DML optimization

Async

• Queueable Apex
• Batch Apex
• Future methods
• Scheduled Apex
• Large-data processing

LWC

• Wire service
• Imperative Apex
• Lightning Data Service
• Component communication
• Error handling

Security

• Sharing
• CRUD
• FLS
• User mode
• SOQL injection
• Secure integrations

Architecture

• Flow vs Apex
• Trigger frameworks
• Integration architecture
• Scalability
• Maintainability
• Technical debt

The Most Important Interview Advice

A Salesforce Developer interview isn’t only testing whether you know Salesforce syntax.

It is testing whether you can answer:

“If this were a real production system, how would you build it?”

When answering scenario questions, explain your thinking.

Don’t just say:

“Use Queueable Apex.”

Say:

“I’d first determine whether the work needs to be synchronous. If it can be asynchronous, I’d evaluate Queueable Apex because the requirement involves a discrete asynchronous job. If the volume is very large and requires batch-oriented processing, I’d evaluate Batch Apex or another large-data approach.”

That distinction demonstrates engineering judgment.

Know the syntax. Understand the platform. Explain the trade-offs.

Let us know if these questions helped you.

References:

• Learn Apex Trigger Fundamentals and Best Practices
• Top Mistakes Developers Make in Salesforce Apex Triggers
• Apex Trigger Code Optimization