USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. When should you use configuration (clicks) vs code (Apex) in Salesforce?
Short answer: Prefer declarative tools; use Apex only when config can’t meet the requirement.
Strong answer: Salesforce best practice is "clicks before code": use declarative tools (Flow, validation rules, formula fields, automation) first because they’re easier to maintain and upgrade-safe. Use Apex/LWC when logic exceeds declarative limits (complex transactions, bulk logic, callouts, advanced UI). Overusing code adds maintenance burden.
Likely follow-up: What can Flow do that used to require Apex?
What the interviewer is checking: Platform philosophy.
Common mistake: Writing Apex for what Flow/config can handle.
Q2. What are Salesforce governor limits and why do they exist?
Short answer: Per-transaction limits (SOQL, DML, CPU) enforcing multi-tenant fairness.
Strong answer: Because Salesforce is multi-tenant, governor limits cap per-transaction resource use — SOQL queries (100), DML statements (150), CPU time, heap, etc. — so no tenant monopolizes shared resources. Code must be bulkified (handle collections, no queries/DML in loops) to stay within limits. Hitting limits is a top cause of failures.
Likely follow-up: How does bulkification keep you within limits?
What the interviewer is checking: Core platform constraint.
Common mistake: Putting SOQL/DML inside loops and blowing limits.
Q3. What does it mean to write bulkified Apex?
Short answer: Handle many records at once — no SOQL/DML inside loops.
Strong answer: Bulkified Apex processes collections of records efficiently: query once for all needed data, operate in memory, and perform DML on lists outside loops. Triggers must handle batches (up to 200 records) because Salesforce invokes them in bulk. Non-bulkified code fails as soon as volume rises. It’s the number-one Apix best practice.
Likely follow-up: Why do triggers need to handle 200 records at once?
What the interviewer is checking: Apex best practice.
Common mistake: Writing per-record logic that queries inside loops.
Q4. Explain Apex triggers and best practices.
Short answer: Before/after DML logic; use one trigger per object with a handler and bulk-safe logic.
Strong answer: Triggers run on DML events (before/after insert/update/delete). Best practices: one trigger per object delegating to a handler class, bulk-safe logic (no SOQL/DML in loops), avoid recursion (static flags), keep logic out of the trigger body, and respect order of execution. This keeps automation predictable and maintainable.
Likely follow-up: Why one trigger per object rather than many?
What the interviewer is checking: Apex architecture.
Common mistake: Multiple triggers per object with logic in the trigger body.
Q5. What are Lightning Web Components (LWC)?
Short answer: Modern, standards-based web components for building Salesforce UI.
Strong answer: LWC is Salesforce’s modern UI framework built on web-standards (custom elements, shadow DOM, modern JS), replacing much of Aura. It’s performant and interoperable, communicates with Apex/wire services for data, and follows a component model. Knowing LWC (and when to use it vs Flow/config) is expected for developer roles.
Likely follow-up: How does an LWC get data from Salesforce?
What the interviewer is checking: Modern SF development.
Common mistake: Only knowing legacy Visualforce/Aura.
Q6. How do you secure data in Salesforce (sharing model)?
Short answer: Org-wide defaults, roles, sharing rules, profiles/permission sets, and field-level security.
Strong answer: Salesforce security layers: object/field access via profiles and permission sets, and record access via org-wide defaults (baseline), role hierarchy, sharing rules and manual/Apex sharing. FLS controls fields. Understanding how these combine (most permissive record access wins within the sharing model) is essential and a common interview topic.
Likely follow-up: What’s the difference between a profile and a sharing rule?
What the interviewer is checking: Security model depth.
Common mistake: Confusing object/field permissions with record-level sharing.