30 Salesforce Coding Interview Questions for 2026

Prep for Salesforce coding interviews with 30 questions on Apex, SOQL, triggers, integrations, security, and Lightning architecture.

Top Salesforce coding interview questions: 30 most asked (2026)

Salesforce coding interviews rarely test whether you can recite a definition. They test whether you understand why the platform works the way it does — governor limits, trigger design, data access patterns, integration security — and whether you can reason through trade-offs under pressure.

This post covers 30 of the most common questions grouped by topic: Apex and governor limits, SOQL and data access, triggers and automation design, integrations and secure coding, and Lightning platform architecture. Each answer is concise enough to study and specific enough to adapt to your own experience.

What Salesforce coding interviews actually test

Interviewers probe four areas, and they care more about your reasoning than your vocabulary.

• Apex programming and governor limits. Can you write code that respects the multi-tenant architecture? Do you understand bulkification, async patterns, and when declarative tools are the better choice?
• Triggers and automation design. Can you design automation that doesn't break at scale? Do you know the order of execution and how to avoid recursive loops?
• SOQL and data access. Can you query efficiently, enforce security, and explain relationship types without hesitating?
• Integrations and secure coding. Can you make callouts, expose APIs, and handle credentials without hardcoding secrets?

Expect a mix of scenario-based questions, live coding, and architecture discussions. The best answers lead with the trade-off, not the textbook definition.

Apex and governor limits

Q1 — What are governor limits and why do they exist?

Salesforce is a multi-tenant platform. Governor limits prevent any single tenant's code from consuming shared resources — CPU time, heap size, SOQL queries, DML statements. A single transaction is limited to 100 SOQL queries, for example. Every Apex developer needs to design around these constraints, not fight them.

Q2 — What is the difference between synchronous and asynchronous Apex?

Synchronous Apex runs in the current transaction and is subject to its governor limits. Asynchronous Apex — Queueable, Batch, Scheduled, and Future methods — runs in a separate context with higher limits. Batch Apex can process up to 50 million records. Use async when you need to handle large data volumes or make callouts that would block the user's transaction.

Q3 — When would you use Batch Apex over Queueable Apex?

Batch Apex is for high-volume processing — millions of records, each chunk governed independently. Queueable is better for chaining sequential jobs with more complex logic and state passing. If you need volume, go Batch. If you need orchestration, go Queueable.

Q4 — What is the difference between a trigger and a Flow?

Triggers are Apex code that runs on DML events. Flows are declarative automation built in Flow Builder. Workflow Rules and Process Builder are being deprecated — Flow is the recommended declarative path going forward. Choose Flow when the logic is straightforward and maintainability matters; choose a trigger when you need complex logic, bulkified processing, or tight control over execution order.

Q5 — What is the order of execution in Salesforce?

The key stages: system validation → before triggers → custom validation rules → after triggers → assignment rules → auto-response rules → workflow rules → Flow automations → commit. One detail worth knowing: validation rules fire before Flow updates, which means a Flow that modifies a field can still be blocked by a validation rule evaluated earlier in the cycle.

Q6 — How do you write a bulkified Apex trigger?

Operate on collections, not individual records. Never put SOQL queries or DML statements inside a loop. Collect IDs first, query once, process in bulk, and perform a single DML operation at the end. This is the most common mistake interviewers screen for.

Q7 — What trigger events are available in Apex?

Before insert, before update, before delete, after insert, after update, after delete, and after undelete. Before events let you modify the record before it's saved. After events give you access to system-set fields like the record Id.

Q8 — What is a global class and when would you use one?

A global class is accessible across namespaces — required for managed packages, web services, and certain interfaces. Use it when you need external visibility. Default to public otherwise, because global access can't be revoked after a managed package is released.

SOQL and data access

Q9 — What is the difference between SOQL and SOSL?

SOQL queries a specific object and its related objects. SOSL searches across multiple objects simultaneously using a text-based search index. Use SOQL when you know which object holds the data. Use SOSL when you need to find a term across Accounts, Contacts, and custom objects at once.

Q10 — What are relationship queries in SOQL?

Parent-to-child queries use a subquery on the child relationship name. Child-to-parent queries use dot notation on the lookup or master-detail field. The distinction between lookup and master-detail matters here — master-detail enforces cascading delete and allows roll-up summary fields.

Q11 — How do you enforce field level security in SOQL?

Two approaches: `WITH SECURITY_ENFORCED` appended to a SOQL query strips out rows where the user lacks field access, and `Security.stripInaccessible()` removes inaccessible fields from query results in Apex. Use `WITH SECURITY_ENFORCED` for simple queries; use `stripInaccessible` when you need to process the data further before returning it.

Q12 — What is dynamic SOQL and what are its risks?

Dynamic SOQL builds query strings at runtime. The main risk is SOQL injection — user input concatenated directly into a query string. Always use `String.escapeSingleQuotes()` on any user-supplied value. Use dynamic SOQL when the query structure genuinely varies at runtime; prefer static SOQL everywhere else.

Q13 — What is a roll up summary field and when can't you use one?

Roll-up summary fields aggregate child records (COUNT, SUM, MIN, MAX) on a master-detail relationship. They don't work on lookup relationships. For lookups, use Declarative Lookup Rollup Summaries (DLRS) or write a trigger to calculate the aggregate.

Q14 — What are the SOQL governor limits you need to know?

100 SOQL queries per synchronous transaction. 50,000 rows returned per transaction. These limits are why bulkification matters — a trigger that runs one query per record in a batch of 200 hits the limit immediately.

Triggers and automation design

Q15 — What is a trigger handler pattern and why use one?

