Salesforce Interview Experience (SMTS) | Backend
Summary
I completed a four‑round interview loop for a Salesforce SMTS Backend role, covering an online assessment, a DSA and project deep‑dive, a high‑level system design, and a hiring‑manager LLD plus behavioral round.
Full Experience
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
Please up‑vote, to motivate me to upload my other interview experiences :)
Interview Questions (3)
Token Bucket / Resource Grant System
Design a system that manages a bucket containing a limited number of tokens. Users can request a specific number of tokens; the request is granted only if enough tokens are available. Granted tokens are held for exactly one hour, after which they are automatically returned to the bucket. The system must expose three operations:
requestTokens(userId, n): attempt to allocatentokens touserId.releaseTokens(userId): manually release all tokens held byuserIdbefore the hour expires.- A background expiry mechanism that automatically returns tokens to the bucket when the one‑hour lease ends. Key considerations include efficient expiry handling (e.g., using a min‑heap or priority queue ordered by expiry time), concurrency control (locking vs. atomic operations), handling partial grants, and ensuring correct time‑complexity for grant and release operations.
Distributed Rate Limiter Design
Design a distributed rate‑limiting system that can be applied at various granularities (per user, per IP, per API key, per tenant). Discuss multiple algorithms (Token Bucket, Leaky Bucket, Fixed Window Counter, Sliding Window Log/Counter) and their trade‑offs in terms of accuracy, memory usage, and throughput. Explain how you would store counters using Redis, including approaches like INCR+EXPIRE vs. Lua scripts for atomicity, and how to implement sliding‑window counters with Redis sorted sets. Address failure scenarios such as Redis outage (fail‑open vs. fail‑closed), multi‑region consistency, replication lag, and strategies for handling thundering herd on limit reset (e.g., jitter). Also include how rate‑limit headers would be returned to clients.
Food Delivery App Low‑Level Design
Create a low‑level design for a food delivery platform. Identify core entities (User, Restaurant, MenuItem, Order, Cart, DeliveryAgent, Payment) and define their relationships. Design an order state machine (placed → confirmed → preparing → picked_up → delivered / cancelled) and outline service boundaries (order service, delivery service, payment service, notification service). Explain how to locate nearby delivery agents using geospatial indexing (e.g., geohash or quadtree) and decide on an assignment strategy (nearest first vs. load‑balanced). Discuss handling agent unavailability mid‑delivery, synchronization mechanisms, and trade‑offs such as synchronous vs. asynchronous order confirmation, consistency models for payments vs. delivery status, real‑time updates (WebSocket/SSE vs. polling), idempotent payment retries, database choices (relational vs. document), and caching strategies for menu data.
Preparation Tips
Practice solving timed medium‑difficulty coding problems on platforms like HackerRank or LeetCode, focusing on clean, compilable code and edge‑case handling. Review and deep‑dive into at least one major past project, being ready to discuss architecture decisions, bottlenecks, reliability, and trade‑offs. Study common system‑design patterns such as token‑bucket and leaky‑bucket rate limiters, distributed storage with Redis, and consider failure modes. For low‑level design, be familiar with core domain entities, state machines, geospatial indexing techniques, and consistency vs. latency trade‑offs. Prepare behavioral stories that showcase influence without authority, conflict resolution, and impactful projects.