Salesforce Developer Interview Questions 2026: What to Actually Ask

Salesforce Developer Interview Questions 2026: What to Actually Ask

Last updated: April 23, 2026

Strong Salesforce developer interview questions in 2026 test Apex bulkification under governor limits, LWC component architecture, integration design tradeoffs, and Agentforce deployment judgment, not syntax recall or declarative configuration basics that a Salesforce admin can already demonstrate. The question banks circulating online were written for candidates studying to pass interviews, not for hiring managers trying to find developers who ship production-quality code. There is a meaningful difference between the two audiences. Most interview loops are optimized for the wrong one.

The most common failure on the Salesforce desk at KORE1 looks like this. Client runs a technically sound-seeming interview loop. Hires someone who answered every question confidently. Calls back six months later because the developer is building solutions that work at 50 records and fall apart at 5,000. The answers were memorized. The production instinct was not there. I’m Gregg Flecke. I place Salesforce developers through our IT staffing practice at KORE1, and I’ve been in enough client interview loops to catalog where the process breaks. What follows is the version I’d run if it were my hire.

One disclosure upfront: KORE1 earns a fee when you hire a Salesforce developer through us. Read this anyway. Most of what’s below applies whether you call us or not. And if the screening framework starts to feel like more work than your team has bandwidth for, we have a Salesforce developer staffing practice built for exactly this kind of search.

Why the Standard Question Banks Don’t Filter Real Talent

Here is what a candidate does to prepare for a 2026 Salesforce developer interview. They search “Salesforce developer interview questions.” They find a list of 30 to 105 questions with model answers. They study for a few days. They arrive knowing how to define governor limits, recite the trigger execution order, explain SOQL versus SOSL, and name the three LWC decorators. Every answer comes from the same three or four sites. Every panel member can access those same sites. The interview becomes a recitation contest. Filters nobody.

It doesn’t screen anyone out. Not the way you need it to.

Between 2021 and 2024, the Trailhead-to-certification pipeline trained a lot of junior Salesforce talent. Trailhead is genuinely good at getting someone to admin-plus capability. Production pressure is different. The batch job that fails at 3am because someone miscalculated heap size. The trigger that passes cleanly in sandbox and throws a governor limit exception at go-live when the client imports 80,000 records. The integration that handled clean test data fine and started failing a month later when the external API changed its response schema without notice. Those experiences separate candidates. Trailhead doesn’t teach you to survive them. Nothing does.

Those are the candidates you want. The interview has to be hard enough to find them.

A time allocation I’d recommend for a 2026 Salesforce developer loop:

The Apex block gets the most time on purpose. It is where production-experienced developers separate from Trailhead-certified ones fastest. The integration block gets more time than most panels allocate because integration failures are the most expensive Salesforce production incident category I see. The callout timeout question alone, properly followed up, will tell you more about a candidate’s production exposure than anything else in this interview framework. Candidates who are strong on integration tend to be solid across every other block. The ones who fall apart on integration questions usually have gaps in production exposure they haven’t disclosed.

Apex and Governor Limit Questions That Reveal Production Depth

Skip “what are governor limits.” Everyone has that memorized. The questions that matter require applying the limits under pressure.

Question 1: “A trigger on the Account object fires on update. It queries a related object inside a for loop, then performs a DML operation inside the same loop. Walk me through what’s wrong and fix it.”

What to listen for: do they immediately identify the SOQL-in-a-loop and DML-in-a-loop problems without prompting? Salesforce enforces 100 SOQL queries and 150 DML statements per transaction, limits that loop-based operations hit quickly at volume. The correct fix involves collecting IDs, moving the query and DML outside the loop, and processing collections. Candidates who describe the fix in abstract terms without naming the specific limits are usually working from memorized process. Not experience.

The follow-up worth asking: do they mention the Trigger.new context and explain the difference between a trigger firing on one record versus 200 records in a data load? The 200-record number matters. It is the default batch size for most Salesforce data operations, and it is the threshold at which naive trigger code starts failing in ways that sandbox testing with five manually entered records never revealed. A developer who has processed real data loads knows that number. One who has only worked in clean sandbox environments usually doesn’t bring it up unprompted.

Question 2: “Your batch Apex job processes 10 million records. Halfway through the run, a batch fails. What happens to the already-processed records, and what does the developer need to build to handle partial failure?”

An operational question dressed as a technical one. The right answer involves the Stateful interface for tracking progress across batch executions, error collection in the finish method, and a specific strategy for identifying and re-running failed batches without reprocessing the records that were already handled correctly in earlier chunks. Weaker candidates describe the batch interface structure but haven’t thought through failure recovery. Senior developers usually have a war story. A misconfigured scope size that caused memory pressure. A batch that ran fourteen hours before hitting execution time limits. Something specific and unpleasant. If they have five-plus years on the platform and no production batch story, probe further.

