Here are the Apex interview questions that come up most often, with clear, correct answers.
Fundamentals
Q1: What is Apex? Apex is Salesforce's proprietary, strongly-typed, object-oriented programming language, syntactically similar to Java, that runs on the Salesforce platform (Lightning Platform) and executes in a multi-tenant environment.
Q2: Why does Apex have governor limits? Because Salesforce runs on shared, multi-tenant infrastructure — governor limits prevent any single customer's code from monopolizing shared resources and degrading performance for everyone else. See our full Governor Limits guide.
Q3: What's the difference between a trigger and a class? A trigger is Apex code that runs automatically in response to a DML event (insert, update, delete, undelete) on a specific object. A class is a reusable container of methods and properties — best practice is to keep trigger bodies thin and delegate logic to a handler class.
Bulkification & Triggers
Q4: What does "bulkify" mean, and why does it matter? Bulkifying means writing code that correctly and efficiently handles a batch of records (e.g., 200 at once from a Data Loader import), not just a single record. Salesforce always processes DML in batches, so any trigger or class not written for bulk operation will eventually hit governor limits or produce incorrect results in production.
Q5: What are the trigger context variables?
Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, and boolean flags like Trigger.isInsert, Trigger.isBefore, etc. — they give you access to the records being processed and the operation type.
Q6: Why is it bad practice to have multiple triggers on the same object? Because trigger execution order across multiple triggers on one object isn't guaranteed, which makes behavior unpredictable. Best practice is one trigger per object, delegating to a handler class (a "trigger framework" pattern).
Testing
Q7: What's the minimum code coverage required to deploy to production? 75% overall, but this is a minimum, not a target — good test classes assert actual behavior, not just execute lines to hit a coverage number.
Q8: What should a good Apex test class actually verify?
That the code produces the correct outcome under realistic conditions — including bulk data (200 records), and both positive and negative/edge cases — using System.assert statements, not just "did it run without throwing an error."
Q9: Why use Test.startTest() and Test.stopTest()?
They reset governor limits for the code inside the block and force any asynchronous Apex (e.g., @future, Queueable) called within it to execute synchronously before stopTest() completes — letting you test async behavior deterministically.
Async Apex
Q10: When would you use Batch Apex vs. Queueable Apex?
Batch Apex is built for processing large data volumes (thousands+ of records) in manageable chunks, with built-in start/execute/finish lifecycle. Queueable Apex is better for more complex, chainable jobs on smaller volumes, and can accept non-primitive parameter types (unlike @future methods).
Q11: What's a limitation of @future methods that Queueable Apex solves?
@future methods can only accept primitive data types as parameters (not sObjects or custom objects), can't be chained reliably, and can't be monitored for completion the way Queueable jobs can via System.enqueueJob return IDs.
Security
Q12: What's the difference between "without sharing" and "with sharing" in an Apex class?
with sharing enforces the running user's record-level sharing rules for the class's operations; without sharing ignores them (running in system context for sharing purposes). Best practice is to default to with sharing unless there's a specific, justified reason not to.
Q13: Why should you avoid dynamic SOQL built from unsanitized user input?
It risks SOQL injection — always use bind variables or the String.escapeSingleQuotes() method when building dynamic queries from user input.
Preparing Further
Understanding these answers is a strong start, but real interviews often layer in scenario-based follow-ups ("how would you refactor this trigger?"). Our Salesforce Developer Training course includes technical mock interviews built around exactly this kind of follow-up questioning.