Salesforce Developer Interview Questions: What to Actually Expect

Salesforce developer interviews test four separate things: Apex and trigger logic, Lightning Web Components, SOQL/data modeling, and platform judgment about when to build declaratively versus write code. Most candidates prep for one of these and get blindsided by the other three.

You've probably done this before: crammed on triggers the night before, walked in confident, then got asked why you'd use a Flow instead of a trigger for a given scenario and froze. That's not a knowledge gap. That's a scope gap. Salesforce interviews don't just check if you can code, they check if you understand the platform's tradeoffs, because a developer who defaults to Apex for everything is expensive to a Salesforce team, not valuable.

I've sat through and prepped candidates for enough of these to know the pattern repeats across Deloitte-style consultancies, small ISVs, and internal enterprise teams. The syntax questions matter less than you think. The judgment questions matter more than you think. Here's the actual breakdown.

What are the most common Salesforce developer interview questions?

The bulk of Salesforce developer interviews cluster into four categories: Apex fundamentals (triggers, governor limits, exception handling), Lightning Web Components (data binding, wire adapters, component communication), SOQL/SOSL and data modeling (relationships, bulkification, indexing), and platform architecture judgment (when to use Flow vs. Apex, sharing rules, integration patterns). A senior-level interview adds a fifth: system design for multi-org or high-volume scenarios.

Plain-language summary: expect a mix of "write this code" questions and "explain this tradeoff" questions. The second type trips up more candidates.

Apex interview questions you'll actually get asked

Apex questions test whether you understand the platform's constraints, not whether you memorized syntax. Interviewers care most about governor limits and bulkification because those are the mistakes that break production orgs.

• "What are governor limits and why do they exist?" Answer with the reasoning, not just the list. Salesforce is multi-tenant. One runaway query on your org can't be allowed to degrade performance for every other org on the same instance. That's why SOQL queries, DML statements, and CPU time all have hard caps per transaction.
• "Write a trigger that avoids hitting the 100 SOQL query limit." This is really asking: do you know bulkification? The wrong answer puts a query or DML statement inside a for loop. The right answer collects IDs first, queries once outside the loop, then processes the collection.
• "What's the difference between before and after triggers?" Before triggers modify the record before it saves (no extra DML needed). After triggers access system fields like Id and read related records that only exist post-save. Get the use case backwards and you look like you've never debugged a real trigger.
• "Explain trigger context variables." Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, isInsert, isUpdate, isBefore, isAfter. You should be able to name the scenario each one solves, not just recite the list.
• "How do you handle exceptions in Apex?" Try/catch blocks, custom exception classes extending Exception, and when to use Database.insert with allOrNone set to false versus a plain insert that throws on first failure. This question is really testing whether you think about partial failure in bulk operations.
• "What's the difference between a Trigger, a Process Builder/Flow, and Apex classes invoked from Flow?" This is the declarative-vs-code judgment question wearing an Apex costume. Answer it with tradeoffs: Flow is faster to build and maintain by admins, but complex branching logic and performance-sensitive bulk processing usually belong in Apex.

Plain-language summary: Apex questions are really governor-limit questions in disguise. If your answer doesn't mention bulk-safety, it's incomplete.

Lightning Web Components (LWC) questions to prepare for

LWC replaced Aura as Salesforce's standard front-end framework, and most companies hiring now expect LWC fluency, not just Visualforce or Aura experience from three years ago. Expect questions on data flow and component lifecycle more than pure JavaScript trivia.

• "How does a parent component pass data to a child component?" Public properties (@api) on the child, set as attributes in the parent's HTML. Data flows down.
• "How does a child communicate back to a parent?" Custom events, dispatched with CustomEvent and caught with an event listener in the parent markup. Data flows up through events, not direct property access.
• "What's the difference between @wire and imperative Apex calls?" @wire is reactive and cacheable, it reruns automatically when its reactive parameters change. Imperative calls (calling an Apex method directly in JavaScript) give you more control over when the call fires, useful for button clicks or conditional logic.
• "When would you use Lightning Data Service instead of calling Apex?" When you're doing simple CRUD on a single record and don't need custom server-side logic. LDS handles caching and sharing rules automatically, which means less code and fewer bugs.
• "How do you handle errors from an Apex call in LWC?" Catch the error in the .then/.catch or try/catch around the await, then surface it with a toast event (ShowToastEvent) rather than letting it fail silently.

