Salesforce Interview Preparation: Apex, LWC, Triggers & System Design

Salesforce interview preparation isn't just about memorizing syntax—it's about proving you can build reliable systems within the platform's unique constraints. I learned this the hard way when I bombed my first senior developer interview years ago. I could recite Apex syntax from memory, but I froze when asked to design a trigger framework that could handle a million records a day without hitting governor limits. This guide covers exactly what I look for in a Salesforce developer, distilled from my own preparation journey and years of building production-grade automation on the platform.

Why Salesforce Interviews Are Different

Most developer interviews test algorithms and data structures. Salesforce interviews throw in an extra layer: platform-specific quirks, governor limits, and architectural trade-offs that don't exist in standard CS problems. You're not just writing code—you're designing systems that run inside a shared multi-tenant environment. I've seen brilliant backend engineers trip over simple concepts like with sharing vs without sharing because they'd never thought about record-level security in a platform context.

This guide isn't a feature list. It's a map of the core topics you'll be quizzed on, with the gotchas that interviewers actually care about. If you're early in your prep, start with my Apex developer guide for a broader skills outline.

1. Apex Fundamentals That Get You Hired

Classes, Inheritance, and Abstract Patterns

You'll be expected to write clean, maintainable Apex. That means knowing when to use an abstract class versus an interface, and how to design for testability. I always ask candidates to whiteboard a notification service that can send emails, SMS, and in-app messages. The good ones immediately propose an interface with separate implementations—not a giant if-else block.

Beyond syntax, interviewers probe the without sharing keyword. When you mark a class without sharing, it runs in system context, bypassing record-level permissions. Use it carefully—only for privileged operations like a public-facing portal. I once worked on a project where a developer applied it to the entire service layer, exposing sensitive data. That's a production incident waiting to happen.

Collections: The Silent Performance Killer

Maps, lists, and sets are your bread and butter, but misuse of them causes most SOQL query timeouts. A classic interview question: how do you aggregate child records for a parent? The wrong answer is a loop with a query inside—that's an SOQL query per record, immediately hitting governor limits. The right answer: query all children in one go, then build a Map<Id, List<Child>>.

// Bulkified pattern: query all child records once
List accounts = [SELECT Id FROM Account LIMIT 100];
Map> contactsByAccount = new Map>();

for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accounts]) {
    if (!contactsByAccount.containsKey(c.AccountId)) {
        contactsByAccount.put(c.AccountId, new List());
    }
    contactsByAccount.get(c.AccountId).add(c);
}

Honestly, this tripped me up early in my career. I wrote a nested loop that queried inside a loop, and it worked on small data sets. Then I deployed it to production, and the batch job timed out. The docs tell you about limits, but they don't tell you how to think in terms of bulkification from the start.

2. SOQL and SOSL: Querying Like a Pro

You'll get questions on query optimization, relationship queries, and common pitfalls. Interviewers want to see that you know LIMIT and OFFSET aren't substitutes for proper filtering. They'll ask about AggregateResult for rollups, and how to use a subquery to get child records without N+1.

A frequent tricky question: how do you search for text across multiple objects? SOSL is your answer, but it has limitations—it can't search in some field types, and it doesn't support ORDER BY. I'd mention you can use FIND with RETURNING to get typed results. But for advanced patterns, I usually steer toward Bulk API best practices when the data volume grows beyond what native queries can handle.

3. Trigger Patterns That Survive Production

One Trigger Per Object

This is the golden rule, and almost every interviewer will test it. You have one trigger per object, and that trigger delegates to handler classes. Why? Because if you have multiple triggers on the same object, you can't control the order of execution, and updates become a debugging nightmare.

Context Variables and Bulkification

Inside the trigger, you handle all Trigger.old, Trigger.new, and context flags like isAfter, isInsert, etc. A good pattern is to split logic into before/after handlers, and avoid queries in before triggers since you don't have IDs yet.

