The Coding Interview

Before you talk to a single engineer at Salesforce, there is usually a gate to clear on your own: an online assessment on HackerRank. It runs about ninety minutes and holds two or three problems. The bar candidates describe is simple to state and hard to hit: pass every hidden test case. Treat it as proctored. It watches for tab-switching. The problems themselves are not exotic. They lean on strings, hash maps, and arrays, with a dynamic-programming problem or two mixed in. What surprises people is that this solo gate, not any live round, tends to be the hardest part of the whole loop. Clear it and you move on to two or three live technical rounds and a hiring-manager conversation to close.

The live rounds hold to the same center of gravity. Arrays, strings, and hashing carry the most weight, with trees, graphs, recursion, and DP filling the rest. Difficulty sits at the medium tier, with the occasional medium-hard and a thin band of genuine hards like two Premium questions. Salesforce draws from a recognizable core of archetypes rather than inventing exotic ones, and it sometimes states them in enterprise terms: contact deduplication, data merging, a notification pipeline. This lesson maps that surface onto four lessons and names the two things that make the loop specifically Salesforce.

The Salesforce angle

The assessment grades on fully passing the hidden tests, so finish a correct solution before you reach for the clever one. A plain version that clears every hidden case scores. A slicker attempt that misses two edge cases does not, however readable it looks. The official Trailhead module on the remote programming test says the same in plainer words: get it working and get it right. Two habits follow. Brute-force your way to a passing solution first if you have to, then optimize with the time left over. Read the constraints for the off-by-one and empty-input cases the hidden suite is built to catch. If the underlying pattern muscles feel shaky, the free Foundations course drills each one from the base up so these lessons can stay on what makes Salesforce Salesforce.

How the rounds run

Live coding happens in a shared editor that runs your code, often HackerRank CodePair and sometimes Quip, Salesforce's own document tool, over video. There is no whiteboard-only round for the algorithm work. One common shape: a pure DS&A round of one or two mediums, then a second round that pairs a medium with an object-oriented design problem. The exact split moves by team, level, and region. Salesforce publishes little about the loop, and acquired orgs like Slack, Tableau, and MuleSoft run their own. Read the shape here as the modal one for core Salesforce engineering. Teams do not all follow a fixed script.

• Platform: HackerRank, code runs. Live rounds run in a shared editor that executes your code, frequently HackerRank CodePair and sometimes Quip, over Zoom or video. You pick the language; Java is common but not required, and Apex is the product, not the interview language.
• First gate: ~90 min assessment. A HackerRank assessment, roughly two to three problems in about ninety minutes, graded on passing every hidden test. Strings, hash maps, arrays, and DP are its bread and butter. Reported as the hardest filter in the loop. Frontend roles get a JavaScript-flavored variant.
• Live rounds: 2-3 technical, ~45-60m. Usually one or two problems per round, often one pure-DSA round and one that adds an object-oriented design problem. Senior loops add a system-design conversation; new-grad loops lean lighter on design.
• Graded on: Reasoning, narrated. State the approach and the time and space complexity before you type, then write working code and collaborate on the optimization. Narrating the trade-off is weighted heavily, sometimes above reaching the fully optimal answer.

The Salesforce angle

Some rounds hand you no boilerplate, so you define the tree, linked-list, or graph node yourself before you can solve anything. Candidates report being asked to write the scaffolding from scratch, which trips people who have only ever filled in a LeetCode stub. Practice writing the class or struct along with the algorithm body. The other consistent non-code signal is sequence. Explain the approach and call the complexity first, then code, then take the optimization the interviewer nudges toward: recursive to iterative, or a coarse lock to a fine-grained one. Going quiet and trying to hold the whole design in your head is the reliable way to stall; the candidates who pass keep talking and keep the code running at every step.

Where the weight sits

The chart below splits the recurring problems across families, with variants of the same problem counted once. Salesforce does not publish these numbers, so the ordering is just how often each family surfaces across reports, nothing you can hold a given loop to. The headline is stable either way. Arrays, strings, and hashing lead by a wide margin. The two design families, implementing a data structure to spec and modeling clean objects, claim a slice the pure-algorithm buckets never give up.

The Salesforce angle

Several array and graph problems come to you in CRM vocabulary, and the cleanest example is a Premium question, which is contact-and-email deduplication by another name. Union-find over shared emails is the same engine that collapses duplicate Account and Contact records, and interviewers in the platform orgs lean on that framing on purpose. Treat the business vocabulary as a hint about the data model. The algorithm stays the same. Zero-sum subarrays become a notification-counting question; a frequency map becomes record reconciliation. The underlying pattern is unchanged. The practical read of the chart is breadth. Drill only trees and DP, and a sliding-window string or a two-heap median round catches you flat. Cover the recurring core across every family, and over-index on the arrays and hashing spine the loop opens on.

The design signature

The one thing that pulls Salesforce out of a generic moderate loop is how heavily it leans on object-oriented design. The roots are in the product: a platform built on Apex and Java, where engineers model objects and write multi-tenant code that many customers run at once. So a dedicated OOD problem shows up far more often than its difficulty tier would predict, usually as the back half of a technical round.

The Salesforce angle

The OOD round is graded on a clean class model first, then it turns hard with a single sentence: now make it thread-safe. The canonical prompt is a multi-floor parking lot: park and unpark, search by plate, count free spots by vehicle type, modeled with proper encapsulation and a Strategy pattern for spot assignment. The follow-up is what separates a hire from a polite pass. Lock at the spot level instead of the whole lot. Get it wrong and your clean design serializes every car behind one mutex and falls over. That is the same noisy-neighbor problem the platform's governor limits are there to cap. Snake-and-Ladder and an LRU modeled as a class show up the same way, as do product-catalog utility classes. India loops add a language-internals probe on top: explain a HashMap's buckets and collisions, then write code that deadlocks. Rehearse the concurrency follow-up before you walk in; the Object-Oriented Design lesson is the one to over-prepare.

How these lessons are organized

Each lesson below takes one part of the map and works it as runnable problems with the Salesforce framing and the follow-ups the room adds. The data-structure design problems ride inside the object-oriented design lesson, since the two blur together in the loop. Where a lesson rests on a base data-structures idea, the deep walkthrough lives in the free Foundations course so these pages can stay on what is specifically Salesforce. Start with arrays, strings, and hashing. It is the widest bucket and the warm-up most loops open on.

Common questions