← Salesforce Interview Insights

Salesforce·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jun 2026

Summary

Salesforce technical phone screen for a software engineer role, pretty much a pure database theory deep dive. The whole thing centered on transaction isolation levels, which I thought I knew well enough until they started pushing on the locking mechanics.

Questions Asked (3)

Q1

Walk me through the four standard transaction isolation levels and which anomalies each one prevents.

Technical Trade-offsSystem Design
Author's notes

Started fine, rattled off the four levels in order and matched them to dirty reads, non-repeatable reads, phantoms.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the four isolation levels in order of increasing strictness, then map each to the anomalies they prevent using a clear matrix. Emphasize the trade-offs between consistency and concurrency, and relate to real-world systems like Salesforce's multi-tenant database.

Pro tip: Mention that while higher isolation levels prevent more anomalies, they can cause performance bottlenecks due to increased locking; in practice, many systems use Read Committed with application-level checks or Snapshot Isolation for a balance.

1. Define the anomalies

Briefly explain dirty read, non-repeatable read, phantom read, and lost update to set the stage. This shows you understand the problems isolation levels solve.

2. List the isolation levels

Enumerate the four standard levels: Read Uncommitted, Read Committed, Repeatable Read, and Serializable. State that they are defined by the SQL standard.

3. Map levels to anomalies

For each level, specify which anomalies are prevented and which can still occur. Use a table-like mental model: Read Uncommitted allows all; Read Committed prevents dirty reads; Repeatable Read prevents dirty and non-repeatable reads; Serializable prevents all.

4. Discuss trade-offs

Explain that stricter isolation reduces concurrency and can cause blocking or deadlocks. Mention that some databases implement levels differently (e.g., Oracle's Read Committed uses snapshot).

5. Relate to Salesforce

Tie it to Salesforce's multi-tenant architecture: they likely use Read Committed for most operations to balance performance and consistency, with additional mechanisms for critical transactions.

Key Points to Mention

  • Dirty read: reading uncommitted data from another transaction.
  • Non-repeatable read: re-reading a row and finding it changed.
  • Phantom read: re-running a query and finding new rows matching the condition.
  • Lost update: two transactions overwrite each other's changes (often prevented by higher levels or locking).
  • Read Uncommitted allows dirty reads; Read Committed prevents dirty reads but allows non-repeatable and phantom reads; Repeatable Read prevents dirty and non-repeatable reads but allows phantom reads; Serializable prevents all.
  • Trade-off: higher isolation means lower concurrency and potential performance impact.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Compare the locking strategies used by Repeatable Read and Serializable, specifically around lock granularity like row locks, gap locks, and predicate locks.

Technical Trade-offsSystem DesignData Modeling
Author's notes

This is where I got exposed.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the isolation levels and their goals, then compare lock granularity (row, gap, predicate) and how each level uses them to prevent anomalies. Use a concrete example to illustrate the difference in locking behavior and discuss trade-offs in concurrency and performance.

Pro tip: Mention that Serializable in MySQL InnoDB uses next-key locks (row + gap) to simulate predicate locking, while true predicate locking is rare due to overhead. This shows depth and practical knowledge.

1. Define isolation levels and goals

Briefly explain Repeatable Read (RR) and Serializable, focusing on their objectives: RR prevents non-repeatable reads, while Serializable prevents all anomalies including phantoms.

2. Explain lock granularity concepts

Define row locks, gap locks, and predicate locks. Clarify that gap locks lock ranges between index records, and predicate locks lock based on conditions.

3. Compare locking in RR vs Serializable

Describe how RR typically uses row locks for writes and may use gap locks for some reads, while Serializable uses stricter locking like next-key locks or predicate locks to prevent phantoms.

4. Illustrate with an example

Walk through a scenario (e.g., a query with a range condition) showing how locks differ and the impact on concurrent transactions.

5. Discuss trade-offs and practical implications

Highlight the trade-off between concurrency and consistency: Serializable reduces concurrency due to more locks, while RR offers better performance but may allow phantoms.

Key Points to Mention

  • Repeatable Read prevents non-repeatable reads but allows phantoms; Serializable prevents phantoms.
  • Row locks lock individual rows; gap locks lock gaps between index records; predicate locks lock based on a condition.
  • In MySQL InnoDB, Repeatable Read uses next-key locks for some operations, which combine row and gap locks.
  • Serializable often uses next-key locks or predicate locks to ensure no phantoms.
  • Lock granularity affects concurrency: finer granularity (row) allows more concurrency but may not prevent phantoms; coarser (predicate) prevents phantoms but reduces concurrency.
  • Trade-off: Serializable provides stronger consistency at the cost of performance and potential deadlocks.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Explain concretely how Serializable prevents phantom reads where Repeatable Read does not, using the locking differences to justify your answer.

System DesignTechnical Trade-offs
Author's notes

Probably the hardest part.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Define phantom reads as new rows appearing in a repeated range query, then contrast the locking mechanisms: Repeatable Read uses row-level locks that don't prevent inserts, while Serializable adds range locks or predicate locks to block them. Conclude with the trade-off: Serializable ensures correctness at the cost of reduced concurrency.

Pro tip: Mention that in practice, databases like PostgreSQL implement Serializable using Serializable Snapshot Isolation (SSI) rather than pure two-phase locking, which avoids read locks but still detects and aborts dangerous conflicts.

1. Define phantom reads

Explain that a phantom read occurs when a transaction re-executes a range query and sees new rows inserted by another committed transaction.

2. Explain Repeatable Read locking

Describe how Repeatable Read typically locks existing rows (or uses snapshot isolation) but does not lock the gaps or predicates, allowing inserts that create phantoms.

3. Explain Serializable locking

Detail that Serializable adds range locks (or predicate locks) on the index or table, preventing other transactions from inserting rows that would match the query's predicate.

4. Contrast concurrency and trade-offs

Highlight that Serializable's stronger guarantees reduce concurrency and can cause more blocking or aborts, while Repeatable Read is more performant but allows phantoms.

5. Conclude with practical implications

Summarize that choosing between them depends on whether phantom reads are acceptable for the application's correctness requirements.

Key Points to Mention

  • Phantom read definition: new rows appearing in a repeated range query.
  • Repeatable Read uses row-level locks or snapshot isolation, not range locks.
  • Serializable uses range locks or predicate locks to block inserts.
  • Trade-off: Serializable reduces concurrency and may cause more blocking/aborts.
  • Real-world implementations: PostgreSQL uses SSI, MySQL uses next-key locks.
  • Example: SELECT * FROM orders WHERE amount > 100; a new order with amount 150 would be a phantom.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.