Question 3: “Explain the order of execution in Salesforce when a record is saved. Then tell me about a time the ordering caused a real problem on a project.”

The first part is on every question bank. The second part is what matters. Memorable. Production developers have been burned by the ordering at least once. Usually it’s a Flow firing after a trigger in a sequence that produced unexpected data, something that worked fine in isolation but only broke when the timing lined up during an import run or a system operation they didn’t anticipate. You trace those back for a long time. They stick. Candidates who recite the order correctly but go blank on the follow-up are often working from documentation, not memory of a real incident.

Question 4: “You have a requirement to fire logic when an Opportunity closes won. You can build it as an Apex trigger, a Flow, or a combination. Walk me through the decision.”

This is the declarative-or-programmatic question every strong Salesforce interview needs. The right answer is almost never automatic. The questions that matter: how complex is the logic, and does it need unit-testable coverage for a release gate? Is there a parallel process in the org that fires at the same time and could produce a race condition? How often will this requirement change? Code requires a full deployment cycle; Flow can be edited and activated without one. What does the failure behavior look like if something goes wrong at 11pm on a Saturday when nobody is watching the org? Candidates who reach for Apex on every requirement are under-using the platform. Candidates who always reach for Flow build automation they can’t maintain at scale. The judgment between them is, more or less, the whole job.

Question 5: “Describe how you’d write a unit test for an Apex trigger that creates related records, where the test needs to be isolated from org data and still achieve meaningful coverage.”

Coverage percentage is table stakes. What you’re actually testing is whether they understand @isTest data isolation, Test.startTest/stopTest scoping, and why inserting records in a test method that doesn’t account for the org’s validation rules and required fields fails in a production org in ways it never did in sandbox. Developers who have only worked in clean sandbox environments often fail here. The production org always has something the sandbox didn’t. Always.

LWC and Front-End Questions for 2026

A framing note. LWC questions split along the old Aura fault line. Many developers trained during the Aura era are nominally LWC-capable but haven’t internalized the reactive programming model. Finding the difference takes deliberate questioning. The interview needs to distinguish between developers who have been actively shipping in LWC since 2022, working with wire services and reactive properties on real data, and those who understand the decorator syntax but still pattern-match to Aura under pressure. That gap shows up fastest in component communication and reactivity questions. Not the same hire.

Question 1: “Explain @api, @track, and @wire in LWC. Which do you reach for first, and in what order does reactivity happen?”

The definition is on every list. What reveals experience: do they know that @track is largely redundant since Spring ’20 because primitive properties, plain objects, and arrays are now reactive by default, making explicit decoration unnecessary for most component state patterns outside of deeply nested object mutation? Wrapping everything in @track is a residual Aura habit. Candidates who still use it reflexively haven’t been building in LWC recently. Candidates who know it’s deprecated and explain why reveal that they’ve been paying attention to platform releases, not just reviewing study guides.

Question 2: “You have a parent LWC component that needs data from a grandchild. Walk me through the communication options and your reasoning.”

Expected answer covers property binding parent-to-child via @api, event bubbling child-to-parent via custom events, and Lightning Message Service for components outside a direct parent-child relationship or spanning page areas. The tradeoff is the interesting part: LMS adds complexity and is harder to unit-test. Events are cleaner for simple hierarchies. A candidate who reaches for LMS on a two-component hierarchy is over-engineering. One who tries to bubble events across page sections is building something fragile. The judgment between them is what you’re testing.

Question 3: “A client has 40 Aura components in active use that need to migrate to LWC. They want the whole thing done in a single release. Walk me through your response.”

Push back. The reasoning is the interesting part. Aura-LWC interoperability allows mixing. That means a phased migration is technically viable and far lower risk than a single-release big-bang that puts 40 components in scope simultaneously, creates a regression surface area large enough to make rollback nearly impossible, and almost guarantees something breaks at step 12 of 12. The real test is whether the candidate raises those concerns without prompting. Developers who say “sure, let’s scope it” without flagging the risk have either never run a migration like this or have a very selective memory of how the last one went.

Integration and Platform Design Questions

Integration failures are expensive in Salesforce. They are also where the senior/junior gap is most visible. Junior developers have typically worked against sandbox endpoints with clean test data that returns expected responses. Production APIs behave differently. They time out. They return 200 with an error payload. They change response schemas without notice three weeks after launch. The interview needs to surface whether the candidate has built integrations that survived those realities.

Question 1: “You’re integrating Salesforce with an external ERP via REST API. The ERP’s endpoint can take up to 12 seconds to respond. How do you architect it?”