Think of LWC's data flow like a one-way water pipe: properties flow down from parent to child, events flow up from child to parent. Water doesn't flow both directions through the same section of pipe, and neither does LWC data.

SOQL and data modeling questions

Data modeling questions reveal whether you've actually built on the platform or just watched tutorials. Interviewers use these to check if you understand relationship types and query efficiency at scale.

1. Explain the difference between a lookup relationship and a master-detail relationship. Master-detail enforces cascading delete and roll-up summary fields; lookup does not. Sharing and security also inherit differently.
2. Write a SOQL query with a subquery across a parent-child relationship. Tests whether you know relationship query syntax, not just flat SELECT statements.
3. Explain selective vs. non-selective queries and why it matters at scale. A non-selective query on a large object can time out or skip the index, which is a real production incident, not a theoretical concern.
4. When would you use SOSL instead of SOQL? When you need to search across multiple objects and fields simultaneously rather than querying one object with known filters.
5. How do you avoid hitting query row limits when processing large data volumes? Batch Apex, with defined start/execute/finish methods, chunking records instead of pulling everything into one transaction.

Plain-language summary: data questions test scale awareness. Any answer that works fine for ten records but breaks at ten thousand will get flagged.

Architecture and judgment questions senior candidates should expect

Past the mid-level, interviews shift from "can you write this" to "what would you build and why." These questions have no single correct answer, the interviewer is grading your reasoning process.

• "A client wants to automate a business process. How do you decide between Flow and Apex?" Frame it as a tradeoff table in your head: complexity, performance needs, who maintains it long-term, and whether the logic needs to run in bulk-safe, testable code.
• "How would you design an integration between Salesforce and an external system?" Talk through options: REST/SOAP callouts, Platform Events for async, middleware like MuleSoft, and when each fits based on volume and real-time requirements.
• "How do you approach testing in Salesforce?" Apex requires a minimum code coverage threshold to deploy, but the real answer is about testing meaningful paths and bulk scenarios, not just chasing a coverage number.
• "Walk me through your deployment process." Change sets, Salesforce CLI with scratch orgs, or a CI/CD pipeline with version control. If you've only used change sets, say so honestly and explain what you'd want to learn next.

How should you actually prepare for a Salesforce developer interview?

1. Rebuild one trigger from scratch, bulk-safe, without looking it up. If you can't write a bulkified trigger cold, that's your first study session, not your fifth.
2. Build one small LWC component with a parent-child event pattern. Ten minutes of hands-on work beats an hour of reading documentation.
3. Review your own past projects and prepare a two-minute walkthrough for each. Interviewers ask about real work more than they ask abstract trivia, and a hesitant answer about your own project reads worse than a wrong answer about a hypothetical.
4. Practice explaining Flow vs. Apex out loud. This judgment question shows up in nearly every interview at every level, so rehearse it until it's fluent, not memorized.
5. Check the job posting for specific mentions of MuleSoft, CPQ, or industry clouds. If the role touches integration or a specific cloud product, expect at least one question probing that surface area specifically.
6. Ask what Salesforce edition and org complexity the team runs. An enterprise org with multiple integrations asks different architecture questions than a single-org small business implementation.

Certifications: do they actually help you pass the interview?

Certifications get your resume past filters faster. They rarely change the outcome of the actual technical rounds, since interviewers know certifications can be memorized without hands-on depth.

Getting to the interview in the first place

None of this prep matters if the posting fills before you apply. Salesforce developer roles, especially contract and C2C positions, move fast once a recruiter starts collecting submissions, and the first wave of applicants gets the interview slots. GiraffyReach watches for fresh Salesforce developer postings the moment they go live and applies before the queue builds, so your interview prep actually gets used instead of wasted on a role that's already closed. Being first isn't a guarantee of an offer, but it's a precondition for a real interview.

If you're also working C2C channels for Salesforce contract roles, pair your interview prep with a look at how vendor hotlists actually work and how to get added to a preferred vendor list, since those determine which recruiters even see your profile before the interview stage. And if speed-to-apply is your bottleneck rather than interview skill, the data on first-applicant advantage is worth reading before your next submission.