I recently went through the interview loop at Salesforce for a Staff Member of Technical Staff (SMTS) Backend role. There were 4 rounds in total — an online assessment, a DSA + project deep-dive, an HLD system design, and an HM round with LLD. The bar was high throughout, with a strong emphasis on depth, trade-offs, and real-world reasoning. Hope this helps someone preparing!
1) Round 1 — Online Assessment (HackerRank)
A timed HackerRank assessment to filter candidates before the interview loop. I don't remember the exact questions but they were around LeetCode medium difficulty — covering standard DSA topics like arrays, strings, and possibly some greedy/graph problems. Nothing too exotic, but you need to be comfortable solving mediums under time pressure.
Tip: practice timed LC mediums and make sure your code compiles and handles edge cases — partial scores matter on HackerRank.
2) Round 2 — DSA + Past Project Deep Dive
DSA: Token Bucket / Resource Grant System
A custom DSA problem modeled around resource allocation:
- A bucket holds a limited number of tokens
- Users request tokens — they are either granted or rejected based on current availability
- If granted, the user holds those n tokens for exactly 1 hour, after which they are automatically returned to the bucket
- Need to support: requestTokens(userId, n), releaseTokens(userId), and a background expiry mechanism
Key discussion points:
- Using a min-heap / priority queue ordered by expiry time to efficiently handle auto-release
- Handling concurrent requests — locking strategies vs. atomic operations
- Edge cases: partial grants, user requesting tokens they already hold, token expiry during an active request
- Time complexity of grant and release operations
Past Project Deep Dive
Detailed walkthrough of one of my significant past projects. The discussion quickly went beyond surface level:
- Architecture decisions and why I made them
- Bottlenecks I encountered and how I resolved them
- How I ensured reliability and consistency under load
- What I would do differently with hindsight
Tip: pick a project you know inside out — they will probe every design choice.
3) Round 3 — System Design HLD: Rate Limiter
Design: Distributed Rate Limiter
This round went very deep. Started with the basics and kept drilling into trade-offs at every layer.
Algorithms discussed:
- Token Bucket — bursty traffic allowed up to bucket size; smooth refill rate
- Leaky Bucket — strict output rate; excess requests are dropped or queued
- Fixed Window Counter — simple but suffers from boundary spike problem
- Sliding Window Log / Sliding Window Counter — more accurate, higher memory cost
- Trade-offs between accuracy, memory, and throughput for each
Storage and synchronization:
- Using Redis as a global distributed cache for rate limit counters
- INCR + EXPIRE vs. Lua scripts for atomicity
- Trade-off: local in-process cache (low latency, inconsistent across nodes) vs. global Redis (consistent, network overhead)
- Sliding window with Redis sorted sets — accuracy vs. memory cost
- Replication lag and what it means for enforcement correctness
Scalability and edge cases:
- Rate limiting at different granularities: per user, per IP, per API key, per tenant
- What happens when Redis goes down — fail open vs. fail closed
- Multi-region deployments — eventual consistency trade-offs
- Rate limit headers in responses (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After)
- Thundering herd on limit reset — jitter strategies
4) Round 4 — Hiring Manager (HM): System Design LLD + Behavioral
Design: Food Delivery App (Low-Level Design)
This was framed as an HM round but went very deep technically — class design, API contracts, and real-world trade-offs were all on the table.
Core entities and class design:
- Key entities: User, Restaurant, MenuItem, Order, Cart, DeliveryAgent, Payment
- Order state machine: placed → confirmed → preparing → picked_up → delivered / cancelled
- Separation of concerns — order service, delivery service, payment service, notification service
Delivery assignment:
- Geospatial indexing to find nearby agents — geohash vs. quadtree
- Agent assignment strategy — nearest first vs. load-balanced
- Handling agent unavailability mid-delivery — reassignment flow
Trade-offs discussed in depth:
- Synchronous vs. asynchronous order confirmation flow
- Strong consistency for payments vs. eventual consistency for delivery status updates
- Push (WebSocket / SSE) vs. poll for real-time order tracking
- Idempotency in payment retries — how to avoid double charges
- Database schema choices — relational for orders/payments, document store for menus
- Caching menu data — TTL strategy, cache invalidation on restaurant updates
Behavioral:
- A time I influenced a technical direction without direct authority
- How I handle disagreement with a senior stakeholder
- A system I built that I'm most proud of and why