If you’re prepping for a new role, you know that Salesforce interview questions can range from simple admin tasks to complex architectural trade-offs. I’ve sat on both sides of the desk, and I can tell you that the best candidates don’t just recite documentation. They talk about the time they broke a production org or how they saved a project with a clever Flow. This guide is a collection of the most common questions I’ve seen lately, along with the context you need to answer them like a pro.
Common Salesforce interview questions on automation
1. Flow vs. Apex: When do you choose?
Look, the old days of Workflow Rules and Process Builder are over. Salesforce is pushing Flow hard, and for good reason. But you still need to know when to pull the trigger on code. I usually tell people to use Flow first unless you’re dealing with massive data volumes, complex list processing, or integrations that need heavy lifting. If you want a deeper look at this, check out this guide on Apex vs Flow to see where the lines are drawn.
2. Dealing with recursion in Triggers
One thing that trips people up is when a trigger updates a record, which then fires the same trigger again. It’s a mess. To stop this, we use a static Boolean variable in a handler class. Since static variables persist through the transaction, we can “flip a switch” to tell the code not to run twice. Here’s how it looks:
public class TriggerHandler {
public static Boolean hasRun = false;
public static void handle(List<Account> accounts) {
if(hasRun) return;
hasRun = true;
// logic goes here
}
}3. @wire vs. Imperative calls in LWC
So what does this actually mean for your UI? Use @wire when you want data to just “be there” and update automatically when the record changes. It’s reactive and easy on the eyes. But if you need to run logic only when a user clicks a button, or if you need to perform a DML operation, you have to go imperative. It gives you more control, but you have to handle the data yourself.
4. The Mixed DML Error
This is a classic. It happens when you try to update a “Setup” object (like a User or Profile) and a “Non-Setup” object (like an Account) in the same transaction. Salesforce hates this because it messes with security. The fix? Wrap one of those updates in an @future method or a Queueable job to separate the transactions.
Advanced Salesforce interview questions for developers
5. SOQL vs. SOSL: Which tool for the job?
I see people get these mixed up all the time. SOQL is your go-to for specific queries on one object. You know what you’re looking for. SOSL is more like a Google search. If you need to find the word “Acme” across Leads, Accounts, and Contacts all at once, SOSL is your best friend. It’s faster for multi-object searches but less precise for specific data fetching.
6. The four types of Asynchronous Apex
When the work is too heavy for the immediate UI, we go async. Here’s the breakdown:
- Future: Simple, hands-off tasks. No chaining allowed.
- Queueable: The modern way. You can chain jobs and pass complex data types.
- Batch: For the big stuff. If you’re processing 50,000 records, this is the only way to go.
- Scheduled: Set it and forget it. Great for nightly cleanups.
7. Bulkification: The cardinal rule
Honestly, most teams get this wrong at some point. Never, ever put a SOQL query or a DML statement inside a loop. If you have 200 records, you’ll hit a governor limit before you can blink. Always collect your data into a List or Map and perform the operation once. If you’re working with automation, you should read up on how to handle bulk record processing in Flows to stay safe.
8. Why bother with Lightning Data Service (LDS)?
LDS is essentially the “no-code” way to handle data in LWC. It handles caching and security for you. If you’re just building a simple form to edit a record, don’t write Apex. Use lightning-record-edit-form. It’s faster to build and better for performance.
9. Can Flow actually replace Apex?
For about 80% of use cases, yes. With the new Flow features, we can do things that used to require a Senior Developer. But for high-performance needs or extremely complex business logic, Apex still wins. It’s about picking the right tool, not just the newest one.
10. Using Test.startTest() and Test.stopTest()
These aren’t just for show. They give you a fresh set of governor limits for your test logic. More importantly, when you call Test.stopTest(), all your asynchronous code is forced to finish. Without it, your tests might fail because the async job hasn’t actually run yet.
Practical Tip: When an interviewer asks about governor limits, don’t just list numbers. Explain that they exist to prevent one company’s bad code from slowing down the entire multi-tenant server. It shows you understand how the platform actually works.
11. 15-digit vs. 18-digit IDs
The 15-digit ID is what you see in the URL. It’s case-sensitive. The 18-digit ID is the API-safe version. If you’re moving data into Excel, always use the 18-digit version because Excel doesn’t care about case sensitivity and will treat “abc” and “ABC” as the same record.
12. Invocable Methods
Want to give your Flow superpowers? Write an Apex method with the @InvocableMethod annotation. This lets an Admin call your custom code directly from the Flow builder. It’s the perfect bridge between clicks and code.
13. Trigger Context Variables
You need to know what’s happening and when. Trigger.isBefore is for validation or changing values before they hit the database. Trigger.isAfter is for when you need the Record ID to update child records. Maps like Trigger.oldMap are lifesavers when you need to compare the “before” and “after” values of a field.
14. Why do we use @AuraEnabled?
If you want your LWC or Aura component to talk to an Apex class, you have to invite it in with @AuraEnabled. If you’re just fetching data, always add (cacheable=true). It makes the UI feel much snappier because Salesforce stores the result on the client side.
15. Scheduling a Batch Job at 2 AM
You’ll likely be asked for the syntax. It uses a Cron expression. It looks like this:
System.schedule('Nightly Cleanup', '0 0 2 * * ?', new MyBatchClass());16. Governor Limits: The “Why”
Salesforce is a multi-tenant environment. Imagine living in an apartment building; you can’t use all the water at once, or your neighbors will be pretty upset. Limits on SOQL (100 per transaction) and DML (150 per transaction) keep the “building” running smoothly for everyone.
17. Parent-Child SOQL Queries
You have to know the syntax for both directions. Going up to the parent is easy: SELECT Name, Account.Name FROM Contact. Going down to the children requires a subquery: SELECT Name, (SELECT LastName FROM Contacts) FROM Account. Note the plural “Contacts” – that’s the relationship name.
18. What is a Wrapper Class?
Think of a wrapper class as a custom container. Sometimes a single SObject doesn’t have all the fields you need for a UI table. You can create a simple class that holds an Account, a Boolean for a checkbox, and a String for a custom message. It keeps your data organized.
19. Order of Execution: The simplified version
If you memorize nothing else, remember this: Validation rules run first, then “before” triggers, then “after” triggers, then assignment rules, and finally Flows. If a Flow updates the record again, the whole cycle (mostly) starts over. This is why recursion is such a headache.
20. Continuous Integration (CI/CD)
In a real-world project, we don’t just click “Deploy” in a Change Set. We use tools like GitHub Actions or Copado to automate the process. It helps teams work on the same code without stepping on each other’s toes. If you’ve used it, mention it – it’s a huge plus.
Key Takeaways
- Prioritize Flow: Use it for most automation, but know when Apex is necessary for scale.
- Bulkify everything: Keep queries and DML out of loops to avoid hitting limits.
- Understand Context: Know the difference between “before” and “after” triggers and when to use each.
- Explain the “Why”: Don’t just give a definition; explain the trade-offs of your choice.
Mastering these Salesforce interview questions isn’t just about passing a test. It’s about showing that you can think like an architect. When you’re in the room, focus on your hands-on experience. If you’ve dealt with a tricky Mixed DML error or optimized a slow SOQL query, tell that story. Interviewers love hearing about how you solved real problems in the wild. Good luck with the prep!