Salesforce interview prep · Part 7 of 7

Salesforce Cheat Sheet: Limits and Key Facts

The numbers and facts to revise the night before a Salesforce interview: governor limits, async Apex, trigger context, security, testing and sandboxes.

By Bhanu Pratap SinghLast reviewed 2026-10-2310 min read7 questions4 Beginner3 Intermediate
Level

The last part is for revision: the numbers and rules interviewers expect you to know without looking them up, each with why it matters. Read it the night before.

Q1BeginnerLimits

Which per-transaction limits should you know by heart?

1What it is

The governor limits every synchronous and asynchronous Apex transaction runs inside.

2Why it matters

Almost every code question ends with "and what limit would this hit?". Knowing the numbers lets you answer at once - and design around them.

3Example

LimitSyncAsync
SOQL queries100200
Query rows50,00050,000
SOSL searches2020
DML statements150150
DML rows10,00010,000
CPU time10 s60 s
Heap6 MB12 MB
Callouts / total callout time100 / 120 s100 / 120 s
sendEmail calls1010
Trigger depth1616

4In short - say this in the interview

100 SOQL (200 async), 50,000 query rows, 150 DML statements, 10,000 DML rows, 10 s CPU (60 s async), 6 MB heap (12 MB async), 100 callouts in 120 s, 10 sendEmail calls.

Common mistake

Mixing up DML statements (150) with DML rows (10,000). One update of a 10,000-record list is a single statement.

Likely follow-ups
  • Which limits are higher in async, and which are the same?
  • How do you read the current usage? (The Limits class.)
Q2IntermediateAsynchronous ApexLimits

Async Apex at a glance - what are the key numbers?

1What it is

The limits on starting background work: how many future calls and queueable jobs one transaction can start, batch sizes, and how many jobs can run or wait.

2Why it matters

Designs that loop and enqueue a job per record fail at 51. Knowing these numbers shows you plan for volume.

3Example

FactValue
@future calls per transaction50 (none from future or batch)
Queueable jobs enqueued50 from sync, 1 from an async job (a chain)
Batch scopeDefault 200, maximum 2,000 per execute
Batch start() with a QueryLocatorUp to 50 million records
Batch jobs running at once5 (more wait in the flex queue, up to 100)
Scheduled Apex jobs100 at a time
Callouts from asyncQueueable or batch with Database.AllowsCallouts; @future(callout=true)

4In short - say this in the interview

50 future calls and 50 queueables per sync transaction, one queueable from an async job, batch scope 200 by default up to 2,000, 50 million records from a QueryLocator, 5 concurrent batches with 100 in the flex queue, 100 scheduled jobs.

Common mistake

Enqueuing a Queueable for each record in a trigger. Enqueue one job that processes the whole list.

Likely follow-ups
  • What does Database.Stateful do?
  • How do you chain Queueable jobs?
Q3IntermediateTriggers

Trigger facts to remember

1What it is

The handful of trigger rules that come up in every interview.

2Why it matters

Each one is behind a common bug: changing a read-only record, reading null from a map, or running the same logic twice.

3Example

  • A trigger receives up to 200 records per batch.
  • Change fields on the record in before triggers only - no DML needed.
  • Trigger.newMap does not exist in before insert; Trigger.old exists only in update and delete.
  • With several triggers on one object, the order is not guaranteed - keep one per object.
  • Static variables last for the whole transaction - the basis of recursion guards.
  • A workflow field update runs update triggers once more.
  • Triggers cannot make callouts directly; use async Apex.
  • Validation rules do not run on delete - use a before delete trigger with addError.

4In short - say this in the interview

200 records per batch, change fields only in before triggers, newMap has no before-insert, old only in update and delete, one trigger per object, static variables live for the transaction, and callouts need async Apex.

Common mistake

Assuming the trigger receives one record. It receives a batch.

Likely follow-ups
  • What runs first, a before-save flow or a before trigger?
  • How do you detect which fields changed?
Q4IntermediateSecurity

Security in one view: who can do what, and see which records?

1What it is

Salesforce security in three layers: object access and field access (profiles, permission sets) and record access (org-wide defaults, role hierarchy, sharing rules).

2Why it matters

Code runs in system mode, so a developer has to know which layer each tool enforces - or a component quietly shows data the user should not see.

3Example

