Binary Search Patterns for LeetCode Interviews

When you hear "binary search," you probably picture searching for a target in a sorted array. That is the textbook version, and it barely scratches the surface. In real coding interviews, binary search shows up in problems that do not look like binary search at all — minimizing shipping capacity, finding the rotation point of an array, or determining how fast a monkey needs to eat bananas.

The core idea is always the same: you have a search space, a condition that partitions that space into two halves, and you eliminate one half at each step. That gives you O(log n) time, which is why interviewers love it. The challenge is recognizing when binary search applies and choosing the right template.

This guide covers the three major binary search pattern families you will encounter in LeetCode and real interviews: classic sorted array search, rotated array search, and binary search on the answer space. Master these and you will handle 15+ common interview problems with confidence.

Every binary search problem starts with the same skeleton: define a left and right boundary, compute a midpoint, and decide which half to eliminate. But the details of that skeleton — the loop condition, how you update boundaries, and what you return — change depending on the problem. Getting these details wrong is the number one source of binary search bugs.

The most versatile template uses left <= right as the loop condition, checks if the midpoint matches the target, and narrows the range by setting left = mid + 1 or right = mid - 1. This works perfectly when you are searching for an exact value in a sorted array. For problems where you need to find a boundary (the first element greater than X, or the insertion point), you will use a variation where right = mid instead of right = mid - 1.

Before writing any binary search code, ask yourself three questions: What is my search space? What condition splits the space into two halves? And do I need to find an exact match or a boundary? The answers determine which template to use.

The classic sorted array problems are where most people learn binary search, and they remain common in interviews. Binary Search (#704) is the purest form: given a sorted array and a target, return its index or -1. This is the warm-up, but do not skip it — getting the boundary updates right here builds the muscle memory for harder variants.

Search Insert Position (#35) adds a twist. If the target is not found, return where it would be inserted to keep the array sorted. This is your first boundary search: instead of returning -1 on a miss, you return left after the loop ends. The left pointer naturally converges to the correct insertion point because it only moves right past elements that are too small.

Find First and Last Position of Element in Sorted Array (#34) requires two binary searches: one to find the leftmost occurrence and another for the rightmost. For the leftmost search, when you find the target, you do not return immediately — you set right = mid to keep searching left. For the rightmost, you set left = mid + 1 to keep searching right. This pattern of "find but keep searching" is fundamental.

These three problems together teach you the full range of sorted-array binary search. Practice them until the boundary logic is automatic, because every harder binary search problem builds on this foundation.

Rotated sorted arrays are a favorite interview topic because they test whether you truly understand binary search or just memorized the sorted-array version. A rotated array like [4, 5, 6, 7, 0, 1, 2] was originally sorted but "rotated" at some pivot — meaning one half is always sorted and the other contains the rotation point.

Search in Rotated Sorted Array (#33) is one of the most frequently asked binary search problems across FAANG interviews. The key insight is that when you compute mid, at least one half of the array (left to mid, or mid to right) is guaranteed to be sorted. You check which half is sorted, then determine if the target falls within that sorted half. If it does, search there. If not, search the other half.

Find Minimum in Rotated Sorted Array (#153) flips the problem: instead of finding a target, you find the rotation pivot. Compare the midpoint to the rightmost element. If mid is greater, the minimum is to the right of mid. If mid is less, the minimum is at mid or to the left. This converges to the smallest element in O(log n).

The common thread in rotated array problems is that you cannot blindly compare to the target or to mid alone — you must also consider which portion of the array is sorted and reason about the target relative to that sorted portion.

Binary search on the answer space is one of the most powerful and underrated patterns in competitive programming and interviews. Instead of searching within the input array, you define a range of possible answers and binary search for the optimal one. If you see phrases like "minimize the maximum," "find the smallest X such that," or "what is the minimum capacity," think binary search on the answer space immediately.

Koko Eating Bananas (#875) is the perfect introduction. Koko has piles of bananas and h hours to eat them all. You need to find the minimum eating speed k. The answer space is 1 to max(piles). For each candidate speed, you calculate the total hours needed — if it fits within h, the speed might work (search lower), otherwise search higher. The feasibility check is a simple O(n) loop, and binary search over the answer space gives you O(n log m) total.

Capacity to Ship Packages Within D Days (#1011) follows the same structure. The answer space is max(weights) to sum(weights). For each candidate capacity, simulate loading the ship day by day. If you finish within D days, the capacity might work — try smaller. Split Array Largest Sum (#410) is the hardest variant: minimize the maximum sum when splitting an array into m subarrays. Same binary search skeleton, different feasibility check.

The beauty of this pattern is its consistency. Once you identify that the problem is asking for an optimal value within a range, the solution is almost always: define the range, write a feasibility function, and binary search. The feasibility function changes per problem, but the binary search wrapper stays the same.

Binary search is conceptually simple but notoriously hard to implement correctly. Research from Jon Bentley found that most programmers who were confident in their binary search implementation had bugs. The mistakes are almost always in the details: off-by-one errors in boundary updates, wrong loop conditions, or infinite loops from forgetting to exclude mid.

The most common bug is an infinite loop caused by setting left = mid when left and right are adjacent. If left = 3 and right = 4, then mid = 3, and left = mid keeps left at 3 forever. The fix is to use left = mid + 1 when you can safely exclude mid, or to use the left < right - 1 template that guarantees at least 3 elements in the range.

Another frequent mistake is choosing the wrong loop condition. Using left <= right when you need boundary convergence (left < right) means the loop runs one extra iteration and can return the wrong index. Using left < right when you need exact match means the loop might exit before checking the last element. Match your loop condition to your problem type.

Finally, watch for integer overflow when computing the midpoint. In languages with fixed-size integers like Java or C++, (left + right) / 2 can overflow. Always use left + (right - left) / 2 instead. In JavaScript and Python this is less of a concern, but it is a good habit that interviewers notice.

Binary search is a pattern where repetition genuinely builds intuition. The first time you solve Koko Eating Bananas, the answer-space approach feels like a leap of insight. By the third or fourth answer-space problem, you spot the pattern immediately. The key is deliberate, spaced practice — not grinding 20 binary search problems in one afternoon.

Start with the sorted array problems (#704, #35, #34) until the boundary logic is automatic. Then move to rotated arrays (#33, #153) to learn how to reason about partially sorted data. Finally, tackle answer-space problems (#875, #1011, #410) — these are the ones most likely to appear in real interviews because they test problem modeling, not just implementation.

YeetCode flashcards are designed for exactly this progression. Each binary search problem is broken into a flashcard that tests pattern recognition — can you identify that a problem is a binary search problem, choose the right template, and recall the boundary conditions? Spaced repetition ensures you review problems right before you would forget them, building the deep recall that survives interview pressure.

The goal is not to memorize solutions. It is to build the reflexive ability to look at a problem, recognize the binary search structure, select the right template, and implement it correctly the first time. That comes from practice, and smart practice means reviewing at the right intervals.