12 seconds exceeds Salesforce’s synchronous callout limit of 10 seconds. The right answer involves asynchronous Apex (queueable or future method) plus a callback or polling mechanism to retrieve the result. Candidates who don’t surface the callout timeout limit usually haven’t hit it on a real integration. It is a memorable production problem. Genuinely memorable. You don’t forget it after the first time it takes down an order-processing workflow at 2pm on a Tuesday because you forgot to account for peak ERP load times when you were testing against the sandbox endpoint at 9am.

Question 2: “When would you use Platform Events instead of triggers or outbound messages for real-time integration? When would you not?”

Platform Events are the right answer when you need guaranteed delivery and replay, want to decouple the publisher from the subscriber, or have external subscribers that can’t poll. Outbound messages are simpler but SOAP-based with limited retry control. The “when would you not” part distinguishes experience from theory: a system with 40 event types and no documentation is a real maintenance problem. Somebody always inherits it.

Agentforce and AI-Powered Salesforce: The 2026 Senior Signal

Most interview loops don’t cover this yet. They should.

Agentforce shipped in late 2024 and became a real hiring criterion by mid-2025. It is now the clearest differentiator between a developer who has been actively building on Salesforce over the last eighteen months and one who earned certifications in 2023 and hasn’t shipped anything meaningful since. If the role touches the Einstein platform, Prompt Builder, AI-powered Flows, or Agentforce agent deployment, you need to test for this explicitly. Most candidates won’t have deep experience with it. That’s useful data before you make an offer.

Question 1: “What is Agentforce, and when would you use it instead of custom Apex automation?”

The right answer distinguishes two paradigms. Agentforce handles conversational, multi-step, context-dependent workflows that would require complex branching in Apex. Custom Apex is better for deterministic, high-volume, auditable operations with strict error-handling requirements. A developer who says “Agentforce replaces Apex” is wrong. One who says “Agentforce is just Flow with AI bolted on” is also wrong. Both answers exist. The right candidate can choose between the tools based on the actual requirement without defaulting to either one, and can articulate the tradeoffs clearly enough that a non-technical stakeholder would understand the reasoning. That’s the judgment you’re testing.

Question 2: “Describe how you’d use Prompt Builder to customize an AI response for a Sales Cloud workflow. What are the compliance guardrails?”

A candidate with actual Prompt Builder experience mentions the specifics. Prompt templates bound to record context. The grounding mechanism that pulls field data into the prompt. Token limits and how they constrain prompt design. And the Einstein Trust Layer, the data masking and compliance layer that prevents sensitive org data from leaving the platform. The Trust Layer is a meaningful signal. Candidates who haven’t worked with Agentforce often don’t know it exists. Clients in financial services, healthcare, and legal have asked me about it by name before starting a Salesforce AI search. Real credential separator in regulated industries. Ask about it.

Question 3: “Your client wants to replace human SDR qualification with an Agentforce agent. Walk me through what you’d build and where you’d put a human in the loop.”

Open-ended intentionally. Strong candidates ask clarifying questions before answering: what are the qualification criteria, what CRM data already exists, what’s the fallback when the agent can’t classify a lead? They name specific Agentforce components, Topics, Actions, the grounding sources the agent can query. The human-in-the-loop piece is where experience shows. A candidate who designs a fully automated qualification workflow with no escalation path has either never deployed Agentforce in production or hasn’t thought seriously about edge cases. The edge cases always arrive. Always.

Red Flags to Watch During the Interview

They can explain what but not why. The candidate who recites that Salesforce enforces 100 SOQL queries per transaction but can’t explain the reason (multi-tenant resource fairness in shared infrastructure) is drawing from memorization. This surfaces when they hit a novel scenario where the memorized answer doesn’t apply cleanly. You won’t know that until something breaks in production. And it will.

They default to code when the requirement is declarative. Over-coding is a real anti-pattern on the Salesforce platform. A trigger that fires on every Account save to update a field that a formula could handle, without governor limit exposure, without a required deployment, is a maintenance cost. Developers who write Apex for everything tend to build systems that are expensive to hand off and hard to modify later.

The flip side is just as bad: they default to Flow when the requirement needs code. The chain of subflows with 14 decision elements built because the developer wanted to avoid writing Apex, that fails in ways that are difficult to trace back to the source, that is owned by nobody after the original developer leaves. Both failure modes are real. Both show up in the Salesforce searches I run. Both cost clients more than the hire itself. Different symptoms. Same root cause: nobody tested the judgment. The declarative-or-programmatic judgment is the most important thing to screen for, and most question lists don’t test it at all.

No production stories. Every experienced Salesforce developer has been burned by something specific: a governor limit exception at go-live, a Flow that fired in the wrong order, a data migration that left 4,000 records in an inconsistent state. A candidate claiming four-plus years of platform experience who can’t recall a specific incident is either padding the resume or was insulated from the operational side of the systems they worked on. Both are worth probing before offer. Every time.