A trigger handler moves all logic out of the trigger body and into a separate Apex class. The trigger itself becomes a thin dispatcher. This makes the logic testable in isolation, easier to maintain, and less likely to cause merge conflicts when multiple developers work on the same object.

Q16 — How do you prevent recursive triggers?

Use a static Boolean variable in a helper class. Set it to true on the first execution and check it at the top of the trigger. If it's already true, exit. This prevents infinite loops when a trigger's DML operation re-fires the same trigger.

Q17 — When would you choose Flow over an Apex trigger?

Flow is the right choice when the logic is declarative-friendly — field updates, record creation, simple branching. It's easier for admins to maintain and doesn't require a deployment cycle. Use a trigger when you need complex logic, bulkification across large datasets, or tight control over execution sequence.

Q18 — How do you test an Apex trigger?

Production deployment requires 75% overall code coverage, and every trigger must have at least 1% coverage. Use `Test.startTest()` and `Test.stopTest()` to reset governor limits within the test. Create test data explicitly — don't rely on org data — and assert outcomes, not just coverage.

Q19 — What is the difference between before and after triggers?

Before triggers let you modify field values before the record is saved — no additional DML needed. After triggers run after the record is committed, so system fields like Id are available, but modifying the triggering record requires a separate DML operation.

Q20 — How would you design a trigger to handle Opportunity approval logic?

A common scenario: only Sales Managers can approve Opportunities over $100,000. The recommended approach combines an Approval Process for the workflow with either a validation rule or Apex logic to enforce the threshold and role check. The Approval Process handles routing and notifications; the code or validation rule enforces the business constraint.

Integration and secure coding

Q21 — How do you make a REST callout from Apex?

Use the `HttpRequest` and `HttpResponse` classes. Set the endpoint, method, headers, and body on the request, then send it via `new Http().send(request)`. Callouts can't run in the same transaction as pending DML — use a `@future(callout=true)` method or Queueable Apex to separate the contexts.

Q22 — How do you expose an Apex class as a REST API?

Annotate the class with `@RestResource(urlMapping='/your-endpoint')` and individual methods with `@HttpGet`, `@HttpPost`, etc. The platform handles authentication via connected apps and OAuth. Keep the methods stateless and bulkified.

Q23 — What are Named Credentials and why use them?

Named Credentials store endpoint URLs and authentication details — OAuth tokens, basic auth credentials — so your Apex code never contains hardcoded secrets. Pair them with Custom Metadata Types for environment-specific configuration that's deployable across orgs.

Q24 — What is the difference between Custom Settings and Custom Metadata Types?

Custom Metadata Types are deployable through change sets and packages, available in formulas and validation rules, and treated as metadata. Custom Settings are stored as data, can be modified at runtime, but aren't deployable the same way. For configuration that needs to travel between environments, Custom Metadata Types are the right choice.

Q25 — How do you enforce sharing rules in Apex?

Use the `with sharing` keyword to enforce the running user's record-level access. `without sharing` bypasses record-level security — use it only when intentional, like in a service class that needs full access regardless of the caller. `inherited sharing` defers to the calling class's sharing context.

Q26 — What is the risk of using without sharing?

It bypasses all record-level security — org-wide defaults, sharing rules, manual shares. If a class marked `without sharing` is called from a user-facing context, it can expose records the user shouldn't see. Always document why you're using it and limit its scope.

Lightning and platform architecture

Q27 — What is the difference between LWC and Aura components?

Lightning Web Components use modern web standards — native HTML elements, standard JavaScript, and the Shadow DOM. Aura uses a proprietary component model. LWC is the recommended framework for new development. Aura is still supported but is heavier and less performant.

Q28 — What is @AuraEnabled and when do you need it?

The `@AuraEnabled` annotation exposes an Apex method to LWC and Aura components. Add `cacheable=true` for read-only methods to enable client-side caching and improve performance. Without the annotation, the method is invisible to the front end.

Q29 — What is SLDS and how does it affect component development?

The Salesforce Lightning Design System (SLDS) is a CSS framework that provides consistent styling across the platform. Using SLDS classes means your components look native without custom CSS. It also handles accessibility compliance.

Q30 — How do you make an LWC component configurable in App Builder?

Expose properties with the `@api` decorator and define `targetConfigs` in the component's metadata XML file. This lets admins set property values directly in App Builder without touching code — useful for reusable components that need different behavior per page.

How to answer these questions well

Four things separate strong answers from forgettable ones.

Lead with the trade-off. Don't start with "X is defined as…" Start with "You'd choose X over Y when…" Interviewers are evaluating your judgment, not your memory.

Anchor in a real project. "In my last org, we used Batch Apex because the nightly sync processed 2 million Contact records" is more convincing than a textbook explanation.

Think aloud on design questions. Architecture questions don't have one right answer. Walk through your reasoning — constraints, alternatives, why you'd pick one approach. That's what's being scored.

Show platform awareness. Knowing that Salesforce ships three major releases per year (Spring, Summer, Winter) and that deprecated tools like Workflow Rules are being replaced by Flow signals that you stay current.

Reading answers is preparation. Saying them out loud is practice. If you want to rehearse these question types with real-time feedback before the actual interview, Verve AI's mock interview tool lets you run through Salesforce-specific scenarios and get structured performance reports on your responses.

---

Salesforce coding interviews cover a lot of ground — Apex, SOQL, triggers, integrations, Lightning architecture, and the platform constraints that tie them all together. The 30 questions above hit the areas interviewers return to most often. Know the answers, but more importantly, know the reasoning behind them. That's what gets you through.