Question 1

What is Apex and how does it differ from Java?

Accepted Answer

Apex is Salesforce's proprietary, strongly-typed, object-oriented programming language that runs on the Lightning Platform. Syntactically it looks like Java — classes, interfaces, generics-style collections, exceptions — but it differs in several important ways: - Hosted, not compiled to JVM . Apex code runs only inside Salesforce's multi-tenant infrastructure. You cannot run Apex outside Salesforce. - Governor Limits enforced at runtime — Apex's defining constraint. Every transaction has hard caps on SOQL queries, DML, CPU time, heap size. - Tightly integrated with the database — SOQL/SOSL queries and DML are first-class language constructs ( ). - Built-in transaction context — every Apex execution is one transaction; rollbacks are automatic on uncaught exceptions. - Versioned per API — every class declares its API version, ensuring backward compatibility across Salesforce releases. - Test coverage requirement — production deploys require 75% Apex test coverage. Use Apex when declarative tools (Flow, validation rules) can't express the logic, or when bulk performance demands code over flow.

Question 2

What is SOQL and how does it differ from SQL?

Accepted Answer

SOQL (Salesforce Object Query Language) is Salesforce's query language for retrieving records. Inspired by SQL but with key differences: - No — you must list every field. Fields not selected return null on the resulting sObject. - Single-object queries with relationship traversal — traverses the lookup, but classic SQL JOIN syntax doesn't exist. You use dot notation for parent and subqueries for children : . - Limited operators — no , no (use only), no full-text via (use SOSL for that). - Governor-limit aware — every query counts against the per-transaction SOQL limit (100 sync, 200 async). - Index-driven — for large tables, queries must hit indexed fields to be selective. - Polymorphic queries — query on Lookup-to-Polymorphic relationships ( ). Use SOSL instead of SOQL for full-text search across multiple objects.

Question 3

What is an Apex Trigger and what are trigger context variables?

Accepted Answer

An Apex Trigger is code that executes before or after specific DML events on a Salesforce object — , , , . Defined as . Trigger context variables give you access to the records being processed and metadata about the transaction: - — list of new versions of records (insert/update). - — list of previous versions (update/delete/undelete). - , — same as above keyed by record Id. - , , , — type of operation. - , — timing. - — number of records. Best practice: one trigger per object , calling out to handler classes that decide what to run based on context. Putting business logic directly in the trigger creates maintenance pain.

Question 4

What is the difference between SOQL and SOSL?

Accepted Answer

Both query Salesforce data, but they answer different questions. SOQL queries a single object (with related-record traversal) and returns specific records matching filters. Use when you know the object and can express criteria as field comparisons. SOSL searches text across multiple objects at once using a search-engine index. Returns a list of lists — one per object searched. Use for full-text "find all records mentioning 'acme'". Differences: - Object scope : SOQL is single-object; SOSL is multi-object. - Match type : SOQL is exact field comparisons; SOSL is text search with stemming. - Performance : SOSL is fast for ambiguous searches across many objects; SOQL is fast when you know what you're looking for. - Result shape : SOQL returns one list of sObjects; SOSL returns nested lists per object. Default to SOQL. Reach for SOSL when the user's input is search-style ("find anything with this name").

Question 5

What is DML in Apex and what are its limits?

Accepted Answer

DML (Data Manipulation Language) is how Apex inserts, updates, deletes, undeletes, and upserts records. Two syntaxes: Statement form (concise): Database method form (more options): Database methods give you partial-success flag ( ) and per-record objects with success/error info. Governor limits : - 150 DML statements per transaction . - 10,000 records per DML in sync; higher async. - Each statement counts as one regardless of record count. Best practices: - Bulkify : do one instead of in a loop. Loops with DML inside hit the 150 limit fast. - Don't mix sObject types in one Database method call — that's a different limit. - Use upsert with External Id for integrations to avoid duplicate-key issues. DML inside a loop is the 1 anti-pattern in Apex.

Question 6

What is an sObject in Apex?

Accepted Answer

An sObject is a Salesforce-aware object representation in Apex — Account, Contact, Opportunity, MyCustom c, etc. Apex generates an sObject class for every Salesforce object, with one strongly-typed field per Salesforce field. You can also use the generic superclass when you don't know the type at compile time: This is useful in framework code that needs to work across many objects — e.g., a generic field-update utility. Key methods: - / — generic accessors. - — runtime type info. - — map representation. Lists of sObjects ( , ) are the standard way to bulk-process records. SOQL queries return them naturally.

Question 7

What's the difference between Lightning Web Components (LWC) and Aura Components?

Accepted Answer

Both are Salesforce's UI component frameworks but represent different generations. Aura (older, 2014) — Salesforce-proprietary component framework. Uses markup files, controllers in JS+helper.js, server-side Apex via attributes. Built on a custom rendering engine. LWC (newer, 2019) — based on the Web Components standard (Custom Elements, Shadow DOM, ES Modules). Looks and feels like modern frontend code: TypeScript-style classes, decorators ( , , ), template files ( ). Differences: - Performance : LWC is faster — uses the browser's native rendering rather than a custom engine. - Standards : LWC is closer to standard JavaScript; developers transfer skills from React/Vue more easily. - Tooling : LWC works with VS Code, Jest for unit testing, ESLint. Aura tooling is more limited. - Composition : LWC components can wrap Aura components but not vice versa (in some scenarios). Mixed apps work. - Bundle size : LWC components are leaner, load faster. - Future : LWC is the strategic direction. New work should be LWC; Aura is for maintaining existing components. When you'd still touch Aura: maintaining an existing Aura-heavy codebase, or for the few platform features that haven't migrated to

Question 8

What is an Apex Test Class and why is it required?

Accepted Answer

An Apex Test Class is Apex code marked with that exercises your production Apex classes. Salesforce requires: - 75% line coverage for the org's Apex code before deploying to production. - Every trigger must be touched by at least one test. - Tests must run successfully — no failures allowed during deploy validation. Anatomy: Key features: - Test isolation — tests don't see existing org data by default. You build test data with methods or inline factories. - / — async ops fired between these run synchronously when is called, letting you assert on their effects. - — assertions that fail the test if values don't match. Don't write tests just to hit coverage. Write tests that assert business behaviour — coverage is a side effect of good tests.

Question 9

How do you bulkify a trigger and why does it matter?

Accepted Answer

Bulkification means writing trigger code that handles a list of records efficiently — not one-record-at-a-time. It's mandatory because triggers are invoked for every DML, and DML can include up to 200 records per batch. The anti-pattern (don't do): Hits the 100 SOQL / 150 DML limit at 100/150 accounts respectively. The correct pattern: One SOQL, one DML, scales to 200 accounts (the Apex bulk size). Bulkification matters because: - Data Loader processes records in batches of 200. - Bulk API can submit 10k+ rows. - Mass updates in flow or reporting tools push lots of records through your trigger. Untestable rule: if you write SOQL or DML inside a loop, your trigger is broken at scale.

Question 10

What's the difference between database.insert() and the insert statement?

Accepted Answer

Both perform DML, but they differ in error handling. Statement form : All-or-nothing: if one record fails validation, the whole list is rolled back. Database method form : The second argument controls behaviour: - (default) — same as statement form: all-or-nothing. - — partial success: each record either succeeds or fails individually. Records that succeed get committed; failed ones return errors in the SaveResult. You then iterate over to inspect: When to use each: - Statement form — when one failure should reject everything (typical for tightly-related records). - Database method, allOrNone=false — when you can tolerate partial success and want to log/handle individual failures (typical for batch loads, integrations). Equivalent variants exist for , , , .

Question 11

What are the async options in Apex (@future, Queueable, Batch, Schedulable) and when use each?

Accepted Answer

