What Apex Interviewers Actually Test
Apex interviews at every level — from junior admin-developer to senior architect — consistently probe four areas: governor limits and bulkification, core OOP/design patterns (interfaces, abstract classes, the trigger handler pattern), asynchronous Apex (@future, Queueable, Batch, Scheduled), and testing discipline (assert-driven tests, code coverage, @testSetup). Interviewers care less about syntax recall than about whether a candidate instinctively reaches for bulk-safe patterns and can explain why a naive solution breaks in production, since that judgment is what actually prevents outages on a live Salesforce org.
Cricket analogy: A cricket selector doesn't just ask a bowler to recite the rules of a yorker — they watch the bowler execute one under match pressure to judge real skill, just as an Apex interviewer cares less about syntax recall and more about whether bulk-safe instincts show up in a live coding exercise.
Governor Limits and Bulkification Questions
Expect questions like 'What happens if you update 300 records via Data Loader and your trigger queries inside a loop?' — the correct answer names the specific exception (System.LimitException: Too many SOQL queries: 101) and explains the fix using Sets/Maps outside the loop. A frequent follow-up probes async limits: Queueable Apex allows chaining one job to another, Batch Apex processes very large record sets in chunks (default batch size 200, configurable up to 2000), and @future methods cannot take SObjects as parameters (only primitive types and collections thereof) because the call is serialized for asynchronous execution.
Cricket analogy: Asking a candidate what happens when a bowler exceeds their over quota is like asking what happens when Apex exceeds its SOQL query quota — both have a hard, enforced ceiling with a specific, named consequence.
OOP, Interfaces, and Testing Questions
Interviewers commonly ask candidates to implement an interface or to explain the difference between an abstract class and an interface in Apex (an abstract class can hold shared implementation and instance state; an interface cannot, and a class can implement multiple interfaces but extend only one class). On testing, expect 'Why must every trigger have at least one test method, and what does 75% code coverage actually guarantee?' — the correct answer is that 75% coverage is a deployment gate, not a quality guarantee, since it says nothing about whether the tests contain meaningful System.assertEquals statements versus just executing lines without verifying behavior.
Cricket analogy: A coach explaining that a bowling action template defines what every bowler must do — deliver a legal ball — but each bowler implements their own technique, mirrors how an Apex interface defines a contract without dictating implementation.
public interface Shape {
Decimal getArea();
}
public class Circle implements Shape {
private Decimal radius;
public Circle(Decimal radius) { this.radius = radius; }
public Decimal getArea() {
return Math.PI * radius * radius;
}
}
@isTest
private class CircleTest {
@isTest
static void testGetArea() {
Circle c = new Circle(2);
Decimal area = c.getArea();
System.assertEquals(Math.PI * 4, area, 'Area should match pi*r^2');
}
}Async Apex and Advanced Scenario Questions
Senior-level interviews probe async orchestration: 'When would you choose Batch Apex over Queueable?' — the expected answer distinguishes Batch Apex's use case (processing very large record sets, like millions of Leads, in chunks via start/execute/finish with a QueryLocator) from Queueable's use case (a single follow-up unit of work needing job chaining, like calling an external callout after a DML commit). A classic trick question is 'Can you make a callout from a trigger?' — the answer is no directly, so the correct pattern is enqueuing a Queueable class from the trigger to make the callout asynchronously outside the trigger's transaction.
Cricket analogy: Choosing between a specialist death-over bowler (Queueable, one precise follow-up task) versus rotating the entire bowling attack across a full innings (Batch Apex, chunked processing of a huge workload) is exactly the tradeoff an interviewer expects a candidate to articulate.
A strong interview signal: candidates who spontaneously mention Test.startTest()/Test.stopTest() to reset governor limits and isolate async execution when discussing bulk or async scenarios, without being prompted.
- Interviewers weight applied judgment (why a pattern is chosen) far more heavily than syntax recall.
- Be ready to name the exact exception a governor-limit violation throws, e.g. System.LimitException: Too many SOQL queries: 101.
- Know the core async Apex types — @future, Queueable, Batch, Scheduled — and when each is the right choice.
- Understand the abstract class versus interface distinction: abstract classes can hold shared implementation and state; interfaces only define a method contract.
- 75% code coverage is a Salesforce deployment gate, not proof of test quality — meaningful assertions matter more than line coverage.
- Triggers cannot make synchronous callouts directly; enqueue a Queueable class to perform the callout asynchronously.
- Batch Apex suits very large record sets processed in chunks; Queueable suits a single chained follow-up unit of work.
Practice what you learned
1. What is the correct fix an interviewer expects when told a trigger queries inside a loop and fails on a 300-record Data Loader update?
2. Why can't a trigger make a synchronous callout directly?
3. What's the key structural difference between an interface and an abstract class in Apex?
4. What does 75% Apex code coverage actually guarantee before deployment?
5. When would Batch Apex be preferred over Queueable Apex?
Was this page helpful?
You May Also Like
Apex Best Practices
The core disciplines — bulkification, selective SOQL, and layered architecture — that keep Apex code safe at production scale.
Building a Trigger Handler
How to structure a one-trigger-per-object handler class with context-specific methods, recursion guards, and safe use of Trigger context variables.
Common Apex Pitfalls
The recurring bugs — unbulkified loops, hardcoded Ids, recursive triggers, and swallowed exceptions — that cause most Apex production incidents.
Apex Quick Reference
A fast lookup for Apex collection syntax, SOQL/DML statement forms, and the exact governor limit numbers that matter day-to-day.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics