Salesforce developer interviews are a bit unusual compared to standard software engineering interviews. There’s less algorithmic coding and more platform-specific knowledge. You can’t brute-force your way through with generic computer science fundamentals. You need to know the platform.
I’ve been going through interview prep resources for Salesforce devs and there’s a lot of content that lists questions without explaining what the interviewer is actually checking for. That’s what I want to fix here.
This covers the five technical areas that come up most consistently, with the specific questions and (more importantly) what a good answer sounds like.
1. Apex fundamentals
Q: What’s the difference between a List, Set, and Map in Apex?
This is usually an early filter question. Not because List vs Set vs Map is complicated, but because candidates who haven’t actually written Apex recently will hesitate or conflate them.
The short version: List is ordered and allows duplicates. Set is unordered with no duplicates. Map is key-value pairs. The follow-up they often ask: “When would you use a Map over a Set in a trigger?” Answer: when you need to look up a record by ID during processing, a Map
Q: How do you handle governor limits?
This is a real question, not a trivia question. Governor limits are why Apex code fails in production when it looked fine in developer org. The answer they want isn’t a recitation of limits (150 SOQL queries per transaction, 100 DML statements, etc.). The answer they want is a pattern: how do you write code that stays within limits as data volume grows?
The patterns that matter:
- Bulkify everything. Your trigger should handle 200 records as easily as it handles 1.
- SOQL queries go outside loops. Always. No exceptions.
- Use collections to batch DML operations instead of inserting one record at a time.
- Know when to use @future, Queueable, or Batch Apex for async processing.
Q: What’s the difference between @future and Queueable Apex?
Both run asynchronously. @future is simpler but limited: it can’t be chained, it can’t take sObject parameters directly (has to be primitive types or collections of primitives), and you can’t monitor its progress. Queueable is more flexible: you can chain jobs, pass complex types, and track execution. If someone asks this, they’re trying to find out whether you reach for @future out of habit or whether you understand when to use each.
2. Lightning Web Components
Q: What’s the LWC component lifecycle?
The hooks in order: constructor(), connectedCallback(), renderedCallback(), disconnectedCallback(). The common mistake is overloading connectedCallback() with logic that should be in the constructor or in a wire function. The interviewer is checking whether you understand the difference between when a component connects to the DOM versus when it first renders.
Q: How do you pass data between sibling components?
This trips people up because the instinct is to look for a direct sibling-to-sibling mechanism. There isn’t one in LWC. The answer is to fire an event from the child component up to the parent, then pass data down to the other sibling via a property. If the siblings are far apart in the component tree, a Lightning Message Service channel is the right answer.
One thing I find people often miss: the @wire decorator isn’t just for calling Apex. You can use it to subscribe to Lightning Message Service, which makes it relevant in the sibling communication question.
3. SOQL and query performance
Q: What’s the difference between SOQL and SOSL?
SOQL queries one object at a time (or related objects via relationship queries). SOSL searches across multiple objects simultaneously using text search. Use SOQL when you know which object you’re querying and have a field to filter on. Use SOSL when you’re building a search feature and need to find a value across multiple objects at once.
Q: How do you optimize a slow SOQL query?
The list they’re expecting:
- Add a WHERE clause that filters on an indexed field. Standard fields (Id, Name, CreatedDate, OwnerId) are indexed by default. Custom fields need to be explicitly indexed.
- Avoid SELECT *. Query only the fields you need.
- Use LIMIT when you don’t need all records.
- For large data volumes, look at custom indexes or filter on a formula field that’s deterministic.
The answer that actually impresses interviewers is when you can describe using Query Plan in Developer Console to diagnose why a query is slow. Most candidates know the list. Fewer know how to diagnose.
4. Triggers and automation
Q: When should you use a trigger versus a Flow?
The rule most experienced Salesforce architects follow: declarative first. Flows (and before that, Process Builder and Workflow Rules) cover a large percentage of automation use cases without any code. Triggers are for when you need complex logic that declarative tools can’t handle, for cross-object logic beyond what’s supported natively, or for performance-sensitive operations where a single Apex transaction is faster than multiple flow executions.
Red flag answers: “I always use triggers” or “I use whatever I’m more comfortable with.” The interviewer wants to see that you default to the platform’s built-in tools and only reach for code when necessary. This matters a lot in Salesforce org maintenance, where a mix of Flows and triggers at least gives you some declarative visibility.
Q: What are trigger best practices?
The list that matters: one trigger per object (two triggers on the same object with conflicting order can cause subtle bugs), handler class pattern to keep logic out of the trigger file itself, bulkification throughout, avoid recursion with a static boolean flag or a trigger handler framework that handles it for you.
According to Salesforce’s own Trailhead documentation, one trigger per object with a handler class is explicitly recommended as the standard pattern. Citing this shows you’re reading primary sources, not just blog summaries.
5. Integrations and APIs
Q: What’s the difference between REST and SOAP APIs in the Salesforce context?
REST is lighter, uses JSON, and is generally preferred for most integrations today because it’s easier to work with across languages and frameworks. SOAP uses XML and is more verbose, but it’s still used in legacy integrations and in situations where WSDL-based contract definitions matter to the integration partner.
The follow-up: “How do you handle callout errors in an Apex class?” The answer they want: try-catch with HttpResponse status code checks, custom exception handling, and logging to a custom object rather than just swallowing errors. Mention that callouts can’t be made from a trigger context synchronously (they have to be async), because that’s the constraint that usually surprises junior developers.
Q: How do you secure an integration endpoint?
OAuth 2.0 for user-context integrations, JWT bearer token for server-to-server. Named Credentials in Salesforce to avoid storing API keys or passwords in Apex code or custom settings that anyone with admin access can read. Salesforce’s REST API documentation covers the Connected App OAuth flows, and knowing this material shows you understand why the authentication patterns exist, not just how to implement them.
Preparing with Craqly
Salesforce developer interviews tend to be more conversational than whiteboard-style. The interviewer is often another Salesforce developer or architect who wants to explore how you think about problems, not just check whether you’ve memorized the governor limit numbers.
Craqly’s interview practice mode lets you run through technical questions and get feedback on your answers, which is useful for building the habit of explaining your reasoning out loud rather than just arriving at the right answer. In a Salesforce interview especially, the architectural thinking matters as much as the technical recall.
Most importantly: if there’s a concept you’re fuzzy on, say so and describe what you’d do to verify. Interviewers generally respect “I’d check the documentation on that to confirm the exact behavior” more than a confident wrong answer. The platform has too many edge cases for anyone to have them all memorized.