Salesforce Developer Interview Questions (Apex & Lightning)

Apex is Salesforce’s proprietary object-oriented programming language with syntax similar to Java but runs entirely on-demand on Force.com platform. Key differences:

• Apex compiles to metadata stored on platform, executed by runtime interpreter
• Strictly enforced governor limits prevent resource monopolization in multi-tenant environment
• Built-in database integration with SOQL and DML operations
• Automatic state management and transaction control

Apex supports classes, interfaces, inheritance, collections, and exception handling. Unlike Java, Apex doesn’t support multiple inheritance, has no file I/O operations, and requires 75% test coverage for production deployment.

Governor limits enforce runtime resource constraints preventing any single tenant from monopolizing shared platform resources. Critical limits include:

• 100 SOQL queries per synchronous transaction (200 for asynchronous)
• 150 DML statements per transaction
• 50,000 records total retrieved by SOQL queries
• 10 MB maximum heap size
• 10 seconds CPU time limit (60 for asynchronous)

Developers must write bulkified code processing records in collections rather than one-by-one loops. Use Limits class checking current consumption: Limits.getQueries() returns SOQL queries used.

Test classes use @isTest annotation containing test methods with testMethod keyword or @isTest annotation. Salesforce requires minimum 75% code coverage for production deployment ensuring code quality.

Best practices:

• Use Test.startTest() and Test.stopTest() resetting governor limits
• Create test data using @TestSetup methods for reusability
• Test positive scenarios, negative scenarios, and bulk operations
• Use System.assert() methods validating expected outcomes
• Avoid @SeeAllData=true preventing org data dependencies

Example: @isTest static void testAccountCreation() { Test.startTest(); Account acc = new Account(Name='Test'); insert acc; Test.stopTest(); System.assertNotEquals(null, acc.Id); }

Triggers execute Apex code automatically before or after DML events (insert, update, delete, undelete) on records. Before triggers run before records saved to database, used for validation and field modification. After triggers run after database save, used for accessing record IDs and related record operations.

Trigger context variables:

• Trigger.new: List of new versions of records
• Trigger.old: List of old versions (update/delete only)
• Trigger.newMap: Map of IDs to new records
• Trigger.isBefore, Trigger.isAfter: Boolean context flags

Best practice: One trigger per object using handler class pattern delegating logic to separate classes maintaining code organization and testability.

Asynchronous Apex executes code outside synchronous transaction with higher governor limits. Types include:

• Future Methods: @future annotation for simple async operations and HTTP callouts. Cannot chain future calls or pass sObjects as parameters
• Queueable Apex: Implements Queueable interface allowing job chaining and sObject parameters. Returns job ID for monitoring
• Batch Apex: Implements Database.Batchable processing up to 50 million records in chunks. Use for data migrations and bulk operations
• Scheduled Apex: Implements Schedulable interface running code at specified times like cron jobs

Use Future for quick async tasks, Queueable for job chaining, Batch for large data volumes, Scheduled for recurring processes.

HTTP callouts use HttpRequest and HttpResponse classes communicating with external REST APIs. Must occur in asynchronous context (future/queueable) when triggered by DML operations.

Example:

• Create request: HttpRequest req = new HttpRequest(); req.setEndpoint('https://api.example.com'); req.setMethod('GET');
• Send request: Http http = new Http(); HttpResponse res = http.send(req);
• Process response: if(res.getStatusCode() == 200) { String body = res.getBody(); }

Use Named Credentials storing endpoint and authentication securely avoiding hardcoded credentials. Whitelist remote site in Remote Site Settings before callouts. Handle timeouts and errors gracefully with try-catch blocks.

with sharing enforces user’s record-level sharing rules (OWD, sharing rules, role hierarchy) when querying data. without sharing ignores sharing rules running in system context seeing all records regardless of user access.

Default behavior depends on execution context. Classes without explicit declaration inherit from caller. Triggers run in system mode (without sharing by default) unless explicitly declared.

Best practice: Use with sharing for user-initiated operations respecting security. Use without sharing only when business logic requires seeing all records like batch jobs or integration. Always document security decisions in code comments.

Dynamic Apex accesses sObjects and fields at runtime rather than compile time using Schema describes and reflection. Enables flexible code adapting to metadata changes without recompilation.

Use cases:

• Dynamic SOQL: String query = 'SELECT Id FROM ' + objectName; List<sObject> records = Database.query(query);
• Field access: sObject obj = ...; Object value = obj.get('FieldName__c');
• Schema describes: Schema.getGlobalDescribe() retrieving all object metadata

Caution: Sanitize user input preventing SOQL injection using String.escapeSingleQuotes(). Prefer static references when object/field known at compile time for type safety and performance.