HackTheRounds Interview Experiences

Salesforce Software Engineer Interview Experience (2026) - Currying, Traffic Light & SQL Traps, Offer

Salesforce 2026 new grad SWE: HackerRank OA with vanilla JS currying and traffic light state machine, plus coffee order SQL design, sliding window coding, and H

By Anonymous · 2026-03-18

Background

I'm a new-grad candidate from a non-target CS program who applied to Salesforce in late 2025 through the careers site. My focus had been full-stack work, so the Salesforce recruiter routed me to a frontend-leaning SWE pod. I had no referral and no prior big-tech offer going in, so the bar felt high. The process turned out to be more forgiving than I expected in some rounds and much stricter in others, particularly around SQL.

Timeline

Online Assessment (90 min, HackerRank)

Two problems, both tailored to the frontend track. Salesforce splits OA question sets by team, and the full-stack pod I applied to had a notably different OA than the pure backend new-grads I compared notes with after. The frontend version leans on vanilla DOM and JS fundamentals rather than LeetCode algos.

Problem 1: Currying Three Numbers

Problem: Implement addThreeNumbers(a)(b)(c) so that each call returns either a function expecting the next arg or the final sum.

This is one of those problems that looks trivial but trips candidates who've never written a curry by hand. My first pass was the obvious nested closure (one function per argument), which passes the canonical three-step call.

But the HackerRank tests also called it as addThreeNumbers(1, 2, 3) and addThreeNumbers(1)(2, 3) in a couple of cases. I generalized with a variadic accumulator: keep collecting args across calls, and as soon as we have at least three, return the sum; otherwise return a new function that spreads accumulated args forward. The lesson: read every test call signature before writing the basic version. Salesforce loves sneaking partial-application variants in.

Practice it: [[problem/286?company=19|Curry Function Implementation]]

Problem 2: Traffic Light in Vanilla JS

Problem: In a CoderPad editor with no React and no frameworks, build a traffic light that cycles Red (4s), Green (1s), Yellow (1s) forever. Use only HTML, CSS, and vanilla JS.

I used three <div circles plus a class toggle. The state machine was a single setTimeout that scheduled the next transition based on the current color's duration. I avoided setInterval because interval drift with 4s/1s/1s mixed is annoying. The CSS was straightforward: background-color transitions plus a simple flex layout.

The tripwire is that Salesforce's test rig sometimes runs the code headlessly and checks class names at specific elapsed times, so the timings need to be accurate and the class on the active light needs to be named exactly what the spec says (usually active ).

Virtual Onsite (3 rounds)

One system design plus SQL, one backend coding, one behavioral with the hiring manager. Each round was 60 minutes on Zoom with a shared CoderPad.

Round 1: System Design — Coffee Order System With SQL

Problem: Design the data model for a coffee-ordering app (customers, orders, items, baristas, stores) and then write SQL for several business questions. The signature one: "Return all users who have never placed an order."

I went with four core tables: users , stores , orders with user id and store id FKs, and order items with order id and item metadata. The canonical SQL answer is a LEFT JOIN from users to orders with a WHERE orders.id IS NULL filter, which is safer than NOT IN because NOT IN returns empty when the subquery contains any NULLs. I called that out explicitly when I wrote the query.

The interviewer followed up with three more SQL variations: top 5 users by total spend last month, most popular drink per store, and a rolling 7-day order count. I handled them with window functions — ROW NUMBER() partitioned by store ordered by count for the popularity question, and a SUM(...) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) for the rolling count.

Round 2: Coding — Max Requests In Time Window

Problem: Given a list of request timestamps and a window size W, return the maximum number of requests that fall within any W-second window.

Sliding window with two pointers. Sort timestamps (they usually arrive sorted but I validated), then for each right pointer advance the left until ts[right] - ts[left] <= W , and track right - left + 1 as the running max. O(n log n) if unsorted, O(n) if sorted.

Follow-up: What if the stream is live and we need the rolling max for the last W seconds at any query time? I switched to a deque keyed by timestamp, popping expired entries on each insert. O(1) amortized per insert and O(1) per query for the length.

Follow-up 2: What if you want the window count and also the top-K heaviest users in that window? I added a hash map of user id - count per window and proposed a min-heap of size K that gets rebalanced as the window slides. The interviewer was satisfied but warned me that rebalancing a heap on delete-by-value is O(n), which I acknowledged.

Practice it: [[problem/279?company=19|Max Requests in Time Window]]

Round 3: Behavioral + Profitability System Design

Half behavioral, half a lightweight design question. The behavioral prompt was "Describe a time you drove a migration and had to convince others to support it." Salesforce's culture values "Trailblazer" stories, which decode as owned-end-to-end narratives with concrete business impact. I told a story about moving our team's event pipeline from Kafka-on-EC2 to MSK, with real numbers on the cost delta (roughly 40 percent lower infra bill) and on the oncall-pages delta (down from 3 per week to under 1). The interviewer interrupted twice to dig into the cross-team negotiation, which he clearly cared about more than the technical details.

The design piece: "Sketch an accounting system that tells us whether each product SKU is profitable." I kept it light: a fact table of sales, a dim table of costs (COGS, attributed marketing spend), a nightly batch job to join them, and a dashboard layer for PM consumption. He asked about late-arriving cost data, which I solved with a reprocessing window plus a "last updated" column that triggers re-computation for affected SKUs.

Result

Offer came 7 business days after the onsite. New-grad SWE on a Sales Cloud team in the San Francisco office. Base was above the band midpoint thanks to a competing offer I had from a smaller company; Salesforce negotiated on sign-on bonus rather than RSUs.

Tips

  1. If you get the frontend track, drill vanilla JS hard. Currying, debounce, throttle, `Promise.all` from scratch, event delegation. These come up every cycle. Salesforce's frontend OA is specifically *not* a LeetCode warm-up.
  2. SQL is a real weight-bearing skill here. The `NOT IN` vs `LEFT JOIN ... IS NULL` trap, window functions, and self-joins all showed up for me and for people I compared notes with. If your SQL is rusty, spend a weekend on StrataScratch or similar.
  3. Have numbers in your behavioral stories. "I led a migration" is the weakest possible version. "I led a migration that cut infra cost 40 percent and reduced oncall pages from 3 per week to under 1" is memorable. Write them down before the interview.
  4. Read the test-call signatures in OA problems. The currying problem had hidden variants where the tests called it as `fn(a, b)(c)` or `fn(a, b, c)`. If your solution only handles the first signature you lose points silently.
  5. Salesforce pods vary a lot. The SDE backend pod I initially applied to had a completely different OA (medium LeetCode pairs) than the frontend-leaning pod I ended up with. Ask your recruiter what track you are on before you prep.
  6. The hiring manager round is where the offer is won. Salesforce is heavy on values fit, and the HM has outsized influence. Prepare concrete stories that map to "Trust, Customer Success, Innovation, Equality, Sustainability" without sounding rehearsed.

The loop is less punishing than FAANG but more opinionated. Be specific, be numeric, and do not skip the SQL practice.