Binary Search Beyond Sorted Arrays: The Coding Interview Pattern People Underestimate

Most candidates think of binary search as a warm-up: find a number in a sorted array, return its index, done. In real coding interviews it shows up far more often, just in disguise. Interviewers like it because a correct solution is short, but getting the boundaries right under pressure separates people who memorized the template from people who understand it. 1. Recognize the disguise Binary search applies whenever you can ask a yes/no question about a candidate answer, and the answers flip from "no" to "yes" exactly once as the candidate grows. That property is called monotonicity. Classic disguises include: - "Find the minimum speed / capacity / time such that X is possible" (shipping packages in D days, eating bananas in H hours). - "Find the first bad version" or "first index where a condition becomes true." - Searching a rotated sorted array, where one half is always sorted. - Finding a peak element, where you compare mid with mid+1 to decide which side must contain a peak. - Finding the k-th smallest value in a sorted matrix by searching over values, not positions. When you read a problem that says "minimum maximum" or "maximum minimum", say out loud: "This smells like binary search on the answer." Interviewers love hearing that pattern recognition. 2. Use one template and stick to it Bugs in binary search almost always come from mixing templates. Pick one and use it everywhere. A reliable choice is the "first true" template: lo, hi = smallest possible answer, largest possible answer while lo < hi: mid = lo + (hi - lo) // 2 if condition(mid): hi = mid else: lo = mid + 1 return lo The loop ends when lo == hi, and that value is the smallest candidate for which condition is true. Because hi = mid (not mid - 1) and lo = mid + 1, the range always shrinks and you never skip the answer. If the answer might not exist at all, check condition(lo) once after the loop. 3. Write the condition function separately For "binary search on the answer" problems, the real work is the feasibility check. Write it as its own helper, for example canShip(capacity) that walks the array greedily and counts days. Then the binary search becomes trivial and the interviewer can follow your logic. It also makes testing easy: call the helper on two or three hand-picked values before wiring it into the loop. 4. Talk through invariants A strong signal in an interview is explaining why your loop is correct, not just that it passes the example. Say something like: "Everything left of lo is known false, everything from hi onward is known true, and the loop keeps that invariant." That one sentence shows you are not guessing at plus-or-minus-one adjustments. 5. Test the edges on purpose Before you declare victory, run through: - An array of length one. - The answer at the very first or very last position. - All elements identical. - A target smaller than everything or larger than everything. Walking through these quickly is often where you catch an infinite loop caused by mid = (lo + hi) // 2 combined with lo = mid. 6. State the complexity correctly For binary search on the answer, the complexity is O(n log R), where R is the size of the answer range and n is the cost of one feasibility check. Candidates often say O(log n) out of habit, which is a small but noticeable mistake. Practicing under realistic conditions Knowing the template at your desk is different from producing it while someone watches. Practice by solving five or six disguised problems in a row, timing yourself, and explaining each step aloud. During live rounds, some candidates also use Linkjob AI (https://linkjob.ai), which gives real-time help during job interviews and technical interviews, as a safety net for structuring their explanation when nerves hit. Whatever tools you use, the goal is the same: recognize the monotonic condition, apply one template you trust, and explain your invariant clearly.