Certifications presented as experience. Admin plus Platform Developer I plus Platform Developer II plus a few specialty credentials do not automatically mean the developer can architect a production org under real data volumes. Certifications test knowledge coverage. The judgment required in production comes from shipping things, watching them fail in ways that weren’t covered in testing, fixing them under pressure while a stakeholder is waiting for an explanation, and then building the next version with those failure modes explicitly in mind from the beginning. Treat certifications as a baseline filter. Not a hiring signal by themselves. Not where it counts. I’ve placed Platform Developer II engineers who could architect a multi-cloud Salesforce integration from scratch and I’ve placed Platform Developer II engineers who needed help through a basic trigger refactor. The certification says nothing about which one you’re hiring. For a view of what this role commands in compensation by experience tier, the KORE1 Salesforce developer salary guide breaks it down by stack and certification profile. And if you want to benchmark your offer against recent closes, the salary benchmark assistant is worth a few minutes before you go to market.

Before You Start the Search

How do I know if a Salesforce developer is senior-level or just certification-heavy?

Ask them to describe a production failure they personally owned.

A senior Salesforce developer has been paged. They’ve debugged at volume. They’ve rolled back a deployment. They can tell the story with specifics: what broke, why it wasn’t caught before go-live, what they changed in the architecture afterward. A certification-heavy junior describes what should theoretically have prevented the failure. One answer comes from experience. The other comes from a module. Two minutes. You’ll know.

What certifications should I require for a senior Salesforce developer role?

Platform Developer I is table stakes for any development role.

Platform Developer II signals meaningful Apex depth and is worth requiring for senior hires. Salesforce Certified Application Architect or System Architect credentials indicate someone who has thought seriously about cross-org design and multi-cloud implementations. For roles touching Einstein and Agentforce, the new AI Specialist certification is worth asking about, though the pipeline is still maturing as of 2026. Don’t let certification count substitute for a conversation about production experience. A developer with strong hands-on history and fewer certs is often a better hire than one with six badges and a sandbox-only track record. That’s a real pattern in this market. I’d rather not see it repeat on your search.

Realistically, how long does it take to fill a senior Salesforce developer role in 2026?

21 to 28 days working with a specialized staffing partner; 6 to 10 weeks recruiting direct.

KORE1’s average IT time-to-hire is 17 days across all roles, and Salesforce developer searches at the mid-senior tier, specifically the combination of Apex depth plus LWC fluency plus at least some exposure to Agentforce, run closer to the 22-25 day range in the current market. Salesforce developer searches, especially for mid-senior candidates with both Apex depth and LWC fluency, run slightly longer because the qualifying criteria are specific. The Salesforce Ben 10K Report put U.S. job postings above 31,200 in late 2025, so demand is real and competition for the right candidate is meaningful. The market for production-experienced Salesforce developers is not thin. But the specific combination of Apex depth plus LWC fluency plus Agentforce awareness is less common than the overall posting volume suggests. Plan accordingly.

Also worth noting: if the role requires a direct hire placement rather than contract, the timeline skews slightly longer because candidate availability windows are tighter and competing offers happen faster at this experience level. Budget for that.

Should I require Agentforce experience in the job description?

Require Agentforce familiarity, not full production deployment experience.

The number of developers with a complete Agentforce deployment in production is still relatively small, and listing it as a hard requirement narrows the candidate pool to a dysfunctional size. What you can and should test for is awareness: understanding of the Agentforce architecture, ability to discuss Prompt Builder and the Einstein Trust Layer, a coherent answer to how they’d approach building a first agent. Developers who answer that credibly will grow into the role. The ones who look blank when Agentforce comes up are likely to struggle with the 2026 and 2027 platform roadmap regardless of their Apex depth.

Is a live coding exercise worth the scheduling friction?

Worth it. Scope it narrowly and make it realistic.

A 30-minute practical Apex exercise, small dataset, a few deliberately ambiguous requirements. That reveals more about actual capability than any 90-minute whiteboard session can. Whiteboard sessions favor the candidates who perform confidence well and reason out loud with polish. Not necessarily the same people who can build something that holds up when the real data arrives and the requirements turn out to be slightly different from what was described. Different skills. Both interview well. One ships clean code. The ambiguity matters: watch whether the candidate asks clarifying questions before writing anything. Developers who ask questions have been in production, where requirements are never fully specified. Developers who start building immediately against their first interpretation have usually worked in more controlled environments where someone else wrote the spec. Both are useful signals before an offer.

If the screening process above feels like more than your team has bandwidth for, that’s a common situation. We run Salesforce searches through our Salesforce developer staffing practice across 30-plus U.S. metros, and the framework above is essentially what we apply when qualifying candidates before we submit them to a client. If you’d rather skip straight to a vetted shortlist, the contact page is the fastest way to get there.