Google binary search interview

Most engineers preparing for a Google binary search interview practice the wrong variant. They drill sorted-array search until they can write it with their eyes closed. Then they sit down in the actual interview, see a problem about shipping packages or calculating speeds, and don't recognize it as binary search at all.

The pattern Google actually tests most often isn't classic binary search. It's predicate search, a variant that binary-searches on the answer space instead of a sorted array. Most prep platforms don't even name it.

How we collected this data

Every problem across Codeintuition's 16 courses carries company tags based on where that problem has appeared in real interviews. The Searching course alone covers 27 problems across 5 distinct search patterns, each tagged to specific companies.

The data here comes from those tags. When we say "Google tests predicate search," we mean Google-tagged problems on the platform cluster around that specific pattern at a higher rate than any other FAANG company. This isn't scraped from interview forums or estimated from self-reports. It's derived from the problems themselves and the companies that ask them.

The sample is limited to Codeintuition's problem bank, not the entire universe of interview questions. But the pattern signal is consistent enough to say something useful about what Google favors.

Google binary search interview problems cluster around one variant

Binary search appears across 7 major companies in our tagging data: Apple, Google, Amazon, Adobe, Uber, Facebook, and Yahoo. No surprise there, since classic binary search is a foundational skill.

But look at where Google's binary search shows up. Their interview problems don't just test "find an element in a sorted array." They test a completely different application of the same algorithmic principle. Here are the Google-tagged predicate search problems.

None of these problems mention sorted arrays. None of them look like textbook binary search. Yet they all use the exact same algorithmic structure: define a monotonic boolean predicate on the answer space, then binary-search for the boundary.

Amazon and Apple also test binary search heavily, but their problems distribute more evenly across classic binary search, lower bound, upper bound, and 2D search. Amazon covers the widest range of search variants of any company in the dataset. Microsoft and Apple both test 2D Binary Search and Staircase Search at rates other companies don't match. Google's concentration on predicate search stands out.

That doesn't mean Google only cares about predicate search. But when a Google interview includes a binary search problem, there's a higher chance than at any other FAANG company that it requires answer-space reasoning rather than array-element lookup. If you've only practiced the array version, you're underprepared for the variant they favor most.

Predicate search problems don't look like binary search

And this is where engineers get tripped up. Classic binary search has obvious signals. You see a sorted array, you need to find an element. The problem practically announces the algorithm.

Predicate search flips the concept. Instead of searching through a data structure, you're searching through possible answers. A lot of optimization problems have a monotonic property: if an answer of size X works, then every answer larger than X also works (or vice versa). That monotonicity means you can binary-search on the answer space itself.

Take Minimum shipping capacity as a worked example.

You have packages with weights [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] and need to ship them all within 5 days. Each day, the ship loads packages in order until the next package would exceed capacity. What's the minimum capacity?

The answer space ranges from the heaviest single package (10) to the total weight (55). For any candidate capacity, you can check: "Can I ship everything in 5 days with this capacity?" That check is a simple greedy simulation. And if capacity 15 works, then 16, 17, 18, and every larger value also works.

That monotonic predicate is the whole trick. Below some threshold, the answer is "no." Above it, "yes." Binary search finds the exact boundary.

The binary search code itself looks identical to classic binary search. The difference is what you're searching. You're not looking for an element in an array. You're looking for a boundary in the answer space where a boolean condition flips.

LeetCode's tagging system contributes to the blind spot here. On LeetCode, Minimum Shipping Capacity is tagged as "Binary Search" and "Array." Punctual Arrival Speed doesn't exist under that name. Trip Completion Frenzy doesn't either. There's no unifying "Predicate Search" category that groups these problems together and teaches the shared structure. You might solve three of them and never realize they're the same pattern.

Most platforms never name this pattern

LeetCode has the problems. You can find Minimum Shipping Capacity, Koko Eating Bananas (a predicate search variant), and similar problems in the problem bank. But they're scattered across different tags and difficulty levels with no unifying concept. A problem tagged "Binary Search" and "Array" doesn't tell you that the core technique is answer-space search with a monotonic predicate. It tells you the solution uses binary search somewhere, which you already knew from the difficulty rating.

NeetCode's roadmap includes some predicate search problems in its binary search section, but doesn't teach predicate search as a named, distinct pattern with its own identification triggers. You work through the problems and might extract the pattern yourself, or you might not.

That gap matters.

Because identification is the hard part. Once you know a problem is predicate search, the implementation is straightforward: define the search space, write the feasibility check, run binary search. The real challenge is looking at "What's the minimum speed to arrive on time?" and recognizing that speed is a searchable answer space with a monotonic feasibility predicate.

The concept of monotonicity is what makes this work. If you can prove that the feasibility function never flips back (once true, always true for larger values), binary search is guaranteed to find the boundary. If you understand this property, you can verify your approach is correct before writing a single line of code. Without it, you're guessing.

This goes beyond Google specifically. Most resources treat binary search as a single technique with variations. But the jump from "search a sorted array" to "search the answer space" is a genuine conceptual leap. It's closer to the greedy-to-DP transition than the lower-bound-to-upper-bound one. Treating them as the same pattern undersells how hard it is to recognize the second one in the wild.

Codeintuition splits predicate search into two explicitly named patterns in the Searching course: Minimum Predicate Search and Maximum Predicate Search. Each has its own understanding lesson, its own identification lesson teaching the structural triggers, and its own problem set. The identification training is what matters for Google interviews. You learn to spot the monotonic predicate before you see the solution.

What this means for your interview preparation

If you're targeting Google specifically, the data points toward a clear priority shift. Classic binary search on sorted arrays is table stakes. The differentiator is whether you can look at an optimization problem with no sorted data in sight and recognize that the answer space is searchable.

Predicate search is the pattern that separates candidates, and most people skip it because they don't realize it's a distinct skill to train. What this looks like in practice:

Codeintuition's learning path sequences searching after sorting, so you arrive at predicate search with the prerequisite reasoning already in place. The predicate search sections alone include 8 problems covering both minimum and maximum variants, each with company tags showing exactly where that specific pattern appears in real interviews.

You've almost certainly practiced binary search for Google. But have you practiced the right binary search for Google?