Salesforce OA Interview Experience (2025) - String Replacement Challenge, Rejected

Problem 1: Minimum Absolute Pair Difference

Problem: You are given a list of distinct measurements taken at different times. Find the smallest possible absolute difference between any two measurements and print every pair that achieves it. Each pair prints with the smaller element first, and pairs are sorted by the first element, breaking ties by the second.

The intended solution is straightforward. Sort the array, sweep once to find the minimum adjacent difference, sweep again to collect every adjacent pair whose difference equals the minimum, and emit them in order. The runtime is O(n log n) dominated by the sort, and because the array is sorted, the smaller element of each pair is already the left one.

I got the algorithm right on the first try. Where I lost points was on two edge cases I did not catch. The first was negative numbers: my comparison used absolute difference correctly, but my output formatting had a sign mistake where a pair like (-5, -1) printed as (-1, -5) because I had re-applied abs in the wrong place when building the output tuple. The second was duplicate adjacent differences that spanned non-adjacent values after sorting; I assumed every minimum-difference pair would be adjacent in the sorted order, which is true, but I also assumed the pair would be unique, which is not. My collector only recorded the first match per value. I noticed the second bug with about 10 minutes left and patched it, but the negative-number formatting slipped through because my hand-rolled test inputs were all positive. The lesson there is a cousin of [[problem/282?company=19|Graph Connectivity Check]] territory: always run your algorithm on at least one adversarial input you did not hand-craft.

Problem 2: Minimize Malware Spread by Removing One Node

Problem: You are given an undirected graph with some nodes marked as initially infected. Infection propagates along edges until no more nodes can be newly infected. Remove exactly one initially-infected node so that the final infected set is as small as possible. If multiple removals tie for the minimum, return the smallest-indexed node.

The clean solution is a union-find over the uninfected edges: build connected components ignoring the initial infection set, count how many initially-infected nodes sit in each component, and then observe that removing an infected node only saves its entire component if that component contains exactly one initial infection. For components containing two or more, removing any single one does not stop the spread. Pick the removal whose component is largest, breaking ties by the smallest node index.

I saw the union-find structure fast but lost time on the "exactly one" observation. My first pass computed the "gain" of removing each infected node as the size of its component minus one, which is wrong for components with multiple infections. I ran my code against the provided sample and it passed, but two hidden tests failed because of this. I caught the issue around the 75-minute mark, reworked the tallying to only credit components with a single infection, and got it submitting with roughly four minutes left. I am fairly sure I passed most of the test cases on problem two but not all of them. The cleaner version of this problem feels a lot like [[problem/281?company=19|Flatten Nested JSON]] in the sense that the easy path passes the visible tests but the hidden cases punish you for not thinking through the invariant.

The other thing that hurt me was tooling. Salesforce's editor is not as responsive as the LeetCode web IDE, and I burned a couple of minutes fighting with its auto-indentation when I tried to refactor. If I were doing it again I would write scratch code in my local editor and paste it in, which their platform does allow.

Result

Rejection email three business days later, form letter. No feedback and no option to reapply for a set window, which I think is 6 months. The recruiter was professional about it but there was nothing to salvage.

Looking at the postmortem honestly: problem one was a stupid loss. I had the algorithm and I lost it to a formatting bug that would have caught me in five seconds with a better test input. Problem two was a real technical gap; I rushed the setup and did not slow down enough to state the invariant out loud before coding. For a 90-minute two-problem OA, the correct pacing is more like 35 minutes on problem one, five minutes to breathe, and 50 minutes on problem two, not the 40/40 split I actually ran.

Tips

1. Write your own adversarial tests before you submit. The sample cases are there to help you understand the prompt, not to validate your solution. Negative numbers, duplicates, single-element arrays, and disconnected graphs are the usual culprits. This is what cost me problem one.
2. State the invariant before you code the graph problem. For the malware problem specifically, the one-line insight ("only single-infection components are savable") has to be written down explicitly before you start coding. If you try to discover it through the code, you will ship the wrong version and patch it under time pressure.
3. Budget problem two more aggressively. The two-problem OA is almost always weighted toward the second problem. If you breeze through the first, use the slack on the second, not on polishing the first.
4. Do not trust the sample passing as a green light. Salesforce's hidden tests are noticeably meaner than the visible ones. If your solution passes the sample on the first compile, that is a signal to add more tests, not to submit.
5. Paste from a local editor if the web IDE is slowing you down. Refactoring in-browser in a finicky editor while the clock is running is where a lot of preventable mistakes happen. Problems like [[problem/280?company=19|Longest Subsequence as Substring]] or [[problem/279?company=19|Max Requests in Time Window]] are the kind of medium where five minutes of editor friction is the entire difference between green and red.