Salesforce has four async patterns, each with different strengths. — fire-and-forget method invocation. Annotate a static method with . The method runs in a separate transaction at some later time. Use for: simple async work, callouts from triggers (callouts can't run in trigger context), email-after-trigger patterns. Queueable — like but with chaining and state . Implement ; enqueue with . Returns a job ID for tracking. Use for: chained async work ("after this, fire the next job"), passing complex objects (sObjects, custom types) through async boundaries — is restricted to primitives. Batch Apex — processes large data sets in chunks. Implement with (returns query/iterable), (processes each chunk), and (cleanup). Each chunk is its own transaction. Use for: million-row scheduled cleanup, mass updates, anything that exceeds single-transaction limits. Schedulable — implements . Used with or via Setup - Apex Classes - Schedule. Just defines . Use for: cron-style "run this every Sunday at 2am". Schedulable typically kicks off Batch or Queueable jobs. Decision tree: - One method, primitive args, fire-and-forget - . - Need chaining or complex args - Queueable. - Large data volume, chunk p

Question 12

What's the order of execution within a trigger transaction?

Accepted Answer

When a record is saved, Apex runs in this order: 1. System validation — required fields, max length, foreign keys. 2. All triggers fire (one trigger per object recommended; if multiple exist, ordering is undefined). 3. Custom validation rules evaluate. 4. Before-save flows run (record-triggered flows configured for fast field updates). 5. Database commit-1 — record is saved but not yet committed. 6. All triggers fire. Record's Id is now populated. 7. Assignment rules (Lead/Case). 8. Auto-response rules (Lead/Case). 9. After-save record-triggered flows . 10. Workflow rules — legacy field updates and outbound messages. 11. Process Builder processes . 12. If a workflow field update happened , before/after triggers and validation rules fire AGAIN on those affected fields (re-entry). 13. Escalation rules (Case). 14. Roll-up summary recalculation . 15. Sharing rules evaluation . 16. Database commit-2 — transaction is now durable. 17. Async logic — , queueable, batch, outbound messages, platform events that publish on commit. Implications for trigger code: - before triggers can mutate Trigger.new directly without DML. - after triggers run on records that are already in the DB but pre-comm

Question 13

How do governor limits differ between synchronous and asynchronous Apex?

Accepted Answer

Sync and async contexts have different limit ceilings — async generally gets more headroom because it's not blocking a user. | Limit | Sync | Async | |---|---|---| | SOQL queries | 100 | 200 | | DML statements | 150 | 150 | | Heap size | 6 MB | 12 MB | | CPU time | 10,000 ms | 60,000 ms | | Future calls / queueable enqueues per transaction | 50 | 50 | Async contexts ( , Queueable, Batch, Schedulable) get: - More CPU time — useful for long-running calculations. - More heap — can load larger record sets. - More SOQL — query more data per transaction. But DML is still capped at 150 in async — async doesn't help with bulk-write needs. Important nuances: - Batch Apex execute() runs once per chunk . Each chunk is its own transaction with its own limits. So a Batch processing 10M records in chunks of 200 effectively gets 200×its-limits-per-execute = lots of total work, but each execute is bounded. - Queueable can chain — fire another Queueable from one Queueable to extend processing. Chaining is unlimited but each link has its own per-transaction limits. - cannot enqueue another — Salesforce blocks the chain to prevent infinite recursion. Don't try to fit a 1M-record update into one async

Question 14

What is a Wrapper Class in Apex and when do you use one?

Accepted Answer

A Wrapper Class is an Apex class that bundles together related data — typically an sObject plus extra computed/UI fields — for use in a Visualforce page, Lightning component, or Apex API. Example: a Visualforce page that lists Opportunities with checkboxes for selection. Then in your controller: In the page: . Common use cases: - UI selection state — checkbox, expanded row, hover, etc. - Computed fields — derived totals, formatted display values. - Multi-object aggregation — combine data from Account, Contact, Opportunity in one row. - API response shaping — DTO-style classes for REST/SOAP web services. In LWC, the same pattern uses JavaScript objects rather than Apex Wrapper Classes, but Apex still returns Wrapper Classes from methods.

Question 15

What are the differences between static, instance, and global methods in Apex?

Accepted Answer

Apex methods have a class scope and a visibility scope. Class scope: - Instance method — bound to an object instance. Access via . Can use instance variables. - Static method — class-level. Access via . No . Used for utilities and stateless logic. Visibility scope: - — visible only within the class (default). - — visible to the class and its subclasses. - — visible to any class in the same namespace. - — visible to any code, including code in other namespaces (other Salesforce orgs / managed packages). Required for web service methods, batch start/execute/finish, and methods called from outside your namespace. When to use each: - + instance — most internal class methods. - + static — utility methods callable from anywhere in your namespace. - — only when truly necessary. methods are part of your public API and changing their signature breaks consumers — they're effectively eternal commitments. Most code shouldn't be . Common mistake: making everything "just in case". This locks the API permanently. Use until you have a concrete reason to expose to other namespaces.

Question 16

How does Apex handle null values, and what patterns help avoid NullPointerException?

Accepted Answer

Apex's semantics are mostly Java-like, with some Salesforce-specific quirks. What is null: - Variables declared but uninitialised: is . - sObject fields not selected in SOQL come back as null — even if they have values in the DB. - Empty collections are NOT null — is empty but non-null. - returns true for against another . NullPointerException sources: - Calling a method on : when or is null. - Dereferencing a map's value when key not present: — returns null, then dereferencing fails. - SOQL returning empty list, then on it — IndexOutOfBoundsException, not NPE, but similar pattern. Patterns to avoid NPEs: 1. Safe navigation operator (Apex equivalent: ): 2. Null check before access : 3. Default values via — Map's get with default. 4. String.isBlank() / String.isEmpty() — check string-ness without NPE. 5. before accessing element by index. 6. Null-coalescing for primitives : The single biggest source of NPEs in Apex is querying with and then accessing the result without checking if the list is empty.

Question 17

What's the difference between `with sharing`, `without sharing`, and `inherited sharing` in Apex?

Accepted Answer

These keywords on a class declaration control how Apex enforces the org's sharing rules when querying or updating data. — Apex respects the running user's sharing rules. SOQL only returns records the user can see; DML respects their edit access. Use for: code invoked from a user context where data privacy must be enforced — Visualforce/LWC controllers, REST services called by users. — Apex ignores the running user's sharing rules. SOQL returns all records; DML can modify anything. Use for: code that legitimately needs system-level access regardless of who invoked it — system maintenance, calculations across all records, integration handlers running as integration users that have View All Data anyway. — Apex uses whatever sharing context the caller declared. If called from a class, runs . If called from , runs . If invoked from outside Apex (top-level), defaults to . Use for: utility classes that should respect their caller's intent, not impose their own. Default behaviour (no keyword) — depends on context: - Triggers: typically run . - Visualforce/LWC controller methods: run with the page's controller's sharing setting. - Anonymous Apex / : runs with system-level access. Best pract

Question 18

Walk me through writing a properly bulkified trigger handler.

Accepted Answer

The trigger framework pattern: trigger does nothing but delegate; logic lives in handler classes. The trigger (one per object): The handler base class : The Account-specific handler : Why this is good : - One trigger per object — clear orchestration point. - Handler is testable — mock the trigger context in tests; no need to fire actual DML. - Bulkified — Sets, Maps, queries outside loops, single DML. - Conditional work — early return when nothing changed. - Type casts isolated — handler does the cast once. Add as you grow : - A that maps sObject name to handler class for dynamic dispatch. - A static recursion guard inside each handler to prevent re-entry. - Per-record action queues for cross-trigger collaboration (e.g., a handler updates state used by another handler in the same transaction).

Question 19

How do you debug a SOQL query returning unexpected results in Apex?

Accepted Answer

Common causes and the diagnostic order. 1. Sharing context. Are you running and the user lacks access to records you expect? Check by running the same query as System Administrator — if results differ, sharing is the cause. 2. Field-Level Security. The query selects fields the running user can't see. The query succeeds but those fields come back null on the result. 3. Query is non-selective on a large table — Salesforce optimizer can return wrong results or time out. Check via (in Developer Console - Query Editor - Explain). Hit indexed fields in the WHERE clause. 4. Implicit limits. - Apex SOQL returns up to 50,000 rows per query unless using (Batch) or . Beyond 50k, query throws or truncates. - Aggregate queries are subject to GROUP BY rules — . 5. Filter logic. OR/AND parentheses — Apex's WHERE clause grammar is its own; "where A and B or C" without parentheses can yield surprising results. 6. Date semantics. SOQL date literals ( , ) are timezone-dependent on the running user's locale. A query for a user in PST and a user in IST returns different rows on the same data. 7. Null and unset values. matches empty strings but not nulls. To match both: . 8. SOQL aliasing trap. If you a

Question 20

Walk me through Apex governor limits in detail and how to stay under them.

Accepted Answer

Salesforce enforces hard caps per transaction. The big ones: | Limit | Sync | Async | What hits it | |---|---|---|---| | SOQL queries | 100 | 200 | Loops with SOQL | | SOQL rows | 50,000 | 50,000 | Massive single query | | DML statements | 150 | 150 | Loops with DML | | DML records | 10,000 | 10,000 | Single bulk DML | | CPU time | 10s | 60s | Heavy computation, recursive flow | | Heap size | 6 MB | 12 MB | Large collections | | Callouts | 100 | 100 | API integrations | | Future calls / queueable | 50 | 50 | Triggering many async jobs | Patterns to stay under: 1. Bulkify everything . Never SOQL or DML inside loops. Build collections, do one query/DML. 2. Use Maps for lookups , not SOQL. If you need parent records: query parents into a Map by Id, then look up in-memory. 3. Selective queries . WHERE clause must hit indexed fields. Without selectivity, queries against large tables fail or time out (separate from row limits). 4. Don't load more than you need . not . Reduces heap and SOQL row count. 5. Use QueryLocator in Batch for 50k rows. returns iterator, not a static list. 6. Async for heavy work . Move CPU/heap-heavy logic into Queueable or Batch — they get more headroom. 7. Limit

Question 21

How do you handle recursion in triggers?

Accepted Answer

Recursion — your trigger fires another DML on the same object that re-invokes the same trigger. Without protection: infinite loop, stack overflow, governor-limit exhaustion. Sources of recursion: - A trigger updates a field on Trigger.new - after-trigger fires another update - trigger fires again. - An after-update trigger updates related records, which fire their own triggers, which update back, etc. - Workflow rule + trigger circular dependency. The static flag pattern (most common): A static variable persists for the duration of one transaction. Setting it on entry and checking on subsequent entries blocks recursion. Variations: - Per-record recursion guard — track Set<Id of processed records: This lets the trigger fire for new records but skip already-processed ones in the same transaction. - Per-context-and-event guard — separate flags for , , etc., so a guard for one event doesn't block others. When NOT to suppress recursion: - If your trigger needs to react to a chain of changes (e.g., parent update - child update - parent recalc), suppressing recursion blocks the desired logic. Restructure to compute final state on the first invocation. Architectural alternative: - Move the

Question 22

What is the Platform Cache and when do you use it?

Accepted Answer

Platform Cache is Salesforce's distributed in-memory cache, accessible from Apex. It lets you store data across transactions/users to avoid redundant queries or computation. Two cache types: - Org Cache — shared across all users in the org. Use for reference data: tax rate tables, region mappings, configuration that's the same for everyone. - Session Cache — per-user. Lasts the user's session. Use for user-specific computed data: their permission profile lookup, computed dashboard tiles. API: Capacity: - Org Cache: tied to allocation purchased; default Enterprise gets a few MB, larger orgs purchase more. - Session Cache: smaller per-user. - Each value is up to 100 KB. Eviction: - Time-based via TTL. - LRU eviction when capacity hits. - Cache misses are normal — always handle null gracefully. Use cases: - Expensive query results that don't change often: country/state lists, custom metadata aggregates. - External API responses with a TTL: weather, exchange rates, third-party lookups (avoid repeated API limits). - Computed authorisation matrices per user (Session Cache). Don't use for: - Mutable user data — you can't guarantee cache freshness across users. - Anything sensitive — cache

Question 23

How do you write tests for async Apex (@future, Queueable, Batch)?

Accepted Answer

Async testing requires careful use of and to force async work to run synchronously inside the test. Pattern : Key rules: - resets governor limits for the test code that follows. Useful for isolating limit usage. - flushes async work — , Queueable, Batch jobs queued during the test all execute synchronously when is called. - Without , async work doesn't run during the test; you can't assert on its effects. Specifics by async type: : - Test calls the future method between startTest/stopTest. The work runs at stopTest. - Cannot test future call from within another future (Salesforce restriction). Queueable : - Same pattern. The Queueable's runs synchronously at stopTest. - For chained Queueables: only the FIRST chain link runs in the test. Subsequent links require additional test-method invocations or the chain is mocked. Batch Apex : - Same pattern, but the test must process records you've inserted. - returns the QueryLocator (or iterable); test setup must populate the source records. - runs once per chunk. In tests, the entire query result becomes one chunk regardless of batch size — keep test data small. - runs at the end. Common pitfalls: - Forgetting — async never runs, assertion

Question 24

Explain the differences between SOAP, REST, and Apex web services.

Accepted Answer

SOAP is an XML-based, strongly-typed protocol with a WSDL contract describing every method, input, and output. You generate a stub from the WSDL in your client language. Heavy, but provides strong contract guarantees. REST is an HTTP-based, JSON-friendly architectural style. Resources are URLs, verbs are HTTP methods (GET/POST/PATCH/DELETE), payloads are typically JSON. Lighter, more flexible, easier to consume from any language. Apex Web Services are how you expose Apex code as a callable web service. Two flavours: Apex SOAP Web Services (older): Annotated methods generate WSDL. Clients consume by importing the WSDL. Apex REST Services (modern): URL-routed, HTTP-verb-based, JSON automatically marshalled. When to use which: - Calling Salesforce from external — generally pick REST. Less ceremony, modern tooling, broad client support. - Building Apex services for external consumption — Apex REST. SOAP is largely legacy. - Calling external services from Apex (callout) — REST callout via / / . SOAP callouts work but are heavier. - Legacy systems mandating SOAP — fall back to Apex SOAP. Increasingly rare. Authentication: - OAuth — preferred. Connected App + chosen flow. - Username/Passw

Question 25

How would you architect a long-running Apex job processing 10M records?

Accepted Answer

10M records is firmly in Batch Apex territory. You can't process it in a single transaction. Architecture: 1. Implement . Three methods: , , . 2. Pick batch size carefully . — 200 is the default max. Smaller (50, 100) reduces governor pressure per execute() but increases total batches. 3. Use in for 50k records — it iterates lazily. 4. marker preserves instance variables across calls — useful for accumulating totals or referencing a master record set. 5. Bulk-pattern within — same rules: no SOQL or DML in loops; build collections; one DML per chunk. 6. Error handling per-record : 7. Recovery strategy . If a batch fails mid-flight, your query should be re-runnable — it should target only records that haven't been processed yet (e.g., plus update Status to 'Processed' in execute). 8. Schedule it . Use or Setup - Apex Classes - Schedule to fire at off-hours when org load is low. 9. Monitoring . Implement notifications on success/failure. Log job runs to a custom object. 10. Test thoroughly . Test classes can simulate one chunk. For full-scale testing, test in a Full Sandbox with realistic data volume. Trade-offs / alternatives: - Bulk API from outside — for one-time loads, consider ru

Question 26

What is a Custom Metadata Type and why use it?

Accepted Answer

Custom Metadata Types are a Salesforce data structure that looks like a custom object but stores configuration as deployable metadata. The records themselves deploy via change sets or Salesforce DX, just like fields and classes. Why use it: deployable values (no re-entering in production), automatically cached (no SOQL governor cost), queryable from Validation Rules and Formulas, packageable, and type-safe. Common use cases: feature flags, integration endpoints, region-specific business rules, mappings. Limitation: read-only at runtime. For runtime-mutable per-user data, fall back to Custom Settings.

Question 27

What is Visualforce and where does it stand today?

Accepted Answer

Visualforce is Salesforce's first-generation custom UI framework, introduced in 2008. XML-style markup compiles to HTML, with Apex controllers driving server-side logic. Each interaction round-trips to the server. Where it stands today: legacy but supported. Many existing orgs have Visualforce running. In Lightning Experience, VF pages render inside an iframe wrapper. New work should use LWC. When you'd still touch Visualforce: maintaining existing pages, Visualforce Email Templates (still useful for templating), PDF generation via (simplest server-side PDF rendering), specific platform features without LWC equivalents. Migration: many orgs are systematically rewriting Visualforce as LWC. New developers should learn LWC; familiarity with Visualforce only for legacy.

Question 28

What is a Lightning Web Component, technically?

Accepted Answer

An LWC is a UI component built on the Web Components standard — Custom Elements, Shadow DOM, ES Modules — running inside the Lightning runtime. Anatomy of an LWC bundle: - — template with directives like , . - — JavaScript class extending LightningElement, with decorators ( , , ). - — scoped styles via Shadow DOM. - — config: which contexts the component appears in, target object types. Apex integration via methods; LWC imports them and binds via . Lightning Data Service (LDS) offers cached record access without writing Apex. Comparison with React/Vue: closer to native (no virtual DOM in the same way); templates are HTML, not JSX; decorators replace hooks for reactivity. Same architectural feel: components, props, events, parent-child composition.

Question 29

What is a Static Resource and when do you use one?

Accepted Answer

A Static Resource is a file (image, JS library, CSS, ZIP) uploaded to Salesforce and accessible at a stable URL. Used to deliver static assets to Visualforce, Lightning components, Email Templates, and Communities. How to add: Setup - Static Resources - New. Upload up to 5 MB per resource. Reference via in Visualforce, or in LWC. ZIP support: upload a ZIP and reference individual paths inside. Useful for shipping a directory of related assets. Common uses: company logos, JS libraries (jQuery, D3.js), CSS frameworks, PDF templates, audio/video. Cache semantics: aggressively cached. Updating a resource keeps the same URL — browsers may serve the cached version. Workaround: bump a version field in the path, or cache-bust with a query string. Alternative: third-party CDN hosting (S3, CloudFront) for performance-critical or frequently-updated assets.

Question 30

What is the Developer Console and what is it good for?

Accepted Answer

The Developer Console is a browser-based IDE built into Salesforce. Provides Apex code editing, SOQL Query Editor, anonymous Apex execution, Apex Test Runner, debug logs viewer, heap dumps, governor-limit dashboard, file explorer, and workspace tabs. Modern reality: the Developer Console is increasingly basic. Most professional Apex/LWC development uses Salesforce Extensions for VS Code (or JetBrains Illuminated Cloud) which offer better editing, source control integration, and debugging. When to still use Dev Console: quick anonymous Apex fix (data hotfix), inspecting a debug log without local tooling, ad-hoc SOQL, quick test runs without leaving Salesforce. When to use VS Code instead: real development (multi-file editing, source control), refactoring across files, local unit-test runs (faster feedback), LWC development (Dev Console doesn't support LWC bundle structure well).

Question 31

What is the Salesforce CLI and what can you do with it?

Accepted Answer

The Salesforce CLI ( , formerly ) is a command-line tool for interacting with Salesforce orgs. Foundational for Salesforce DX and CI/CD. Common commands: Why it matters: source-driven development (track metadata in Git, deploy via CLI), CI/CD integration with GitHub Actions/GitLab/Bitbucket, scratch org provisioning for unit testing, cross-org operations, scripting. Pairs with Salesforce Extensions for VS Code (which use the CLI under the hood). VS Code is the UI; CLI is for automation. Modern Salesforce projects don't use the Setup UI for deployments — they use the CLI from version-controlled source.

Question 32

What is a Scratch Org and how does it differ from a Sandbox?

Accepted Answer

A Scratch Org is a disposable, source-controlled Salesforce org spun up from a configuration file. Lifespan up to 30 days; intended for short-lived development tasks. The config declares features, edition, namespace, language. Each scratch org is fresh — no inherited data, no inherited metadata. Differences from Sandboxes: - Scratch: from config file, up to 30 days, no data, used for feature dev. - Sandbox: from production copy, indefinite, has data (Full) or none (Dev), used for UAT/integration/regression. Why use scratch orgs: isolation per developer, reproducibility (same config = same org), CI/CD (disposable orgs for tests), feature development. Limitations: daily creation limits, not for production-realistic data testing, custom domains/SSO not always available. Modern Apex/LWC dev expects scratch orgs for new code; sandboxes are for testing and staging.

Question 33

What is Salesforce DX and what are its core concepts?

Accepted Answer

Salesforce DX (Developer Experience) is Salesforce's modern development methodology. It brings traditional software engineering practices — version control, modular code, CI/CD, scratch orgs — to the Salesforce platform. Core concepts: 1. Source-Driven Development — code and metadata in Git, not in an org. 2. Project Structure — standard layout with , , . 3. Scratch Orgs — disposable orgs from config files. 4. Dev Hub — a parent org that authorises scratch org creation. 5. Salesforce CLI — the orchestration tool. 6. Unlocked / Managed Packages — modular distribution units. 7. VS Code Extensions — UI on top of the CLI. Why DX: branch-based feature development with scratch orgs, CI/CD pipelines, modular code via Unlocked Packages, test automation, reproducible orgs from source. Migration from "click-and-deploy": extract metadata to source, set up Git, train the team, build CI pipeline, retire change sets. Worth it for any team larger than 1-2 devs.

Question 34

How does the Apex testing framework handle test data isolation?

Accepted Answer

Apex tests are isolated from existing org data by default. Tests don't see records that exist in the org; they must create their own. runs once per class, rolls back at end — efficient for shared test data. — at runtime, lets your code branch on test context. — overrides isolation. Strongly discouraged. Tests should be deterministic; if they depend on prod data, they are flaky. Test data factory pattern: a class with etc., reusable across tests.

Question 35

What is `@AuraEnabled` and how does it differ from `@InvocableMethod`?

Accepted Answer

Both annotations expose Apex to non-Apex callers, but they target different consumers. — exposes Apex to Lightning components (Aura and LWC) . LWC: then bind with . allows client-side caching (required for ). — exposes Apex to Flow Builder as a callable Apex Action. Bulk pattern is mandatory: List in, List out. Differences: caller (LWC vs Flow), bulk (single vs list), caching ( vs N/A), discovery (import vs Action element). You can have both annotations on the same method.

Question 36

How do you design Apex classes for different sharing requirements?

Accepted Answer

The design rule: be explicit about sharing context for every class . Default behaviour is fragile. Architecture pattern: separate classes by concern. - Service classes ( ) — invoked from user contexts (LWC controllers, REST endpoints). Respect user's sharing. - Repository classes ( or ) — encapsulate SOQL/DML. Inherited sharing lets caller decide. - System utilities ( ) — when system needs full access (audit logging, etc.). Common mistake: putting everything in one large class. Then a system task that genuinely needs full access can't run, or you sprinkle everywhere. Mixing in the same call chain: Apex respects each class's sharing setting for its own SOQL/DML , regardless of caller. Test mode: tests run as System Administrator unless wrapped in . Test sharing-relevant code by running as a non-admin user.

Question 37

What is the difference between SOQL and Aggregate SOQL?

Accepted Answer

Aggregate SOQL uses to compute per-group results — sums, counts, averages — and returns objects instead of sObjects. Aggregates run on the server; you get one row per group. Vastly fewer rows. Key features: , , , , , . on any field. for post-aggregation filtering. for multi-level aggregation. Limits: 2000 rows from aggregate queries. Aliases needed for aggregate functions. When to use: reporting/dashboards, performance (fewer rows), avoiding row limits on large queries. A common pattern: replace a "sum by category" Apex loop with to dodge governor limits.

Question 38

What is a Managed Package and what are the implications for developers?

Accepted Answer

A Managed Package is a distribution unit ISVs publish on the AppExchange. Once installed, components carry the publisher namespace prefix and are upgrade-managed. Key developer implications: 1. Namespace prefix : every API name is prefixed ( ). Code outside the package referencing these names must include the prefix. 2. Code is hidden : customers can't see your Apex source. 3. Schema is partially open : customers can add fields to packaged objects but can't remove the packaged ones. 4. Versioned upgrades : new versions install over old; can add fields/classes; can't easily remove without deprecation. 5. Global vs Public APIs : only Apex is accessible from outside the namespace. Be deliberate. 6. Test coverage : package code must have 75% test coverage with tests included. 7. Subscriber sharing : package code respects installing org sharing if . 8. Package limits : managed packages have their own limits separate from customer's org limits. For developers: architect for upgradability, use Unlocked Packages for internal modular dev, test in real subscriber orgs, version interfaces. For developers in customer orgs with packages: don't depend on internals (only is stable), reference by

Question 39

How does Apex handle exceptions and what is the Exception class hierarchy?

Accepted Answer

Apex follows Java-style try/catch/finally. The Exception hierarchy includes (base), , , , , , , , , etc. DmlException specifics: , , , . Custom exceptions: then throw with custom message. Critical caveats: - is mostly UNCATCHABLE — when you hit a governor limit, the transaction terminates. Don't rely on catching it. - Database.insert with allOrNone=false — errors return in , not exceptions. - Async job exceptions — uncaught exceptions in Future/Queueable/Batch get logged and emailed; they don't propagate back. In production, route exceptions to a custom object for forensics.

Question 40

When would you choose an Apex Trigger over a Record-Triggered Flow?

Accepted Answer

With Record-Triggered Flows now mature, the boundary has shifted. The decision pivots on complexity and performance. Choose Flow when: - Logic is straightforward field updates, related-record creates/updates. - Logic is conditional but expressible in Decision elements. - The team doesn't have a developer to maintain Apex. - Future modifications likely come from admins. - Performance demands are typical. Choose Apex Trigger when: - Performance-critical — hot-path triggers on millions of records. - Complex bulk patterns — flows that loop and modify collections get complicated. - Custom error handling — partial-success logic. - Recursion-aware logic — Apex's static state pattern is cleaner. - Cross-object atomic transactions — Apex's transaction model is more predictable. - Apex Managed Sharing — flows can't write to tables. - Complex callouts — multiple HTTP calls with conditional branching. Mixed pattern (often best): Flow at the entry point (orchestration, simple decisions), Apex Invocable Method called from Flow for heavy lifting. Admins can tweak orchestration; developers own the logic. Anti-patterns: Apex Trigger AND a Record-Triggered Flow on the same object firing the same log

Question 41

How would you handle an integration that needs to call an external API for 100 records?

Accepted Answer

The naive approach — call the API once per record in a loop — fails fast: governor limit of 100 callouts per transaction. Better patterns: 1. Batch API on the external side — if the external API supports batch endpoints, send all 100 in one call. Done. 2. Async chunking via Batch Apex — implement . Each chunk has its own callout limit. Use batch size 100 or less. 3. Composite API on the Salesforce side — if external systems are calling Salesforce, Composite API bundles multiple subrequests as one HTTP call. 4. Queueable chain — a Queueable that processes a chunk and chains the next, processing 50 records per chain link. Good when Batch interface doesn't fit. 5. Platform Events to decouple — publish an event per record; an external subscriber processes asynchronously. Decouples Salesforce from external availability. Always: mark for async; handle errors per-record (log to custom object); don't make blocking callouts in trigger context (use or queue to async); respect external rate limits.

Question 42

From a developer perspective, when do you pick Custom Settings over Custom Metadata?

Accepted Answer

Both are config patterns. The decision pivots on mutability and deployability . Custom Metadata Types are deployable as metadata; their records deploy. Read-only at runtime. Cached automatically. Custom Settings are runtime-mutable. Records do NOT deploy with metadata — you re-enter values in production. Two flavours: Hierarchy (per-org/profile/user) and List (singleton table). When to pick Custom Metadata : configuration that should ship with codebase (feature flags, integration endpoints, region rules), read-only at runtime, multi-org consistency, packageable. When to pick Custom Settings : mutable at runtime (Apex needs to write), per-user/per-profile overrides (Hierarchy is great for this), personalisation. Practical default : pick Custom Metadata for almost all new configuration. Only fall back to Custom Settings when you need runtime-write or per-user values. Common mistake: using Custom Settings for static config because dev learned them first, then discovering production deployment requires manual re-entry — causing drift.

Question 43

Walk me through writing a custom REST endpoint in Apex for an external system.

Accepted Answer

Apex REST exposes a method as an HTTP endpoint that external systems can call. URL: . Authentication: OAuth bearer token via Connected App. Error handling: set and serialise an error object as the response body. Critical considerations: with sharing enforces user record access; governor limits apply per request; request size cap; versioning is mandatory ( , ); document via OpenAPI; rate limits eat into the org's daily API quota. Testing: build / mocks in test methods, call the static method directly, assert results. Clean, versioned, well-tested REST endpoints are foundational deliverables for Salesforce integration work.

Question 44

How do you handle large file uploads and downloads in Apex?

Accepted Answer

Files in Apex are tricky because of heap limits (6 MB sync, 12 MB async) and request size limits. Salesforce file primitives: (binary, capped at heap), (versioned file record), / (parent + links). Upload patterns: 1. Direct upload via REST API (file transferred to Salesforce, not through Apex): external system POSTs to with multipart/form-data. Salesforce stores it; your Apex doesn't see the binary. Best for large files. 2. Chunked upload through Apex : client splits file into chunks (each <6 MB), sends one at a time. Apex appends. Heap concerns — concatenating Blobs has the same 6 MB cap. 3. Salesforce Files Connect or external storage : files 2 GB go to S3, Box, SharePoint via Files Connect. Salesforce holds metadata; binary lives elsewhere. Download patterns: for files near heap limit, return a redirect URL pointing to the file's direct ContentVersion endpoint, let client download from there. Practical advice: files 2 MB never load into Apex heap; files <2 MB Apex Blob is fine; use async (Batch/Queueable) for any heavy file operation (12 MB heap doubles headroom); avoid holding multiple large Blobs simultaneously.

Question 45

From a transaction-state perspective, what is the difference between @future, Queueable, and Batch?

Accepted Answer

All three run async, but they handle state differently — and that affects what is possible. — stateless. Method signature accepts only primitive types and collections of primitives (Id, String, Integer). Cannot accept sObjects directly. Why: when the future fires, original sObjects may be stale. Salesforce avoids inconsistency by disallowing sObject parameters. Queueable — stateful. The class is instantiated with member variables, and the entire instance state is preserved into the async execution. You can pass sObjects, custom Apex classes, complex types through the constructor. Batch Apex — chunk-stateful with marker. By default, each call gets a fresh instance. With , member variables persist across executes. Implications: - — limited usefulness when complex data needed. Fire-and-forget callouts and primitives. - Queueable — modern choice for most async work. Pass any data, chain jobs, simpler to test. - Batch — chunks large data with cross-chunk state via . Recommendation: prefer Queueable as default async; reach for only for simple callouts (legacy patterns); use Batch for 10k records.

Question 46

How do you architect Apex code for a multi-tenant managed package?

Accepted Answer

Building for an unknown set of subscribing orgs imposes design constraints beyond a single-org build. Key considerations: 1. Namespace awareness — all custom objects/fields/classes carry your namespace. Cross-namespace references require dynamic SOQL. 2. Bulkified by default — subscribers can have wildly different data volumes. 3. Sharing model neutral — default to ; opt out only for legitimate system tasks. 4. Governor limits leave room for subscriber — aim to use 30% or less of limits; the customer's own automation also consumes them. 5. No dependencies on subscriber-specific metadata — use for dynamic field access. 6. Test data factory inside package — subscribers may have validation rules that break naive test setup. 7. Forward compatibility — subscribers will be on different versions. Avoid breaking changes; deprecate, don't remove. 8. is permanent — once exposed, you can't change the signature. Be deliberate. 9. Trigger handler discipline — one trigger per object. 10. Error handling — throw custom exceptions; subscribers need to debug your package. 11. Configurable behaviour — Custom Metadata Types let subscribers tune without forking. 12. Performance budgets — each method co

Question 47

Walk me through writing a complex SOQL query with multiple joins, aggregations, and bind variables.

Accepted Answer

A real-world scenario: "find all open Opportunities owned by users on a list of teams, where the Account has at least one open Case, grouped by Stage with counts." Key features: 1. Bind variables ( , ) — Apex variables prefixed with . Parameterised, type-safe, injection-protected. 2. Subquery in IN (semi-join) — Salesforce SOQL's IN-subquery. One level deep only. 3. Date arithmetic — Apex Date binds to SOQL date. 4. Aggregate — with . Aliases for AggregateResult access. 5. ORDER BY on aggregate . Dynamic SOQL when runtime-built: build the WHERE clause as a string, use . Always use bind variables ( ) or on raw user input. SOQL Injection protection: static SOQL with bind variables = automatic protection; dynamic SOQL with concatenation = vulnerable. Always parameterise. Performance gotchas: non-selective subqueries against large tables are slow; multiple subqueries add load; aggregate row limit is 2000.

Question 48

How do you debug a complex interaction between a Flow and an Apex Trigger?

Accepted Answer

When a record save fires both a Record-Triggered Flow and an Apex Trigger, debugging requires layering observability. Diagnostic order: 1. Establish the order — refer to the Order of Execution. Before-save flows fire before validation rules; after-save flows fire after triggers. 2. Enable debug logs for the running user. Setup - Debug Logs - Add User. Set Apex Code to FINE+ and Workflow to FINE. 3. Reproduce the issue. 4. Read the debug log. Look for , , , , , . The interleaved log shows exact order. 5. Check for re-entry — trigger updates a field, after-save flow detects, fires another save, trigger re-runs. Use static recursion guards in trigger; use checks in flow. 6. Use Flow Builder Debug — replay flow with same input, step element by element. 7. Test isolated — disable trigger temporarily; reproduce. Disable flow; reproduce. Each in isolation tells you what each contributes. 8. Add explicit logging — in trigger; insertion in flow. Common failure modes: field updates fight each other (both write same field); validation rule fires twice (workflow re-fires); async fires before trigger commits (events publish on commit-2). Resolution: pick one owner per field; use before-save flo

Question 49

What is the difference between immediate, time-based, and scheduled actions in Salesforce, implementation-level?

Accepted Answer

Three categories of "do something at a specific moment", each with different mechanisms. Immediate actions — fire as part of the saving transaction. Triggers, Validation Rules, Before-Save Flows, After-Save Flows. User sees effect on same UI render. Time-based actions — scheduled to fire at a future time relative to the record state (e.g., "7 days after Close Date"). Bound to record lifecycle. - Workflow Time-Based Actions (legacy) — defined in a Workflow Rule. Fire in a queue. - Scheduled Paths in Record-Triggered Flows (modern) — defined within the flow. Action fires at the scheduled point. - Approval Process re-evaluation — after time delay. Time-based items sit in the time-based workflow queue (Setup - Monitor - Time-Based Workflow). Tied to record state; if criteria no longer hold, items are removed. Scheduled Apex / Schedulable — fire at a fixed cron-style time, independent of record lifecycle. Scheduled Flows — declarative analogue. Configure schedule and optional record query. Decision: fire on save = Trigger/Flow; X days after record event = Scheduled Path; fixed cron = Schedulable Apex or Scheduled Flow; after time elapses on record = Time-Based Workflow or Scheduled Path

Question 50

How do you implement Salesforce DX-driven CI/CD for an Apex/LWC project?

Accepted Answer

A complete CI/CD setup for a Salesforce DX project, with GitHub Actions as the example runner. Pipeline phases: 1. PR validation pipeline (runs on pull request) — checkout code, install Salesforce CLI, authenticate to dev hub via stored auth URL, create scratch org from , deploy source, run all Apex tests with code coverage, delete scratch org. Failures block merge. 2. UAT deploy pipeline (runs on merge to develop branch) — auth to UAT sandbox, run validate-only deploy first (catches issues without commit), then deploy with all tests. 3. Production deploy pipeline (runs on merge to main, with manual approval gate) — uses GitHub Environments to require human approval before production deploy. Always run all tests on production deploys. 4. Quality gates: - Apex test coverage enforced at 75% via . Fail pipeline if below. - PMD / ESLint static analysis on Apex / LWC. - Pre-commit hooks (Husky + Prettier) for code style. 5. Secrets management: - Store auth tokens for each org (DevHub, UAT, Prod) as GitHub Secrets, referenced by the workflow. - Use JWT-based auth for headless CI: register a private key in a Connected App, sign JWT tokens for CLI auth. 6. Advanced patterns: - Unlocked Pac

Question 51

What is Lightning Data Service (LDS) and when do you use it?

Accepted Answer

Lightning Data Service (LDS) is a Salesforce-managed cache and CRUD layer for record data, accessible from LWC without writing Apex. LDS provides: - — fetch a record's fields with cached, FLS-aware results. - / — get layout-aware metadata for record creation/edit. - / / — CRUD without Apex. - — invalidate cache to force refresh. When to use LDS: simple read/edit on a single record, you want FLS/sharing automatically respected, you don't need cross-object queries. When to use Apex instead: complex SOQL (joins, aggregates), cross-object logic, custom business rules before save, bulk operations, integrations. Bonus: LDS shares its cache across all components on a page, so multiple components viewing the same record share data without duplicate API calls.

Question 52

How do LWC components communicate with each other?

Accepted Answer

Three patterns, each appropriate for different relationships. 1. Parent-to-Child via @api properties. Parent passes data via attributes; child receives via decorated properties. 2. Child-to-Parent via Custom Events. Child dispatches ; parent listens. 3. Sibling-to-Sibling via Lightning Message Service (LMS). Components in different DOM trees use a Message Channel for pub-sub. LMS works across Aura/LWC/Visualforce on the same page, making it the universal sibling-communication channel. Decision tree: parent- child = ; child- parent = CustomEvent; siblings = LMS. Avoid: directly manipulating sibling components (anti-pattern); using DOM events for cross-tree communication (won't propagate).

Question 53

How do you serialize and deserialize JSON in Apex?

Accepted Answer

Apex provides the class for converting between Apex objects and JSON strings. Serialize : Deserialize : Important nuances: - Field names are case-sensitive for type-safe deserialization. matches the casing exactly. Use or transform the JSON if external systems use different casing. - fails if JSON has fields not in the class (catches typos). - includes nulls by default . Use to suppress nulls. - Lists, Maps, nested objects all serialize naturally. - DateTime serializes as ISO 8601 string. Common use cases: REST callouts (request body, response parsing), Platform Event payloads, custom serialization for archival.

Question 54

How do you make an HTTP callout from Apex?

Accepted Answer

The standard pattern uses , , and classes. Critical practices: - Use Named Credentials ( ) instead of hard-coded URLs — auth headers handled automatically. - Set timeouts — default is 10s; bump to 20-30s for slow endpoints. Max is 2 minutes. - Handle errors — check status code, log failures, retry idempotent operations. - Catch for network failures. - Async required when called from triggers — synchronous callouts are blocked in trigger context. Use or Queueable. Mock callouts in tests: Tests can't make real callouts; mocks are mandatory.

Question 55

How does Apex handle DateTime, Date, and Time, and what are common pitfalls?

Accepted Answer

Three distinct types: - Date — calendar date with no time (e.g., ). - Time — clock time with no date. - DateTime — date + time + timezone. Critical timezone behaviour: - returns current time in GMT/UTC . - returns today in the running user's timezone . - etc. operate in the user's timezone. This split causes confusion: a job running at "midnight UTC" and a job running at "midnight in user's timezone" can fire at different times. Comparing : Formatting : Parsing : Common pitfalls: - Mixing user-timezone and UTC when computing differences. - SOQL date literals ( , ) honour user timezone — same query gives different results for users in different zones. - Daylight saving transitions can cause hour-arithmetic surprises. Always: store DateTime as UTC; convert to user timezone only for display.

Question 56

What are the differences between List, Set, and Map in Apex, and when do you use each?

Accepted Answer

Three core collection types: List : Ordered, allows duplicates, indexed. Good for: SOQL results, processing in sequence, when order matters. Set : Unordered, no duplicates , no index. Good for: deduplication, fast checks, building IN clauses. Map : Key-value pairs, fast lookup by key, no duplicate keys. Good for: relating records by Id, in-memory joins, caching. Conversion patterns: - List of Ids from List of records : — clever idiom. - List from Set : . - Set from List (dedupe): . Performance: - List access by index : O(1). - List : O(n) — slow for large lists. - Set : O(1). - Map : O(1). Rule: never call inside a loop that iterates over another list — use a Set for that. Bulk pattern building blocks : - — accumulate. - — fetch as Map. - Loop, call — O(1).

Question 57

What are Schema describe calls and when do you use them?

Accepted Answer

Schema is the namespace for runtime metadata access in Apex. Describe calls let your code inspect objects, fields, and picklist values without hard-coding API names. Common patterns: Use cases: - Generic framework code that operates on any object — no hard-coded field names. - Dynamic SOQL — build query strings from describe results. - FLS checks — verify the running user can access fields before reading/writing. - Picklist value validation — confirm an inbound value is a valid picklist entry. - Schema introspection tools — admin utilities that report on org structure. Performance : describe calls are cached in Apex transaction. First call is slower; subsequent calls in the same transaction are essentially free. Can also use Limits.getDescribeRows() to monitor. Test data factories that work for any object commonly use describe calls to figure out which required fields need values.

Question 58

How do you publish and consume Platform Events from Apex?

Accepted Answer

Platform Events are the Salesforce Pub/Sub mechanism. You define an event type as metadata (with suffix), publish events from Apex/Flow, and consume them from Apex triggers, Flows, or external clients. Define the event (one-time setup): Setup - Platform Events - New. Add fields like , , . The event becomes . Publish from Apex : Consume via Trigger (triggers are the most common subscriber): External subscribers : connect to the Pub/Sub API (or older Streaming API/CometD) to receive events in near-real-time. Key behaviour: - Asynchronous — queues the event; subscribers run separately. - At-least-once delivery — events may be delivered more than once; subscribers must be idempotent. - 72-hour retention — events available to subscribers for 72 hours via replay. - Publishing in a transaction — by default, publish happens on commit-2 (after success). For "fire and forget regardless of outcome", use operation type when defining the event. Use cases: - System-to-system signalling — "OrderApproved" event triggers downstream fulfilment. - Decoupled architecture — module A publishes, modules B and C consume independently. - Bridging Salesforce to external — external middleware subscribes via

Question 59

What is Change Data Capture and how does it differ from Platform Events?

Accepted Answer

Change Data Capture (CDC) is Salesforce's built-in event stream of record-level changes on enabled objects. When a record is created, updated, undeleted, or deleted, an event is published describing what changed. Setup : Setup - Change Data Capture - select objects to enable. CDC is opt-in per object. Event format — each event includes: - The change type (CREATE / UPDATE / UNDELETE / DELETE). - The record's Id. - A list of changed fields with their new values. - Header metadata (timestamp, transaction Id, change origin user). Consume from Apex : Differences from Platform Events : - Schema — Platform Events are user-defined; CDC events are auto-generated from the source object's schema (Salesforce determines fields). - Trigger — Platform Events are explicitly published from code/flow; CDC events fire automatically on every record change. - Retention — both 72 hours. - Use case — Platform Events for custom semantic signals ("OrderApproved"); CDC for "tell me when records change". Common consumers : - External replication — middleware subscribes via Pub/Sub API and writes changes to Snowflake/BigQuery. - Real-time integrations — system-of-record sync. - Audit logging — comprehensive r

Question 60

How do you migrate Visualforce pages to LWC at scale?

Accepted Answer

The migration is rarely a like-for-like rewrite — Visualforce and LWC have different paradigms. The strategy: Inventory phase: 1. List every Visualforce page in the org (Setup - Visualforce Pages). 2. Categorise: simple display pages, controller-heavy interactive pages, PDF generators, embedded utilities. 3. Identify which can be deprecated (replaced by Lightning Record Pages, Path, or out-of-the-box features) vs which need a real LWC equivalent. Per-page rewrite: 1. Simplify scope . Visualforce pages often pile multiple features onto one page. Each LWC component should do one thing well. 2. Decompose — split the VF page into a parent LWC plus child components for distinct concerns (header, list, form, footer). 3. Replace controller logic : - Standard controllers - Lightning Data Service / . - Custom controllers - Apex methods called via or imperatively. - Visualforce-specific tags ( , ) - Lightning Base Components ( , ). 4. Replace remoting and AJAX - async/await on imperative calls. 5. Replace ViewState — LWC has no ViewState. State lives on the client; you store in component reactive properties. 6. Replace inline styles - SLDS classes or scoped CSS. 7. Test in Lightning Experien

Question 61

What are Streaming API, CometD, and the Pub/Sub API, and when do you use them?

Accepted Answer

Three generations of Salesforce real-time event delivery for external clients. Streaming API (CometD) — original real-time event channel. Uses CometD long-polling under the hood. Channels are URLs like or . Client establishes a session, subscribes to channels, receives events. Strengths: well-supported across many languages, browser-friendly via SocketJS or similar. Weaknesses: long-polling is heavier than modern protocols, replay-from-id has limits, scaling beyond a few hundred concurrent subscribers gets expensive. Pub/Sub API (newer) — a gRPC-based bidirectional stream. Replaces CometD as the modern protocol for high-volume, high-throughput event subscription. Strengths: lower latency, higher throughput, native streaming over HTTP/2, better replay support, Schema registry integration. Weaknesses: gRPC tooling is newer for some languages; Salesforce documentation still maturing. When to use which: - External middleware (Mulesoft, Snowflake CDC connectors) — these prefer Pub/Sub API now. - Custom integrations in Java/Python/Node — Pub/Sub API for new builds. - Browser-based subscribers — CometD/Streaming API still works; Pub/Sub API is more for backend-to-backend. - Legacy code ru

Question 62

What are the canonical Apex bulk patterns?

Accepted Answer

Bulk-safe code is the difference between an Apex class that works in unit tests and one that survives 200-record DML batches. Pattern 1: Single SOQL outside the loop. Pattern 2: Single DML at the end. Pattern 3: Map for O(1) lookups. Pattern 4: Set for membership. Pattern 5: Aggregate when summing. Use instead of looping to sum amounts. Pattern 6: Bulk-safe DML. Use for partial-success when bulk inserting potentially-bad records. Pattern 7: Don't pass single records. Methods accept and return Lists, not individuals. Forces bulk-thinking. Pattern 8: Static caching. Within a transaction, cache expensive describe/SOQL results in static Maps. Anti-patterns : - SOQL/DML inside loops. - inside loops (O(n²)). - Querying related records one at a time. - Single-record signatures forcing callers to loop. The bulk discipline is what separates Apex code from script-style code.

Question 63

What is Dynamic Apex and when do you use it?

Accepted Answer

Dynamic Apex means writing code that operates on runtime-determined types and metadata, rather than hard-coded references. Dynamic SOQL : Use when the object/field names aren't known at compile time. Always parameterise user input — concatenating raw user input into the query opens SOQL injection vulnerabilities. Dynamic DML : Dynamic describe : Type.forName for runtime instantiation : Used in framework code that needs to dispatch to handlers by name. When to use: - Generic framework code that operates on any object — trigger frameworks, audit utilities. - Configurable behaviour where the field/object is named in Custom Metadata. - Multi-org apps where customers add their own fields. - Schema introspection tools. When NOT to use: - Performance-critical paths — dynamic dispatch is slower than direct method calls. - When the type is known — direct typed references are more readable, type-safe, and refactor-friendly. Common pitfalls: - SOQL injection — never concatenate untrusted input. Use bind variables ( ) or . - FLS bypass — Dynamic SOQL doesn't automatically respect FLS. Use to filter. - Test coverage — dynamic code paths are easy to miss in tests. Modern guidance: prefer typed A

Question 64

What are the patterns for high-quality Apex unit tests?

Accepted Answer

Beyond just hitting 75% coverage — meaningful tests follow recognisable patterns. Pattern 1: Arrange / Act / Assert (AAA). Pattern 2: Test data factory. Reusable, factory accepts overrides for variations. Pattern 3: Bulk testing. Always test with at least 200 records to confirm bulkification. Pattern 4: Negative testing. Confirm errors fire for bad input. Pattern 5: Mock externals. Pattern 6: System.runAs for permission tests. Pattern 7: Assert messages. Always include a meaningful message in assertions. Anti-patterns: - — tests depending on org data are flaky. - "Coverage tests" with no assertions — pump up coverage without verifying behaviour. - Tests with no setup that pass against any code change — they aren't testing anything. - Tests with hard-coded Ids — break in any new org. - Tests that depend on order of execution — non-deterministic. A good test reads like specification: "given X, when Y, then Z."

Salesforce Developer interview questions

Top 10 must-know

All 100 questions

Easy

Medium

Hard

Top 10 must-know

1What is Apex and how does it differ from Java?easy

2What is SOQL and how does it differ from SQL?easy

3What is an Apex Trigger and what are trigger context variables?easy

4How do you bulkify a trigger and why does it matter?medium

5What are the async options in Apex (@future, Queueable, Batch, Schedulable) and when use each?medium

6What's the order of execution within a trigger transaction?medium

7Walk me through writing a properly bulkified trigger handler.hard

8Walk me through Apex governor limits in detail and how to stay under them.hard

9How do you design Apex classes for different sharing requirements?medium

10What are the canonical Apex bulk patterns?medium

All 100 questions

Easy

What is Apex and how does it differ from Java?easy

What is SOQL and how does it differ from SQL?easy

What is an Apex Trigger and what are trigger context variables?easy

What is the difference between SOQL and SOSL?easy

What is DML in Apex and what are its limits?easy

What is an sObject in Apex?easy

What's the difference between Lightning Web Components (LWC) and Aura Components?easy

What is an Apex Test Class and why is it required?easy

What is a Custom Metadata Type and why use it?easy

What is Visualforce and where does it stand today?easy

What is a Lightning Web Component, technically?easy

What is a Static Resource and when do you use one?easy

What is the Developer Console and what is it good for?easy

What is the Salesforce CLI and what can you do with it?easy

What is a Scratch Org and how does it differ from a Sandbox?easy

What is Salesforce DX and what are its core concepts?easy

What is Lightning Data Service (LDS) and when do you use it?easy

How do LWC components communicate with each other?easy

How do you serialize and deserialize JSON in Apex?easy

How do you make an HTTP callout from Apex?easy

How does Apex handle DateTime, Date, and Time, and what are common pitfalls?easy

What are the differences between List, Set, and Map in Apex, and when do you use each?easy

What are Schema describe calls and when do you use them?easy

What is Salesforce Connect and what are External Objects?easy

What is the Custom Notification API and how do you use it from Apex?easy

How do you send email from Apex?easy

What is Salesforce Functions / Heroku integration?easy

How do you handle inbound webhooks in Salesforce?easy

Medium

How do you bulkify a trigger and why does it matter?medium

What's the difference between database.insert() and the insert statement?medium

What are the async options in Apex (@future, Queueable, Batch, Schedulable) and when use each?medium

What's the order of execution within a trigger transaction?medium

How do governor limits differ between synchronous and asynchronous Apex?medium

What is a Wrapper Class in Apex and when do you use one?medium

What are the differences between static, instance, and global methods in Apex?medium

How does Apex handle null values, and what patterns help avoid NullPointerException?medium

What's the difference between `with sharing`, `without sharing`, and `inherited sharing` in Apex?medium

How does the Apex testing framework handle test data isolation?medium

What is `@AuraEnabled` and how does it differ from `@InvocableMethod`?medium

How do you design Apex classes for different sharing requirements?medium

What is the difference between SOQL and Aggregate SOQL?medium

What is a Managed Package and what are the implications for developers?medium

How does Apex handle exceptions and what is the Exception class hierarchy?medium

When would you choose an Apex Trigger over a Record-Triggered Flow?medium

How would you handle an integration that needs to call an external API for 100 records?medium

From a developer perspective, when do you pick Custom Settings over Custom Metadata?medium

How do you publish and consume Platform Events from Apex?medium

What is Change Data Capture and how does it differ from Platform Events?medium

How do you migrate Visualforce pages to LWC at scale?medium

What are Streaming API, CometD, and the Pub/Sub API, and when do you use them?medium

What are the canonical Apex bulk patterns?medium

What is Dynamic Apex and when do you use it?medium

What are the patterns for high-quality Apex unit tests?medium

How do you implement Apex Managed Sharing in code?medium

Why can't you make HTTP callouts directly from a trigger, and how do you work around it?medium

How do you avoid "soup" in a growing Apex codebase — what design patterns help?medium

How would you build a typeahead search component in LWC + Apex?medium

What is the Apex Recipes repository and what patterns does it teach?medium

How do you mock dependencies in Apex tests beyond HTTP callouts?medium

How do you implement feature toggles in Apex?medium

What is a Salesforce DX shape and what does it represent?medium

How does Apex parse complex/nested JSON?medium

Hard

Walk me through writing a properly bulkified trigger handler.hard

How do you debug a SOQL query returning unexpected results in Apex?hard

Walk me through Apex governor limits in detail and how to stay under them.hard