LayerSet byEnforced in Apex by
Object (CRUD)Profile, permission setsWITH USER_MODE, as user DML, stripInaccessible
Field (FLS)Profile, permission setsWITH USER_MODE, stripInaccessible
Record (sharing)OWD, roles, sharing ruleswith sharing, WITH USER_MODE
What can they do?objects, fields, system permissionsProfileexactly one per user - keep it minimalPermission sets and groupsmany per user - grant access hereObject: create, read, edit, deleteField-level security: see / edit a fieldWhich records?record-level sharingManual and team sharingSharing rulesRole hierarchyOrg-wide defaults (baseline)Each layer only adds access - never removes it.

4In short - say this in the interview

Profiles and permission sets decide object and field access; org-wide defaults, the role hierarchy and sharing rules decide record access. In Apex, with sharing covers records only - WITH USER_MODE and stripInaccessible cover objects and fields too.

Common mistake

Thinking Lightning Data Service and Apex behave the same. LDS enforces all three layers automatically; Apex does not unless you ask.

Likely follow-ups
  • Does a page layout protect a field? (No - field-level security does.)
  • What is the most restrictive org-wide default?
Q5BeginnerTestingDeployment

Testing and deployment facts to know

1What it is

The rules for getting Apex into production, and the tools to move changes between orgs.

2Why it matters

A deployment that fails at 74% coverage on release night is a story every interviewer has lived. These rules show you have shipped code.

3Example

  • 75% overall Apex coverage, all tests passing, every trigger covered, to deploy to production.
  • Tests do not commit data, and cannot see org data unless SeeAllData=true - avoid it.
  • @testSetup creates shared test data once per class.
  • Test.startTest / stopTest reset limits and run queued async work.
  • Tests cannot make real callouts - use HttpCalloutMock.
  • Move changes with change sets, the Salesforce CLI and Metadata API, DevOps Center, or unlocked packages.

4In short - say this in the interview

75% coverage with all tests passing and every trigger covered; tests make their own data and never commit it; startTest and stopTest reset limits and flush async work; deploy with change sets, the Salesforce CLI, DevOps Center or packages.

Common mistake

Treating coverage as the goal. Tests without assertions pass at 100% and prove nothing.

Likely follow-ups
  • Why is SeeAllData=true risky?
  • What is the difference between a change set and source-driven deployment?
Q6BeginnerEnvironments

What sandbox types are there?

1What it is

Copies of production for building and testing: Developer, Developer Pro, Partial Copy and Full - differing in how much data they hold and how often they can be refreshed.

2Why it matters

Choosing the right one for each step - build, integration testing, user acceptance, performance - is part of any release process question.

3Example

TypeDataRefresh everyGood for
DeveloperMetadata only, 200 MB1 dayBuilding and unit testing
Developer ProMetadata only, 1 GB1 dayLarger dev and test data sets
Partial CopyMetadata + a sample of data, 5 GB5 daysIntegration testing, UAT
FullA full copy of production29 daysPerformance tests, final UAT, staging

4In short - say this in the interview

Developer and Developer Pro copy metadata only and refresh daily; Partial Copy adds a sample of data and refreshes every 5 days; Full copies all of production and refreshes every 29 days.

Common mistake

Testing a data migration in a Developer sandbox. It has no production data to test against.

Likely follow-ups
  • What is a sandbox template? (It chooses which objects a Partial Copy samples.)
  • What happens to email deliverability in a new sandbox?
Q7BeginnerData modelLimits

Other numbers that come up

1What it is

Platform facts outside governor limits that interviewers like to check.

2Why it matters

They come up in design questions: "could we use a master-detail here?", "how would we load this file?".

3Example

FactValue
Master-detail relationships per object2
Lookup relationships per object40
Data Import Wizard / Data Loader50,000 / 5 million records
Composite API subrequests in one call25
Platform event retention for replay72 hours
SOQL OFFSET maximum2,000
Trigger batch size200
Non-selective query error in triggersObjects over 200,000 records

4In short - say this in the interview

Two master-detail and 40 lookups per object, 50,000 records with the Import Wizard and 5 million with Data Loader, 25 Composite subrequests, 72-hour event retention, OFFSET up to 2,000, and 200 records per trigger batch.

Common mistake

Quoting numbers without the reason. Say what each one means for the design.

Likely follow-ups
  • What happens to the details when a master is deleted?
  • When would you use Bulk API instead of Data Loader?

Answers describe documented behaviour, checked against the sources listed. Platforms change between releases - confirm limits and versions before an interview.

Previous · Part 6Salesforce Integration Interview Questions