Nineteen companies test LRU Cache in coding interviews. That number gets thrown around a lot, but the more useful detail is underneath it. The Amazon vs Google coding interview DSA split is wider than most engineers expect. Company tags across 450+ handpicked problems show that Amazon tests 11+ distinct pattern categories (the broadest of any company), Google uniquely tests predicate search (a pattern most engineers can't even name), and Meta, Microsoft, and Apple each have their own distinct signatures.

Amazon tests more distinct DSA pattern types in interviews than any other major tech company, covering hash tables, searching, design, and backtracking. Google uniquely emphasizes predicate search, a binary search variant applied to the answer space that most preparation platforms never label as a separate pattern. Meta focuses on sliding window and design problems, while Microsoft tests 2D binary search and staircase search at a higher rate.

How We Collected This Data

Every problem on Codeintuition carries company tags based on which companies are known to test it. These tags span all 16 courses and 450+ problems across the structured learning path. The data is curated from verified interview problem sets collected from public sources (including Glassdoor interview reports, LeetCode company-tagged discussions, and preparation platforms that publish company associations), then cross-referenced for consistency and attached to specific patterns within the course structure. It's not scraped from a single forum or self-reported by users.

That means we can map pattern frequency by company, not just raw problem frequency. When we say "Google emphasizes predicate search," it's not a guess from a handful of discussion posts. It comes directly from company tags attached to problems that teach that specific pattern. A single LeetCode forum post saying "I got asked binary search at Google" tells you nothing about which variant of binary search Google actually prefers. Company-tagged problem data, mapped to specific patterns, does.

The analysis covers Amazon, Google, Meta (Facebook), Microsoft, and Apple. These five account for the highest concentration of pattern-specific tags in the dataset. Other companies like Uber, LinkedIn, Adobe, Stripe, and Oracle appear too, but with fewer tagged data points per individual pattern.

The DSA Patterns Every FAANG Coding Interview Tests

Before the company-specific differences matter, there's a universal layer. Seven patterns appear at 6 or more major companies in the dataset. These aren't optional for anyone targeting big tech.

The most prominent is LRU Cache, tagged at 19 companies. That includes every FAANG member, plus DoorDash, Oracle, Zoom, PayPal, Twilio, TikTok, eBay, Yandex, LinkedIn, Zillow, Intuit, and Cloudera. An engineer who can't implement LRU Cache from scratch under time pressure is unprepared for design rounds at most top-tier companies. The problem tests hash table mechanics, linked list manipulation, and design thinking at once, which is exactly why it shows up everywhere. No single alternative problem covers the same combination. The remaining six universal patterns:

If you're targeting any combination of big tech companies, these seven patterns come first. Cover them before you specialize.

Where the Patterns Split

The universal patterns get you to the table. The company-specific patterns determine whether you're actually prepared for the interview you're walking into.

Amazon: the broadest pattern spread. Amazon tests Counting, Fixed and Variable Sliding Window, Prefix Sum, LRU Cache, Randomised Set, Binary Search, 2D Binary Search, Staircase Search, Maximum Predicate Search, Queue Design, and Backtracking. That's 11+ distinct pattern categories, more than any other company in the dataset. You can't narrow-focus for Amazon the way you might for Google or Meta. An engineer who prepared only DP and graph patterns would walk into Amazon's hash table, searching, and design questions unprepared. Amazon interviews are the least predictable by pattern type.

Google: the reasoning filter. Google shares the universal patterns but adds a distinctive emphasis on predicate search. This is binary search applied not to a sorted array, but to the answer space itself. Problems like Minimum Shipping Capacity ask you to find the smallest value that satisfies a feasibility condition. The answer lives in a range you construct, not in the input data, and you binary search that range by testing feasibility at each midpoint.

Take the shipping capacity problem. You're given packages with weights and D days to ship them. You need the minimum ship capacity. Instead of checking every capacity, you define the search range (from the heaviest single package to the total weight of all packages) and binary search it.

What separates this from classic binary search: you're searching a range you defined, not an array the problem gave you. You constructed the search boundaries from the problem constraints, then applied binary search to your own abstraction. Google tests this distinction more than any other company in the dataset, through problems like Punctual Arrival Speed, Trip Completion Frenzy, and Calculate Square Root. Each one requires the same mental shift from "search within given data" to "search within a range I defined based on the feasibility condition."

There's a reason this pattern goes unnamed on most platforms. LeetCode tags these problems "Binary Search" alongside classic sorted-array problems, even though sorted-array search and answer-space search require different mental models. Engineers who "know binary search" often freeze on predicate search problems because they're applying the wrong starting assumption. Google's interviews expose this gap consistently.

Meta: weighted toward design. Meta consistently tests Sliding Window (both Fixed and Variable), Prefix Sum, Counting, and Design (LRU Cache and Randomised Set). Maximum Predicate Search also appears in Meta's tags. Compared to Google, Meta places less emphasis on searching variants and more on hash table depth and design implementation. Amazon tests breadth, Google tests reasoning depth, and Meta wants hash table fluency and deep design knowledge in a tighter band of patterns than Amazon requires.

Microsoft and Apple round out the picture. Microsoft is distinct for 2D Binary Search and Staircase Search, multi-dimensional patterns that appear less frequently at other companies. These test spatial reasoning in ways that most preparation plans skip entirely. Apple tests fundamentals with unusual depth: five Counting problems carry Apple tags, alongside Binary Search, Prefix Sum, and Backtracking. Apple's data suggests a preference for candidates who've built strong basics before moving to advanced techniques.

What FAANG Interviews Don't Test

What a company doesn't test matters just as much for preparation planning. Every hour spent on patterns your target company doesn't emphasize is an hour that could've gone to patterns they do.

Google shows minimal tags for Queue Design and 2D Binary Search in the dataset. If you're targeting Google specifically, those patterns aren't a priority compared to predicate search and graph-based reasoning. Save the multi-dimensional search prep for a Microsoft or Apple pipeline. That reallocation alone could save you a week of misdirected practice.

Meta has lower coverage of searching variants compared to Amazon and Google. The Staircase Search and 2D Binary Search patterns that Microsoft emphasizes don't appear in Meta's interview problem sets in our data. Meta's signal points toward hash table depth and design, not search breadth. Microsoft shows fewer tags for Variable Sliding Window and Predicate Search, tilting instead toward structured, multi-dimensional search problems. If you're targeting Microsoft, weight 2D search higher and variable-window lower.

Apple is the opposite case. Tags cluster tightly around fundamentals. The breadth of advanced design problems (Randomised Set, Queue Design) that Amazon tests doesn't appear in Apple's data at all. Apple's interviews reward deep understanding of the basics over broad pattern coverage. Those gaps matter more than most preparation plans acknowledge.

What This Means for Your Preparation

The data points to a specific preparation sequence.

Most platforms organize problems by data structure, which buries the company-level signal entirely. Every problem on Codeintuition carries company tags, and the 75+ patterns are taught with explicit identification training before any problem-solving begins. That turns these findings into a concrete filter: learn the patterns tagged for the companies you're interviewing at, in the order that maximizes coverage across your target list. For more detail, see our FAANG coding interview preparation guide.

Companies shift emphasis as roles and teams evolve, and 450+ problems is a snapshot, not a census. But the five companies don't all test the same things, and preparing as if they do wastes time you don't have.

Before this data, you'd study "binary search" as one category and hope it covered everything. After it, you split your preparation. Sorted-array search for the universal baseline, predicate search specifically for Google. Same study hours, different allocation, different readiness for the interview you're actually walking into.