After treating every FAANG company like the same interview, Amazon exposed the gap in about twenty minutes.
I'd built FAANG prep around a small set of pattern families that looked highest-frequency: predicate search, sliding window, hash table fundamentals, and a few graph traversals.
The mental model was that these were the patterns "every big tech round" sampled from.
The first Amazon round asked about Randomised Set design followed by a Queue Design follow up.
Neither was in the deep set the plan covered.
I solved the first one with effort and improvised the second one badly.
The interview went south in the last 20 minutes.
The thing missing wasn't a specific pattern.
It was that Amazon's pattern footprint is meaningfully wider than Google's, and the prep allocation behind every hour was treating every FAANG company as if they sampled from the same bag.
Here's what came out of mapping company tags across 450+ handpicked FAANG problems:
- Seven patterns are universal across 6+ major companies. Skipping any of them is a structural hole.
- Amazon spans 11+ pattern families, the broadest in the data. "Study three patterns deeply" doesn't work there.
- Google has narrower coverage but a distinctive emphasis on
predicate search (binary search on the answer space).
- Meta wants hash table depth and design fluency in a tighter pattern band.
- Prefix Sum is the single most undertrained pattern relative to its 8-company tag count.
Where the old approach was breaking
The old plan looked roughly like this:
Pick five or six pattern families that look universal-ish, drill them to the point you can write the canonical solution from memory, then trust that volume on adjacent problems will generalise to whatever the interview throws.
The implicit bet was that every FAANG company is a sample from roughly the same distribution, and the mean of the drilled patterns covers the mean of the question pool.
The data didn't support the bet.
The surprising part wasn't that companies differed.
It was how much they differed.
Across the company tags:
- Google's distribution skewed toward predicate search and graph reasoning. Narrower set, harder reasoning per problem.
- Amazon's distribution was the flattest of any company in the set. Eleven plus pattern families, none dominant.
- Meta's distribution clustered tight: sliding window, prefix sum, counting, design.
- Microsoft had a quietly distinct cluster: 2D binary search and staircase search, multi-dimensional patterns most plans skip.
- Apple's distribution was the inverse of Amazon's: deep on fundamentals (especially counting), almost no advanced design.
The mistake wasn't drilling the wrong patterns.
It was applying the same allocation across companies that didn't share the same allocation.
The shift that worked
The shift was small in description and large in practice.
Instead of one prep plan, the move was to build a per-company allocation, anchored to the universal patterns underneath.
Concretely:
| Then | Now |
|---|
| Drill 5–6 patterns deeply, hope coverage generalises | Cover 7 universals first, then add 2–4 patterns specific to the target company |
| Pick problems by data structure (Hash Table, Tree, Graph) | Pick problems by pattern, then filter by company tag |
| Treat all FAANG rounds as the same problem distribution | Allocate by the company’s actual tag profile |
| Practise at uniform intensity across pattern families | Front load the universals, then go deep on company-specific gaps |
The 7-pattern universal layer never moved:
- LRU Cache
- Counting
- Backtracking
- Prefix Sum
- Binary Search
- Fixed Sliding Window
- Variable Sliding Window
What changed was what came after.
For an Amazon round, the next four patterns to drill were:
- Randomised Set
- Queue Design
- 2D Binary Search
- Staircase Search
plus dedicated time on the Bar Raiser follow up format.
For Google, the next two patterns were:
- Predicate Search
- Graph reasoning
drilled deeper.
For Meta:
- Design depth (
LRU Cache from scratch, Randomised Set from scratch)
- Maximum Predicate Search
The total prep time stayed roughly the same.
The allocation was different.
What that looked like on the next problem
The clearest example was LRU Cache.
The canonical solution had been in the toolkit for years:
- hash map + doubly linked list
O(1) per operationhead and tail sentinels
What I'd never done was rebuild it under a constraint shift.
Which is exactly what the Amazon Bar Raiser round likes to test.
The setup is the standard one:
class LRUCache:
def __init__(self, capacity):
self.capacity = capacity
self.map = {}
self.head = ListNode() # most recently used end
self.tail = ListNode() # least recently used end
self.head.next = self.tail
self.tail.prev = self.head
def get(self, key):
if key not in self.map:
return -1
node = self.map[key]
self._remove(node)
self._add_to_front(node)
return node.value
def put(self, key, value):
if key in self.map:
self._remove(self.map[key])
node = ListNode(key, value)
self._add_to_front(node)
self.map[key] = node
if len(self.map) > self.capacity:
lru = self.tail.prev
self._remove(lru)
del self.map[lru.key]
The constraint shift Amazon likes to ask:
“Now each entry has a TTL. A read on an expired entry returns -1. The cache still operates at expected O(1) per call.”
That's the moment the canonical answer stops being enough.
The candidate who memorised LRU starts redesigning from scratch.
The candidate who built the original from the invariant asks one question first:
Which invariant did the doubly linked list maintain, and does that invariant still hold under TTL?
The list maintained an ordering:
Nodes near head were used more recently than nodes near tail.
The eviction criterion changes from:
“Least recently used”
to:
“Expired or least recently used.”
The list ordering by recency is still useful for the second clause.
The first clause needs a different signal.
That's where lazy expiry (timestamp checked on read) and eager expiry (min heap on TTL) diverge.
The canonical LRU sits in most candidates' heads.
The constraint flip doesn't.
Once practising the follow up explicitly becomes part of the loop, on every design problem in the universal set, the conversion rate on Amazon-style rounds shifts noticeably.
The pattern that's underrated for years
Looking back at the tag data, the single biggest miscalibration in the old plan was Prefix Sum.
Eight companies tag it.
That's the same as Backtracking.
More than almost every classic searching variant except the basic one.
Most prep plans treat it like a minor utility pattern because it doesn't have a flagship problem the way LRU Cache does.
In the data, it punches above its weight:
- Subarray Sum Equals K
- Equilibrium Index
- Count Subarrays Divisible by K
especially in Meta and Amazon variants.
The fix took less than a weekend.
Prefix Sum's mechanic is small enough that two evenings of focused drilling cover it.
The composite version (prefix sum + hash map of seen sums) is the FAANG-shaped one, and it's the one most prep plans bury under a miscellaneous heading.
What works for someone in the same spot
Three rules from the retrospective:
1. Cover the seven universals first
No exceptions.
- LRU Cache
- Counting
- Backtracking
- Prefix Sum
- Binary Search
- Fixed Sliding Window
- Variable Sliding Window
No matter the target company.
2. Specialise second
But specialise to the company’s actual tag profile.
For Amazon:
- breadth
- constraint-flip follow ups
For Google:
- predicate search
- graph reasoning depth
For Meta:
- design depth
- sliding window fluency
For Microsoft:
For Apple:
3. Cut what doesn't match
Targeting Google and not Amazon?
Queue Design can wait.
Targeting Meta and not Microsoft?
Staircase Search can wait.
Prep time is finite.
The data tells you where the false-priority work lives.
The biggest shift, though, wasn't any one pattern.
“FAANG prep” isn't one allocation problem.
It's five separate ones with a shared seven-pattern foundation.
The company determines which 2–4 patterns sit on top of it.
Every hour spent assuming the foundation was all that mattered was an hour that could've gone to the layer above.
Originally posted in a longer form on my own blog, with the per-company FAQ and a fuller breakdown of what each company quietly deemphasises.
If you've interviewed at more than one FAANG, what was a pattern that came up where the company’s reputation hadn't prepared you for it?