Apex Interview Questions

Analogy categoryAnalogies

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.

apex

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.