The Vital Guide to Salesforce Interviewing
In general, writing code is an essential part of extending any software, product, or platform. But when it comes to Salesforce, coding is not necessarily required.
This is possible because Salesforce provides a comprehensive toolbox, including drag-and-drop tools to build your database, standard user interfaces (UIs) to edit with point-and-click tools, and workflow engines with advanced automation capabilities.
By sticking to only these tools, it’s possible to a create an advanced and customized business solution inside Salesforce without writing a single line of code.
Of course, this out-of-the-box toolkit will not work perfectly for everyone, and you’ll hit a wall.
This is when coding comes into play and when you’ll have to hire a developer to help you.
When you hit that wall, you’ll need an expert-level Salesforce developer, who is not only fluent with SQL and Salesforce’s drag-and-drop tools, but someone who also knows Apex and SOQL, Salesforce’s custom programming and query language.
Most people won’t know the right questions to ask, which is why we put together this guide. In it, you’ll find our top Salesforce developer interview questions and answers.
Questions and Answers
Q: Name the available collection types in Apex. Discuss their limits and characteristics.
In Salesforce, Apex supports three different collection types: Lists, Maps, and Sets.
Lists are ordered collections of elements that are distinguished by their indices. Lists should be used when you want to identify an element by its index. It’s also important to note that lists can contain duplicates.
Maps are collections of key-value pairs, where each unique key maps to a single value. A key can be any primitive data type, and value can be a primitive, sObject, collection type, or an Apex object.
Sets are unordered collections of elements that do not contain any duplicates (in contrast to Lists, as noted above).
Which type should you use? That depends on what you’re trying to accomplish and the characteristic of each collection type described above.
It’s also worth mentioning that removing items from a set is more straightforward than removing an item from a list. When you remove an item from a list, the index will shift left.
There is no inherent limit on the number of items a collection can hold, although there is an implicit limit based on the heap size.
Due to the multi-tenant nature of the environment, Salesforce maintains a table with all the limits. Salesforce occasionally revises these limits and adjusts the execution capabilities.
Q: Discuss the transaction control limitations in Apex.
Salesforce is a multi-tenant environment, which essentially means that all resources are shared among its users. To maintain system performance and availability, the platform enforces process limits.
All Salesforce developers must know these limits well because they affect how a solution should be engineered and coded.
Here’s the most relevant limitations regarding transaction control.
- Static variables are not reverted during a RollBack.
- The ID on an sObject inserted after setting a SavePoint is not cleared after a RollBack.
- Each RollBack or SavePoint you set, counts against the governor limit for the DML statements.
- References to SavePoints cannot cross trigger invocations because each trigger invocation is a new trigger context.
- If you set more than one SavePoint, then roll back to a SavePoint that is not the last SavePoint you generated, the later SavePoint variables become invalid.
Q: What is the time limit for synchronous Apex requests? Discuss the strategies that can be used to avoid hitting the limit.
A synchronous Apex request that is running for more than five seconds is considered to be long-running. To avoid reaching this limit, it’s recommended to use any of the following strategies.
- Tune SOQL and DML operations, making sure queries are selective.
- Check if Batch Apex is a possible alternative to convert synchronous processes into asynchronous processes.
- Try to limit calls to synchronous web services.
These are standard solutions Salesforce developers know to look out for when reaching limits.
Limits are at the very core of Salesforce development, and every developer should understand them.
When you get errors mentioning limits, you should tweak your code to optimize, or break your solution into chunks that will stay within the Salesforce enforced limits.
Q: What is the main difference between a global and a public class in Apex? Explain with examples.
Global classes are visible in any application or namespace, while public classes are only visible within a specific application or namespace.
All classes using the public access modifier will be accessible only within your own application or namespace.
public class MyClass {
// Methods accessible only within your application
}
Classes using the global access modifier are accessible by Apex everywhere. An example would be a class that allows an external application to invoke an Apex Web service to perform an action in Salesforce.
global class MyWebService {
// Methods accessible by Apex everywhere, e.g.: the SOAP API
}
Q: Explain how to write an Apex class that will take into consideration the sharing rules for the current user. Explain with examples.
By default, Apex code runs in the system context, with access to all objects and fields object permissions.
If you need to write a class that will take the current user sharing rules into consideration, you need to declare it with the with sharing keywords.
This class will be executed with access in the system context, with access to all objects and fields.
public without sharing class MyNoSharingRuleClass {
// Code here will NOT enforce the current user sharing rules
}
This class will enforce the sharing rules of the current user.
public with sharing class MySharingRuleClass {
// Code here WILL enforce the current user sharing rules
}
When a class is declared without these access modifiers, the current sharing rules are used. By default, the class will not enforce sharing rules except if the sharing rules are acquired from a calling class.
Q: Explain what Apex Unit Tests are. Discuss the deploy requirements for Apex code. Provide an example.
Salesforce uses Apex Unit Tests, which are class methods that check if a piece of code is working properly. Note that the unit test methods take no arguments, commit no data to the database, and send no emails.
Test methods must be defined in test classes that are annotated with @IsTest.
To deploy your Apex code, Salesforce requires that all of the following criteria is satisfied.
- At least 75% of your Apex code must be covered by unit tests, and all of these tests must be completed successfully.
- Every trigger must have some test coverage.
- All classes and triggers must compile successfully.
Here is an example of a basic structure of a test class.
@isTest
private class MyCustomObjectTestClass {
static testMethod void runPositiveTestCases() {
// Run your positive tests here
System.debug('Positive validation test...');
}
static testMethod void runNegativeTestCases() {
// Run your negative tests here
System.debug('Negative validation test...');
}
}
Q: Explain how to access archived and deleted records by using the SOQL statement?
In Salesforce, a deleted record is not actually deleted. Instead, it is moved to a recycle bin.
Every Salesforce user has access to the recycle bin, which is conceptually similar to the recycle bin in Windows or macOS. The same goes for archiving.
Therefore, if a developer building a query wants to include the deleted and archived records in its result set, [s]he can use the ALL ROWS keywords in the SOQL statement.
Here’s an example.
SELECT COUNT() FROM Contact WHERE AccountId = a.Id ALL ROWS
Q: Explain how to assure a process can update records, without the risk of other processes or users simultaneously updating the same records.
SOQL supports the FOR UPDATE keywords.
When included in the SOQL statement, they guarantee that no other process or user will be able to update the records concurrently. After the transaction handling the records is completed, the lock is released.
Q: Consider the following snippet of code:
List<Opportunity> opportunityList = [SELECT Id, Name, StageName FROM Opportunity WHERE StageName = 'Qualification'];
Explain what, if anything, is wrong with it?
The preceding code fetches all the opportunities in the Qualification stage. While the code snippet is correct, we are using the string literal directly, without a constant or a configuration.
This coding practice could become a source of problems because there may be other classes using the same approach.
For example, if we assume that we want to change the stage name from Qualification to Pending Review, this would take a certain amount of work to perform an impact analysis and incorporate the changes in the code.
This situation could have been avoided with a constant or a configuration approach, and our query will look something like this, assuming we have created a constant.
public static final String STAGE_NAME = 'Qualification';
The final query will be:
List<Opportunity> opportunityList = [SELECT Id, Name, StageName FROM Opportunity WHERE StageName = STAGE_NAME];
Q: Consider the following snippet of code:
global class FutureRecordProcessing
{
@future
public static void processRecords(List<MyObject__c> myObjectList)
{
// Process records
}
}
Why does this code generate a compilation error?
In Apex, @future annotated methods cannot get sObjects as arguments, because the sObject might change between the time you call the method and the time it actually executes. In this particular scenario, a list of sObjects IDs should be used instead to perform a query for the most up-to-date records.
Here is an example of a future method properly querying the objects from a list of IDs:
global class FutureRecordProcessing
{
@future
public static void processRecords(List<ID> recordIds)
{
// Query records
List<MyObject__c> myObjects = [SELECT Name FROM MyObject__c WHERE Id IN :recordIds];
// Process records
}
}
Take the time to find a top Salesforce developer.
The questions we covered in this article should be a piece of cake for any sufficiently experienced Salesforce developer; and therefore, should help you distinguish a wannabe Salesforce developer, who mostly uses only drag-and-drop tools, from a top-level developer, who is fluent in both SOQL and Apex.
Taking the time to find the best candidates is well worth the effort, as they will undoubtedly will have a significant impact on your team’s productivity and bottom line.
