25 SFDC developer interview questions with a role-calibrated rubric for junior, mid-level, and senior answers — plus the topics to study first, the traps.
Most lists of sfdc developer interview questions look the same: forty bullet points, no order, no context, no indication of whether you're supposed to know this on day one or after three years in production orgs. The real problem isn't finding more questions — it's knowing which ones matter at your level and what a strong answer actually sounds like when someone who has shipped Salesforce code is sitting across from you.
The gap between a candidate who passes and one who doesn't usually isn't knowledge. It's calibration. A mid-level interviewer doesn't want a definition. They want to hear you name a tradeoff, describe what broke, and explain what you changed. That's a different kind of preparation than flashcard drilling, and this guide is structured around it.
What follows covers 25 questions grouped by topic and difficulty, with explicit guidance on what junior, mid-level, and senior answers look like — so you can study in the right order and walk in knowing what the interviewer is actually listening for.
What Salesforce Developer Interviewers Are Actually Checking For
Which level are they really interviewing for?
The same question does three different jobs depending on where you are in the hiring funnel. "Tell me about a trigger you've built" is a screening checkbox at junior level — the interviewer just wants to confirm you've written one. At mid-level, it becomes a tradeoff question: did you bulkify it, did you separate handler logic, did you think about order of execution? At senior level, it's an architecture probe: where does trigger logic belong versus Flow, how does this interact with the rest of the automation stack, and what would you change if the org tripled in size?
Candidates who don't understand this calibration give the same answer at every level. A junior answer to a senior question sounds like vocabulary without judgment. A senior answer to a junior screening question sounds like someone who doesn't know when to stop. Both fail.
The answer they trust is the one tied to a real org
Generic definitions collapse fast under follow-up. If you say "master-detail creates a tight parent-child relationship," the next question is always "when would that choice create a problem for you?" An interviewer who has worked in a real org knows the answer involves sharing behavior, rollup summary field limitations, and what happens to child records on deletion. If your answer sounds like the Salesforce help article, you're one follow-up away from silence.
The scenario that separates candidates is the one with operational texture: "we had three sandboxes, a broken deployment path, and a partial copy that didn't have the integration credentials we needed." That kind of detail signals that you've actually shipped something, not that you've read about shipping.
What a hiring manager hears when you sound experienced
Experienced answers have three things in common: they name a constraint, they acknowledge a tradeoff, and they describe how you verified the decision in a real org. "I used a queueable job because the callout limit in a future method would have been a problem at scale, and we confirmed it in a developer sandbox before moving to partial copy" is a sentence that lands. "I used a queueable job because it's more flexible" is a sentence that gets you a polite nod and a mental minus.
Hiring managers running screening rounds consistently report that the questions that separate candidates most reliably are the ones about recursion, bulkification, security enforcement, and deployment strategy — topics where a wrong answer in production costs real time. According to Salesforce's own developer documentation, these are also the areas where platform behavior is most nuanced and most often misunderstood.
Start With the Table Stakes Nobody Should Miss
These Salesforce technical interview questions appear in nearly every screening round. Getting them wrong doesn't just cost you points — it signals that you haven't done the work.
What are the object relationships you have to explain without thinking?
1. What's the difference between a lookup relationship and a master-detail relationship? A lookup is a loose association — the child can exist independently, and the parent field is optional. A master-detail is a tight dependency: the child requires a parent, inherits its sharing and security settings, and is deleted when the parent is deleted. The follow-up that exposes real experience is about rollup summary fields, which only work on master-detail, and about what happens when you need a rollup but can't afford the deletion cascade. That's where junction objects and cross-object formulas enter the conversation.
2. When do you use a junction object, and what does it actually solve? A junction object creates a many-to-many relationship between two objects by sitting between them with two master-detail relationships. The textbook answer covers the structure. The experienced answer covers why you'd choose it over a lookup-based approach: rollup summaries, sharing inheritance, and the fact that the junction record carries its own data — status, date, notes — that belongs to the relationship itself, not to either parent.
3. What's a self-relationship, and when would you actually use one? A self-relationship links a record back to another record of the same object — the classic example is an Account hierarchy where a child account rolls up to a parent account. Interviewers ask this less often, but it comes up in org design discussions and it's a quick signal of whether you've worked in complex data models.
Which sandbox type would you choose for this change?
4. Walk me through sandbox types and when each one matters. Developer sandboxes are fast to create and fine for unit testing, but they have no production data and a small storage limit. Developer Pro gives you more storage but still no real data shape. Partial Copy gives you a sample of production data — useful when your logic depends on data volume or record relationships that don't exist in a clean developer org. Full sandbox mirrors production completely and is essential for load testing and integration validation, but it takes longer to refresh and costs more.
The question that exposes real experience is: "why would you choose Partial Copy over Full for a regression test?" The answer is usually time and cost — Full refreshes can take days, and Partial Copy is often good enough when you need realistic data shapes but not full volume.
5. What happens when your sandbox doesn't have the integration credentials you need? This is the scenario that breaks deployments. Named credentials, remote site settings, and connected app configurations don't always carry over cleanly. A strong answer describes how you handle environment-specific configuration — custom metadata types that hold environment-aware values, or a post-refresh checklist that includes credential validation before any test run begins.
When do you reach for Flow instead of Apex?
6. How do you decide between Flow and Apex for a new automation requirement? The slogan answer is "use Flow when you can, Apex when you must." The practical answer is more specific. Flow is the right call when the logic is declarative, the admin team needs to maintain it without a developer, and the complexity doesn't require collection manipulation or complex branching. Apex is the right call when you need precise governor limit control, complex data transformations, or integration callouts that Flow can't handle cleanly.
The tradeoff that actually matters in interviews: Flow is faster to build and easier for admins to read, but it becomes brittle when requirements keep changing and the logic grows beyond what the visual builder was designed for. If you're building something you know will need three more conditions in six months, Apex with a test suite is often the more maintainable choice — even if it takes longer today. Salesforce's automation documentation explicitly addresses this tradeoff in its guidance on when to use each tool.
Junior, Mid-Level, and Senior Answers Are Not the Same Thing
These Salesforce Apex interview questions illustrate how the same topic sounds different depending on experience level.
What does a junior answer sound like?
7. Explain what an Apex trigger is. A junior answer covers the mechanics correctly: a trigger fires before or after a DML event on a specific object, it has access to Trigger.new and Trigger.old, and it can run in before or after context depending on when you need to act. That's a passing answer at the screening level. It proves vocabulary. It doesn't prove judgment.
What changes at mid-level?
8. Tell me about a trigger you've built that had to handle bulk updates. The mid-level version of this answer starts with the constraint: triggers fire on up to 200 records at a time in a single transaction, and if you write logic that queries or DMLs inside a loop, you'll hit governor limits fast. A strong mid-level answer describes the collection pattern — build a map of record IDs to values outside the loop, process the collection, then do a single DML call — and names a real scenario where they caught a single-record assumption before it went to production.
What does senior sound like without turning into jargon?
9. How do you decide whether logic belongs in a trigger, a Flow, or both? The senior answer connects platform mechanics to team risk. Triggers give you control and testability. Flow gives you admin accessibility and faster iteration. Splitting logic across both creates maintenance complexity that costs you when the developer who built it leaves. A senior answer names the org-specific factors — team composition, admin capability, technical debt tolerance — and describes how they made that call on a real project, including what they'd change in retrospect.
Apex and Triggers Are Where Interviews Stop Being Polite
How do you explain bulkification without sounding scripted?
10. What is bulkification and why does it matter? The trap answer is "you should use collections instead of single records." The real answer names the governor limit that breaks: 100 SOQL queries per transaction. If you query inside a loop and someone runs a data import of 500 records, you'll hit the limit at record 101 and the whole transaction fails. The strong answer describes the map pattern, explains why it works, and names the production bug it prevented — a batch import that worked fine in a developer sandbox with test data and exploded on the first real data migration.
11. How do you write a trigger that won't break under load? One handler class, called from a single trigger per object, with all logic in methods that accept collections. No SOQL or DML inside loops. Assertions in tests that cover 200-record scenarios, not just single records. The interviewer is listening for whether you've actually written a trigger that survived a data load, not whether you can recite the pattern.
How do you stop trigger recursion before it becomes a mess?
12. What causes trigger recursion and how do you prevent it? Recursion happens when a trigger fires, updates a record, and that update fires the trigger again. The classic production scenario is an after-update trigger that sets a field, which triggers another after-update, which sets another field, until you hit the recursion limit. The standard prevention is a static Boolean flag in a handler class — set it to true on first entry, check it at the top of every trigger invocation. The more robust solution is a trigger framework that manages execution context explicitly, which also makes the logic easier to test and maintain.
13. What happens when a downstream automation change breaks your recursion guard? This is the question that separates people who've been in a real org from people who've read about it. The scenario: your static flag prevents your trigger from re-entering, but a Flow added by an admin fires on the same object and causes an update your trigger wasn't expecting. Now your flag is set but the Flow is still running. A strong answer describes how you audit the full automation stack on an object before assuming your recursion guard is sufficient.
What do you do when the interviewer asks you to whiteboard a trigger?
14. Walk me through how you'd write a trigger for this requirement. Talk through order of execution first — validation rules, before triggers, system validation, after triggers, workflow, processes — so the interviewer knows you understand where your code runs. Then describe handler separation: the trigger file should be thin, delegating to a handler class immediately. Write test methods that cover bulk scenarios, negative cases, and the specific business logic you're implementing. The interviewer is watching whether you can reason out loud under pressure, not whether you produce perfect syntax.
Async Apex Is Where Good Answers Get Specific Fast
These Salesforce developer interview questions are where mid-level candidates most often lose ground to seniors who can name the right tool for the right job.
15. When do you use a future method versus a queueable job? Future methods are simple and work for callouts and small async operations, but they can't be chained, can't pass complex objects, and can't be monitored easily. Queueable jobs fix all three: you can chain them, pass complex state, and monitor them in the Apex Jobs queue. Use future when the operation is simple and one-shot. Use queueable when you need sequencing, complex data, or visibility into what's running.
16. When does a batch class make more sense than a queueable? Batch is built for large data volumes — it processes records in chunks of up to 200, handles its own transaction boundaries, and gives you start, execute, and finish methods for setup and cleanup. Use it for nightly data cleanup, large-scale recalculation, or any operation that needs to touch more records than a single transaction can handle. The follow-up question is usually about chaining batches, which requires care because you can only have five batch jobs queued at once.
17. How do you test a batch class so the test actually proves something? Shallow coverage passes the coverage threshold but doesn't validate behavior. A meaningful batch test inserts test records with specific values, runs the batch inside Test.startTest() and Test.stopTest(), and then queries the database to assert that the right records changed for the right reason. The test should fail if the batch logic is wrong — not just if it throws an exception.
18. What's the governor limit that catches people most often in async Apex? The callout limit in a single transaction is 100 HTTP callouts. Future methods allow callouts but can't be chained, so if you need to make more than 100 callouts in sequence, you need a queueable that re-enqueues itself or a batch class with callout support enabled. The interviewer is listening for whether you've actually hit this limit or designed around it, not whether you can recite the number. Salesforce's governor limits documentation is the canonical reference here.
Modern Salesforce Interviews Are Asking About the Parts Older Lists Skipped
These Salesforce coding interview questions reflect what's actually on the board in 2024 panel rounds — topics that flat question lists from three years ago don't cover.
What should you say about Lightning Web Components communication?
19. How do parent and child LWC components communicate? Parent-to-child: pass data via public properties decorated with @api. Child-to-parent: fire a custom event with CustomEvent and handle it in the parent template. For sibling communication or cross-component messaging without a shared parent, use the Lightning Message Service. The follow-up that exposes real experience: "what happens when you use @api on a property and mutate it directly in the child?" The answer is that LWC enforces one-way data flow — mutating an @api property directly throws a warning and can cause unpredictable behavior. You dispatch an event and let the parent update the data.
20. How do you handle security enforcement in Apex without hand-waving? CRUD and FLS enforcement means checking whether the running user has permission to read, create, edit, or delete the object and fields your code touches. In Apex, you do this with Schema.sObjectType and Schema.sObjectField describe calls, or by using WITH SECURITY_ENFORCED in SOQL. With sharing versus without sharing controls whether your class respects the running user's sharing rules. The production scenario that makes this concrete: a record-edit screen that called a service class marked without sharing, which allowed a community user to read records they weren't supposed to see. Fixing it required auditing every Apex class in the callstack, not just the one that surfaced the bug.
21. Why do Salesforce DX and scratch orgs matter in interviews now? Because source-driven development is how modern Salesforce teams work. Scratch orgs are disposable, version-controlled environments that can be spun up from a project definition file — which means every developer on the team is working from the same baseline, not from a shared sandbox that someone modified last Tuesday. Interviewers ask about this because it signals whether you've worked on a team with a real CI/CD pipeline or whether you've only used change sets. The answer that lands describes a branch strategy, a scratch org per feature, and a packaging or deployment pipeline that made the release process reproducible.
Integration and Deployment Questions Separate Builders From Button-Clickers
These Salesforce technical interview questions are where candidates who have only worked in simple orgs get exposed.
22. How do you explain an integration you've built without making it sound imaginary? Name the system, the auth pattern, and the failure scenario. "We integrated Salesforce with an ERP via REST, using named credentials for OAuth 2.0 client credentials flow. The downstream system had a 30-second timeout on heavy queries, so we moved the callout to a queueable job and added retry logic with exponential backoff." That's a real integration. "We connected Salesforce to an external system using APIs" is not.
23. What's the right answer on deployment strategy when the interviewer asks about change sets? Change sets work, but they're manual, error-prone, and don't version-control your metadata. Source-driven deployment with Salesforce CLI, connected to a Git repository and a CI/CD pipeline, gives you reproducibility, rollback capability, and team visibility. The honest answer acknowledges that many orgs still use change sets for legacy reasons, and that the transition to source-driven development requires buy-in that doesn't always come easily — but that it's the direction the platform is moving, and DevOps Center is the Salesforce-native tool that bridges the gap.
24. Where do platform events and Change Data Capture fit in an integration architecture? Platform events are Salesforce's publish-subscribe messaging system — you publish an event from Apex or a Flow, and subscribers (inside or outside Salesforce) react asynchronously. Change Data Capture streams record changes to external systems in near real-time without polling. The architectural reason to choose one over the other: platform events are for triggering business processes, Change Data Capture is for keeping external systems in sync with Salesforce data. Conflating them in an interview answer is a red flag that you've read about both but haven't had to choose between them.
The Mistakes That Make Solid Candidates Sound Junior
Why do memorized definitions backfire so badly?
25. What's the most common reason a technically correct answer still loses points? It has no application. "A lookup relationship is a loose association between two objects" is correct and useless. The interviewer who asks about relationships is waiting to hear what happens to sharing, what happens to rollup summaries, and what you do when the requirement changes after the object is already in production with data. The candidate who answers with the definition and stops is signaling that they know what a thing is called, not that they've had to make a decision about it.
Why do weak answers avoid tradeoffs?
The habit of listing tools without choosing one reads as inexperience, not humility. When an interviewer asks whether you'd use Flow or Apex for a given requirement, "it depends" is the beginning of an answer, not the answer. What it depends on — team skill, maintenance ownership, complexity trajectory, governor limit exposure — is the answer. Candidates who avoid choosing signal that they haven't had to own the consequences of a technical decision.
What makes a good answer sound fake?
The too-smooth project story with no constraints, no failure, and no verification step. Real Salesforce work involves sandboxes that don't match production, metadata conflicts on deployment day, and governor limits that only appear under real data volumes. An interviewer who has shipped code in a real org will notice when a project story has no friction. The version that lands is the one where something went wrong, you figured out why, and you changed your approach — not the one where everything worked on the first try.
How Verve AI Can Help You Prepare for Your Salesforce Developer Job Interview
The structural problem this guide keeps returning to is that knowing the right answer and being able to deliver it under live pressure are two different skills. You can read every section above and still freeze when the interviewer follows up on exactly the part you glossed over — because recalling a concept and reconstructing a coherent project narrative in real time are not the same thing.
That's the gap Verve AI Interview Copilot is built for. It listens in real-time to the actual conversation, reads what's happening on screen, and surfaces relevant context and answer prompts as the interview unfolds — not based on a canned script, but based on what the interviewer actually just said. For Salesforce developer interviews, where a question about triggers can pivot instantly into a recursion scenario or a governor limit edge case, that kind of live responsiveness is the difference between a practiced answer and a confident one.
Verve AI Interview Copilot stays invisible while it works — the desktop app operates at the OS level and doesn't appear in screen shares. You can run a full mock session, get feedback on whether your async Apex answer named the right tradeoff, and iterate on your project story until it has the operational texture that makes an interviewer trust it. The specific capability that changes the calculus for Salesforce candidates: Verve AI Interview Copilot can respond to follow-up questions dynamically, which means you're not just rehearsing a script — you're practicing the actual back-and-forth that exposes gaps in live interviews.
Conclusion
The promise here wasn't more questions. It was the right questions in the right order, with enough context to know what a strong answer actually sounds like when you're sitting across from someone who has worked in real Salesforce orgs.
Start with the table stakes: object relationships, sandbox types, and the Flow versus Apex decision. Get those clean first, because no amount of async Apex sophistication covers for fumbling a master-detail question in a screening round. Then move to triggers and bulkification — the questions where interviews stop being polite — and make sure your answers name a constraint and a real scenario, not just a pattern.
Once the fundamentals are solid, rehearse one project story at three levels of depth: the junior version that proves you did the work, the mid-level version that names the tradeoff you faced, and the senior version that connects the decision to team risk and architecture judgment. That range is what the best Salesforce developer candidates bring into every round — and it's what separates the ones who get offers from the ones who get polite rejections.
James Miller
Career Coach
