1) What happens if you call refreshApex()
but don’t keep a reference to the wired result object?
-
refreshApex()
needs the object returned by the wire service (the “wired result”) to know what to refresh. -
If you don’t store it (e.g.,
this.wiredResult = result
),refreshApex()
won’t know what to refresh and nothing happens. -
Best practice: always store the wired result from the wire function if you plan to refresh it later.
2) What happens if you put a large console.log()
inside renderedCallback()
without any condition?
-
renderedCallback()
runs every time the component re-renders. -
If you log a big object there with no guard, you’ll flood the browser console, slow the page, and potentially freeze the tab.
-
Best practice: use a flag to run heavy code in
renderedCallback()
only once or when really needed.
3) What happens if your LWC component has an infinite loop of property updates between parent and child via @api
?
-
Parent changes a property → child reacts and sends an update back to parent → parent changes property again → infinite loop.
-
Result: performance issues, repeated renders, sometimes “Maximum call stack size exceeded” errors.
-
Best practice: debounce or compare old/new values before updating, break the loop.
🔷 Apex Questions
1) How do you ensure an Apex class can run in both synchronous and asynchronous contexts?
-
Write the business logic in a separate method/class that doesn’t depend on context.
-
Then call it from synchronous code or from Queueable/Batchable/Future.
-
Optionally check
System.isFuture()
/System.isQueueable()
to change behaviour if needed (e.g., smaller batch sizes synchronously).
2) What happens if you try to send 20,000 emails in a single transaction using Messaging.sendEmail()
?
-
You’ll hit the governor limit: max 10 single emails or 5,000 recipients per day per org (depending on email type).
-
The transaction will throw a
LimitException
. -
Best practice: batch your sends across multiple transactions or use an Email Service / Marketing Cloud.
3) What happens if you call System.debug()
with a very large string (e.g., 10 MB) in a production org?
-
Salesforce truncates logs; debug statements are cut off.
-
Large logs slow execution and may hit the 20 MB log size limit, causing “maximum debug log size reached”.
-
Best practice: log only key info or break large logs into smaller chunks.
🔷 Integration Questions
1) How do you handle retries in Salesforce when an external system is temporarily unavailable?
-
Implement retry logic in your Queueable/Batch jobs or Platform Event subscribers.
-
Use exponential backoff and idempotency keys to avoid duplicates.
-
If retries fail, push the message to a dead-letter queue or log table for manual reprocessing.
2) How do you secure outbound callouts without exposing credentials in Apex code?
-
Use Named Credentials (and External Credentials in the new model).
-
This stores the endpoint and authentication securely; Apex code only calls the alias (
callout:MyNamedCredential
). -
Never hard-code usernames/passwords or tokens in Apex.
3) How do you enforce API rate limits in integrations?
-
Track calls per time window (custom object or in memory cache) and throttle when close to the limit.
-
Use Bulk API for batch operations.
-
For inbound APIs, set limits on the external system or use middleware with built-in throttling/queuing.
-
Always check
Limits.getCallouts()
or response headers to adjust behaviour dynamically.
Post a Comment