Table of contents
- Preparing for a Salesforce technical interview
- SOQL and data access questions
- Apex testing questions
- Salesforce integration questions
- Deployment and version control questions
- How to practice your answers
- Key takeaways
- Sources
Salesforce technical interviews can cover much more than writing Apex. Depending on the role, you may be asked how to retrieve data, test a solution, connect Salesforce to another system, or deploy changes safely.
For administrators moving into technical roles, some of these topics may be unfamiliar. For experienced developers, the challenge is often explaining not only what a feature does, but also when and why you would use it.
The following Salesforce technical interview questions and sample answers cover four areas that are common in development work: SOQL and data access, Apex testing, integrations, and deployment. Use them to identify knowledge gaps and practice explaining concepts in your own words.
Preparing for a Salesforce technical interview
A strong technical answer should connect the feature to a practical use case. For example, rather than simply defining SOQL, explain what data you would retrieve and why a query is appropriate for the requirement.
When practicing, consider these questions:
- What problem does the feature solve?
- When would you use it?
- What limitations or risks should you consider?
- How would you test or verify the result?
The sample answers below provide a starting point. Adapt them to the role you are applying for and the projects you have worked on.
SOQL and data access questions
1. What is the difference between SOQL and SOSL?
Sample answer: “SOQL is used to query Salesforce records when I know which object and fields contain the data I need. For example, I could use SOQL to retrieve open Opportunities for a particular Account.
“SOSL is designed for text-based searches across searchable fields. I’d consider SOSL when I need to search for a term across multiple objects, such as finding a customer’s name in Accounts, Contacts, and Leads.”
SOQL can also retrieve related records through relationship queries. The choice depends on whether the requirement is primarily a structured query or a search across indexed fields.
Possible follow-up: If you know the customer’s email address but are unsure whether the person is a Lead or a Contact, which approach would you consider?
2. How do you retrieve a parent record’s fields in a SOQL query?
Sample answer: “I can use a child-to-parent relationship query and reference the parent’s fields using dot notation. For example, I could query Contacts and include the name of each Contact’s related Account.”
SELECT Id, FirstName, LastName, Account.Name
FROM Contact
This query starts with Contact and retrieves Account.Name through the existing relationship. For a custom relationship field, replace the field’s __c suffix with __r to access fields on the related record. For example, use Project__r.Name to access the name of the record referenced by Project__c.
Possible follow-up: What should your code consider if a Contact does not have a related Account?
3. How do you retrieve child records for a parent record?
Sample answer: “I can use a parent-to-child relationship query with a subquery. For example, I could retrieve Accounts and their related Contacts in one query.”
SELECT Id, Name,
(SELECT Id, FirstName, LastName FROM Contacts)
FROM Account
Here, Contacts is the child relationship name. For custom relationships, the child relationship name is defined in the relationship field’s configuration and may not be the same as the object’s API name.
Relationship queries depend on defined Salesforce relationships; they are not arbitrary SQL joins.
Possible follow-up: How would you find the correct child relationship name for a custom object?
4. When would you use an aggregate query?
Sample answer: “I’d use an aggregate query when I need a summary, such as a count, sum, or average, rather than individual records. For example, I could count Opportunities by stage.”
SELECT StageName, COUNT(Id)
FROM Opportunity
GROUP BY StageName
An aggregate query can reduce the amount of detail returned when the requirement is to calculate a summary. Consider the filter criteria and the volume of data being summarized.
Possible follow-up: How would you change the query if you needed results only for Opportunities owned by a particular user?
5. What would you consider when a SOQL query performs poorly?
Sample answer: “I’d review the query’s filters, the number of records it returns, and the volume of data in the object. I’d use the Query Plan tool where applicable to examine how Salesforce may execute the query and whether the filters are selective.
“I’d also check whether the application requests more fields or records than it needs, and whether the same query runs repeatedly during a transaction.”
A query that performs well in a small sandbox may behave differently in a production org with significantly more data. Test with representative data volumes where possible.
Possible follow-up: Why might adding a filter not automatically make a query selective?
Apex testing questions
6. What makes an Apex test effective beyond code coverage?
Sample answer: “An effective Apex test verifies that the application behaves as expected. It creates the required test data, runs the operation, and uses assertions to check the result.
“I’d cover successful outcomes, relevant failure conditions, and edge cases. For automation that processes collections, I’d also test with multiple records.”
Code coverage shows which lines were executed. It does not, by itself, prove that the code produced the correct result or handled an error appropriately.
Possible follow-up: What assertion would you add to verify that a record was not changed when it did not meet the business criteria?
7. Why should Apex tests create their own test data?
Sample answer: “Creating test data makes tests more reliable and easier to understand. A test should establish the records and conditions it needs instead of depending on business data that may differ between environments.
“I’d create the required records in the test or use a shared test-data setup where it improves clarity and avoids unnecessary duplication.”
Self-contained test data also makes it easier to identify why a test failed. The setup should reflect the conditions the test intends to verify without creating unrelated records.
Possible follow-up: What would you check if a test that creates its own data passes in one sandbox but fails in another because a record cannot be inserted?
8. What are Test.startTest() and Test.stopTest() used for?
Sample answer: “I use Test.startTest() to mark the beginning of the portion of the test focused on the operation I want to exercise. It gives that portion a separate set of governor limits from the setup performed before it.
“Test.stopTest() ends that portion. It also causes supported asynchronous work queued during the test to execute so I can verify its results.”
For example, a test might create its data first, enqueue a Queueable job between these methods, and then assert the expected outcome after Test.stopTest().
Possible follow-up: Why should you still use assertions after Test.stopTest() instead of assuming that the job succeeded because the test completed?
9. How would you test an expected failure?
Sample answer: “I’d create the conditions that should cause the failure, run the operation, and verify the expected result. If the code is expected to throw an exception, I’d check that the correct exception occurs and, where useful, that its message or other details are appropriate.
“I’d also verify that the operation did not make changes it should have prevented.”
A useful negative test verifies the intended failure, rather than passing merely because some exception occurred.
Possible follow-up: How would you test a partial-success operation where some records succeed and others fail?
Salesforce integration questions
10. How can Apex call an external API?
Sample answer: “Apex can make an HTTP callout to an external API using classes such as HttpRequest, Http, and HttpResponse. I’d configure the request method, endpoint, and any required headers or body, then process the response.
“For an authenticated service, I’d use a Named Credential and the associated authentication configuration where appropriate. I’d also handle unsuccessful responses, timeouts, and other errors.”
A complete answer should consider what the application needs to do when the external system is unavailable, not just how to send a successful request.
Possible follow-up: If a callout fails after Salesforce has accepted a user’s request, how should the user or support team learn about the failure?
11. What is a Named Credential, and why would you use one?
Sample answer: “A Named Credential provides a reusable configuration for an external callout endpoint and works with authentication configuration for the external service. Apex can reference the Named Credential rather than hardcoding the endpoint and authentication details in the code.
“This makes the integration easier to maintain and helps keep connection details separate from business logic.”
When explaining authentication, also consider who is permitted to use the configured external credential and whether the service uses a shared identity or a user-specific identity.
Possible follow-up: What configuration might need to be checked if the callout works for an administrator but fails for another user?
12. How do you test an Apex HTTP callout?
Sample answer: “I’d use an HttpCalloutMock implementation to simulate the external service’s response. In the test, I’d register the mock and then run the code that makes the callout.
“I’d verify how the application handles a successful response and relevant failure responses, such as an error status or an unexpected response body.”
The mock makes the test independent of the availability and behavior of the external service. It should return a response representative of the scenario the test is intended to cover.
Possible follow-up: What would you assert if the external service returns a success status but the response body is missing a required value?
13. When might you use asynchronous Apex for an integration?
Sample answer: “I’d consider asynchronous Apex when the work does not need to complete before the user receives an immediate response, or when it needs to run outside the original transaction.
“For example, a user could submit a request in Salesforce, and a Queueable Apex job could send the data to an external service. I’d also plan how to track the job, handle failures, and avoid creating duplicate transactions if a request is retried.”
Asynchronous processing changes the user experience: a successful submission does not necessarily mean the external system has completed the request.
Possible follow-up: How would you prevent a retry from creating the same order twice in the external system?
Deployment and version control questions
14. What would you check before deploying a Salesforce change?
Sample answer: “I’d identify the components and dependencies included in the release, review the changes, and verify that they have been tested in an appropriate environment.
“I’d also consider target-org configuration, required access, test results, deployment timing, and any steps that must happen before or after deployment. Where appropriate, I’d validate the deployment before the release.”
Depending on the change, post-deployment work might include assigning permissions, activating automation, configuring integration access, or verifying that the solution works for intended users.
A validation can check whether a deployment would succeed without committing the changes to the target org.
Possible follow-up: If the deployment succeeds but users cannot access a new component, what would you check first?
15. Why is version control useful for Salesforce development?
Sample answer: “Version control provides a history of changes and helps a team collaborate on the same code and metadata. Developers can work on changes separately, review proposed changes, and understand when and why a change was made.
“It also supports release processes by helping the team identify which changes are included in a deployment.”
A repository is most useful when the team follows a consistent process for retrieving, reviewing, merging, and deploying changes.
Possible follow-up: How would you handle a situation where two developers modify the same Apex class?
16. How would you investigate a deployment that fails because of an Apex test?
Sample answer: “I’d start with the deployment result and identify the failing test, exception, and assertion message. Then I’d determine whether the failure is caused by the new change, test data assumptions, missing dependencies, or a difference in target-org configuration.
“I’d reproduce the issue in a suitable environment and fix the underlying cause. I wouldn’t remove assertions or change the test solely to make the deployment pass.”
A deployment test can reveal an issue in existing functionality affected by the change, so review the interaction between the release and the failing code.
Possible follow-up: What would you investigate if the failing test belongs to a feature that was not intentionally included in the release?
17. What is the difference between deployment validation and deployment?
Sample answer: “A deployment validation checks the proposed deployment and runs the applicable tests without committing the changes to the target org. An actual deployment applies the changes if the deployment succeeds.
“Where the requirements are met, a successful validation can also support a subsequent quick deployment.”
Validation reduces uncertainty before a release, but the team should still plan post-deployment checks for user access, configuration, and business behavior.
Possible follow-up: Why might a successful validation not be enough to prove that an integration will work after release?
How to practice your answers
Reading sample answers can help you identify the concepts to study, but a technical interview often includes follow-up questions. Practice explaining each answer aloud and connecting it to a real or practice project.
For example, build a small application that retrieves related records, includes an Apex test, and calls a mocked external service. Then explain the decisions you made, how you tested the behavior, and what you would change if the data volume or requirements increased.
If you are preparing for scenario-based questions as well, read How to Answer Tricky Salesforce Developer Interview Questions. It covers how to discuss requirements, trade-offs, security, automation, and testing during an interview.
For structured development training, explore K2U’s Modern Salesforce Development course and Object-Oriented Programming in Apex course. You can also use the Platform Developer certification resources to identify areas where you need more practice.
Key takeaways
- Choose SOQL or SOSL based on how the data needs to be retrieved or searched.
- Explain how relationship queries and aggregate queries solve specific data requirements.
- Write Apex tests that assert expected behavior, including relevant failure conditions.
- Consider authentication, error handling, and testing when discussing integrations.
- Include dependencies, validation, user access, and post-deployment checks in your release plan.
- Practice follow-up questions so you can explain your reasoning instead of relying on memorized answers.
Sources
- Salesforce Developers: Introduction to SOQL and SOSL
- Salesforce Developers: Relationship Queries
- Salesforce Developers: Named Credentials
- Salesforce Developers: Test Credentials in the Target Org
- Salesforce Developers: Validate a Deployment with Salesforce CLI
- Salesforce Developers: Test the Release Artifact in a Staging Environment