Salesforce System Design Interview 2026: What to Expect and How to Prepare

When you sit down for a Salesforce system design interview, the goal is simple: prove you can architect a reliable, scalable solution that fits the platform’s multi‑tenant nature. The round usually lasts 45‑60 minutes, and the conversation is largely driven by your whiteboard (or digital canvas) while the interviewer probes your decisions. Below is a practical guide that walks through what the interview covers, how the rubric works, two realistic prompts, and a step‑by‑step preparation plan.

What the Round Typically Covers

Interviewers often start with a high‑level requirement and then drill down. Expect follow‑up questions that push you to refine a diagram, discuss edge cases, or switch to a different technology stack.

The Rubric Interviewers Use

Most Salesforce interviewers score candidates on three broad dimensions, each rated from 1‑5:

1. Clarity & Communication – Do you explain concepts in a logical order? Do you keep the discussion focused?
2. Depth & Trade‑offs – Do you identify key constraints (governor limits, latency) and evaluate alternatives?
3. Iterative Design – Do you respond to feedback, adjust the diagram, and show willingness to revisit assumptions?

A total score of 12‑15 is typically regarded as a solid pass. Scores below 10 often indicate gaps in either domain knowledge or the ability to iterate under pressure.

Example Prompt #1: Multi‑Tenant CRM for a Global Sales Team

Prompt: Design a system that supports a global sales organization with 10 M accounts, 50 M contacts, and 200 M opportunities. The system must allow each regional team to view only its own data while still providing company‑wide dashboards.

High‑Level Sketch

• Core Objects: Use standard Account, Contact, Opportunity objects with custom fields for region and reporting hierarchy.
• Sharing Model: Implement a role‑hierarchy combined with sharing rules to enforce regional isolation. Add a custom sharing reason for cross‑region analytics.
• Data Partitioning: Leverage big objects for archival data older than 2 years to keep primary storage within limits.
• Analytics: Build Einstein Analytics datasets that pull from a replicated sandbox of the live data, ensuring dashboards do not expose raw records.
• Integration: Expose a REST API for external tools, throttled by named credentials per region to stay within API limits.

Key Trade‑offs Discussed

• Governor Limits vs Real‑Time – Real‑time sync across regions would hit API limits; batch jobs using Bulk API are safer.
• Storage Cost – Big objects are cheaper for cold data, but queries are slower; keep hot data on standard objects.
• Latency – Regional caches (e.g., Platform Cache) reduce read latency for frequently accessed lookup data.

Example Prompt #2: Real‑Time Analytics for Lead Scoring

Prompt: Design a pipeline that scores incoming leads in real time and updates the lead record with a confidence score. The system should handle bursts of 10 k leads per minute.

High‑Level Sketch

1. Ingestion – Use Salesforce Shield Event Monitoring or Streaming API to capture lead creation events.
2. Processing – Route events to Salesforce Functions (or an external serverless function) that runs the scoring model.
3. Model Storage – Keep the model in Salesforce Files or an external ML endpoint; retrieve it lazily to avoid cold‑start delays.
4. Write‑Back – Update the lead with a custom field via the Bulk API in batches of 2 k to stay within transaction limits.
5. Monitoring – Set up Platform Events to emit success/failure metrics; feed into Einstein Monitoring dashboards.

Key Trade‑offs Discussed

• Batch Size – Smaller batches reduce transaction time but increase API calls; a sweet spot is typically 2‑5 k records per batch.
• Latency vs Accuracy – A lightweight heuristic can give an immediate score; a deeper model can run asynchronously for refinement.
• Error Handling – Use dead‑letter queues (via Platform Events) to capture failed updates and retry without losing data.

How to Prepare: A Concrete Plan

1. Refresh Core Knowledge – Review Salesforce data model limits, sharing mechanisms, and the most common APIs. A quick cheat‑sheet of governor limits is invaluable.
2. Practice Sketching – Spend 30 minutes a day drawing system diagrams on a whiteboard or a digital tool. Start with the two example prompts above, then vary parameters (e.g., 100 M records, stricter latency).
3. Mock Interviews – Pair with a peer or use a mock‑interview platform. Record your answers and replay them. This is where Call Assistant can be handy: it captures your spoken answer, suggests follow‑up topics, and helps keep the story anchored to your resume.

Sample Answer Template (45‑60 seconds)

"To support a global sales team, I’d start with the standard Account, Contact, and Opportunity objects, adding a custom Region__c field. Using a role‑hierarchy combined with sharing rules ensures each region only sees its own data, while a custom sharing reason lets us build company‑wide dashboards without exposing raw records. For archival data older than two years, I’d move records to a big object to keep storage costs low. Real‑time regional dashboards would pull from a replicated sandbox using Einstein Analytics, keeping latency under a second. Finally, I’d expose a REST API per region, throttled by named credentials, to stay within API limits and maintain isolation."

How to Practice This

1. Re‑create the prompts – Write the prompt on a sticky note, set a timer for 15 minutes, and sketch the solution without looking at any reference material.
2. Explain to a non‑technical friend – Summarize the design in plain language; this forces you to clarify assumptions.
3. Iterate with feedback – Use a mock interview partner or Call Assistant to get follow‑up questions, then refine your diagram and narrative.

---

FAQ

• What if I’m not familiar with big objects? Big objects are Salesforce’s way to store billions of rows at low cost. They’re ideal for archival data and support simple query patterns, but you can’t use them for complex joins.

• How deep should I go into code? Focus on architecture and trade‑offs. Mention code snippets only to illustrate a point (e.g., a simple Apex trigger for lead scoring) rather than writing full implementations.

• Do I need to know every Salesforce product? No. Know the core platform, standard objects, sharing models, and the most common integration patterns. Extra products like Einstein Analytics are useful to mention when they solve a specific need.

• Can I bring a diagram from a previous project? Yes, as long as you adapt it to the interview prompt and explain how it satisfies the specific constraints they give you.