Data-Structure Design

Roughly a fifth of the Salesforce coding surface is a data-structure design problem. The ask is less "use a hash map" and more "implement the structure itself as a class, with the eviction or ordering rule that makes it work." The loop draws these from a short, recognizable list. A Premium question is the one named most often and sits at the top of the difficulty band. A running median over a stream, a stack that pops by frequency, and a trie fill out the rest. Each is graded on the same thing: whether your data model makes every operation cheap, and whether you can name the invariant that keeps it correct as entries come and go.

The shape is always a lookup structure married to an ordering structure. A hash map answers "where is this key" in constant time; a second structure, a doubly linked list, a pair of heaps, a bucket keyed by frequency, answers "what leaves next." Get those two talking and the operations fall out. The interviewer is watching where you put the tie-break rule and whether the two structures ever drift out of sync. Build each class in the editor before opening the walkthrough, and say the eviction rule aloud first.

The Salesforce angle

A cache in front of CRM records is a multi-tenant object, so eviction is a shared resource that one org must not be allowed to monopolize. Salesforce runs one logical store that thousands of customers hit at once, and the platform's governor limits exist to stop a single greedy org from starving the rest. An LFU policy writes that instinct down as a data structure. Entries earning their keep across all tenants stay resident, and cold ones fall out first. Frequency ties break by recency, so a burst from one org cannot pin a stale row forever. Modeling the cache as a class rather than reaching for OrderedDict is what makes that policy an auditable object. The eviction rule lives in one method you can reason about, instead of being smeared across call sites.