// Example trigger handler pattern
public class AccountTriggerHandler {
    public static void handle() {
        if (Trigger.isAfter && Trigger.isInsert) {
            ContactService.assignDefaults(Trigger.new);
        }
        if (Trigger.isAfter && Trigger.isUpdate) {
            AccountService.syncParentActivity(Trigger.newMap, Trigger.oldMap);
        }
    }
}

In interviews, expect the question: 'Why can't you add a SOQL query inside a for loop?' The answer isn't just 'governor limit'—it's about performance and reliability at scale. I emphasize that even though the 100 SOQL limit is strict, the real cost is the potential for timeouts and lock contention in concurrent transactions.

4. LWC: Modern Frontend Development on Salesforce

Lightning Web Components Basics

LWC is now the standard, so you need to know its lifecycle, reactive properties, and the difference between public and private properties. Interviewers love asking about @track—actually, since LWC uses JavaScript getters and setters, you don't need @track for objects unless you're doing deep observation. But you do need to understand how to wire Apex methods with @wire or imperative calls.

You'll also be asked about communication between components: custom events for parent-child, pubsub for cross-component, and Lightning Message Service for complex scenarios. I usually recommend message service for anything beyond a single child, because it's more secure and maintained by Salesforce.

// Example LWC Apex call
import getAccounts from '@salesforce/apex/AccountService.getAccounts';

export default class AccountList extends LightningElement {
    accounts;
    
    connectedCallback() {
        getAccounts()
            .then(result => {
                this.accounts = result;
            })
            .catch(error => {
                console.error(error);
            });
    }
}

Rendering and Performance

Interviewers might ask how to handle large lists of records. You should mention virtual scrolling or using lightning-datatable with lazy loading. Don't just render a thousand rows in a for:each—that kills the browser. Also, be ready for questions on lightning-record-form versus input fields, and when to use one over the other based on data complexity.

5. Integration Patterns: Connecting Salesforce to the World

REST and SOAP APIs

Salesforce has both, and you need to know when to use which. REST is simpler for modern apps, SOAP is for legacy enterprise systems. You'll be quizzed on how to make outbound callouts with HttpRequest and HttpResponse, and how to handle timeouts and retries.

// Simple outbound REST callout
HttpRequest req = new HttpRequest();
req.setEndpoint('https://api.example.com/endpoint');
req.setMethod('GET');
req.setHeader('Authorization', 'Bearer ' + accessToken);

Http http = new Http();
HttpResponse res = http.send(req);

if (res.getStatusCode() == 200) {
    // Parse and process
}

Don't forget to mention Named Credentials—they handle auth and URL routing without hardcoding secrets. And if you're integrating with external systems that require user context, consider Salesforce Connect for OData-style data access. My rule: if latency is tolerable, use platform events for async patterns; if you need synchronous response, REST callouts with appropriate timeouts.

6. System Design for Salesforce Architects

This is where the interviewer separates senior candidates from the rest. You'll be given a scenario—say, a sales team needs to sync data with an external ERP, generate PDFs, and send notifications. Your job is to design the flow, highlighting where to use Apex triggers, queueable jobs, batch processes, or platform events.

Bulk Data Processing Decisions

I always ask: 'How would you process a nightly job that updates 500,000 records?' A good answer: Batch Apex with a sensible batch size, using Database.Batchable and properly handling state. Or, if the data is coming from outside, use the Bulk API. I also probe for error handling—an interview candidate who can describe how to log failures and retry them is a winner.

Event-Driven Architecture

More modern systems use platform events to decouple components. Instead of a batch job polling for changes, you raise an event when an account's status changes, and subscribers act on it. This scales better and reduces lock contention. For an event-driven automation project I built, I used platform events to sync accounts to an external data warehouse, which kept the sync out of users' transactions.

7. Governor Limits and Performance Pitfalls

You'll be drilled on limits: 100 SOQL queries, 50,000 total DML rows, heap size of 6 MB, and so on. But the deeper question is how to write code that stays under limits. Interviewers want to hear about bulkification, efficient queries, and avoiding expensive operations in loops.

One mistake I see constantly: using DML inside a loop. Even if it's within the limit, it causes lock contention and slow performance. Always collect records in a list, then update once. I also advise against complex nested loops with map lookups when a simple set operation would do—every millisecond counts in a multi-tenant environment.

8. Testing and Deployment: Proof of Quality

Salesforce requires 75% code coverage, but that's the floor. Interviewers ask how you write unit tests that are meaningful—like testing bulk scenarios, and testing negative paths. You'll also discuss deployment processes: change sets, source-backed orgs, and CI/CD with GitHub Actions or Salesforce DX. I always probe for testing strategy: do they write one test method that tests everything, or focused tests per scenario?

@isTest
static void testBulkAccountTrigger() {
    List accounts = new List();
    for (Integer i = 0; i < 200; i++) {
        accounts.add(new Account(Name = 'Test' + i));
    }
    insert accounts;
    
    // Verify defaults were applied
    List contacts = [SELECT Id FROM Contact WHERE AccountId IN :accounts];
    System.assertEquals(200, contacts.size(), 'Contacts should be created for all accounts');
}

In interviews, I want to see that you've faced a failure—like a test that passed locally but failed in a sandbox due to data differences. Show that you understand query locators, @TestSetup, and how to handle bulk data in tests.

9. Common Interview Scenarios and Answers

Take the classic: 'A trigger runs after insert, but it's interfering with another process. How do you debug?' You'd check debug logs, trace the order of execution, and look for recursion—use a static flag to prevent self-triggering. Or: 'How would you design a callout that must happen asynchronously because you're over the callout limit in a sync context?' Use a queueable or a platform event.

These scenarios test your ability to think on your feet and map Salesforce-specific features to business need. I've seen candidates freeze because they didn't know Trigger.isBefore vs Trigger.isAfter. The best way to prep: write a trigger, then write a test that calls it with 200 records—that's what an interviewer might ask you to do live.

Frequently Asked Questions

What's the most common Salesforce interview question?

The most common is about governor limits—describe one and how you handle it. Usually, the SOQL query limit of 100 per transaction is asked. Be ready to explain how to minimize queries by bulkifying your code and using maps.

How do I prepare for an LWC-focused interview?

Practice building simple components that call Apex methods, handle events, and use reactive properties. Understand the component lifecycle (constructor, connectedCallback, renderedCallback) and be able to explain why you'd use one over another. Also, learn to use Lightning Message Service for cross-component communication.

Do I need to know system design concepts for a Salesforce developer interview?

Yes, especially for senior roles. Interviewers will present a scenario like an integration with an external system and ask how you'd architect the solution. You should be familiar with batch vs. real-time patterns, event-driven architecture, and how to handle large data volumes.

What's the best way to practice triggers for interviews?

Write a trigger for a common object like Account or Opportunity that does something beyond a simple field update—like creating child records or making a callout. Then write a test that inserts 200 records to ensure it's bulk-safe. This is the exact exercise I'd give in an interview.

How can I stand out as a Salesforce candidate?

Show you've built real-world solutions that handle production data. Mention a project where you dealt with a tricky governor limit or integration failure. Be ready to walk through the architecture and trade-offs. Reading the Salesforce integration patterns guide on developer.salesforce.com helps you speak to practical concerns.

What I Actually Do Before Any Interview

Honestly, the most valuable prep I do now is revisiting my own past mistakes. I'll pull up a project where I hit a governor limit or a recursion bug and walk through how I fixed it, out loud. That story is more convincing than any textbook answer. I also always run through a few scenarios where I have to choose between batch and platform events. I don't memorize answers; I understand the trade-offs. You'll be more confident if you can say, 'I had a similar situation, and here's what I did.'

One final tip: don't just study concepts—build a small proof-of-concept before the interview. Create a trigger that processes 1,000 records, add a callout with retries, and wire it up in an LWC. That hands-on experience will give you concrete examples to talk about, and it's the kind of thing that makes an interviewer lean forward.