First Bad Version - Problem

You're a product manager leading a software development team, and your latest product release has failed quality assurance! ๐Ÿ˜ฑ

Here's the challenge: your team develops software versions sequentially [1, 2, 3, ..., n], where each version builds upon the previous one. Unfortunately, once a bad version is introduced, all subsequent versions inherit the same issues and become bad too.

Your mission: Find the first bad version that started this cascade of problems!

๐Ÿ”ง Available Tool: You have access to an API function isBadVersion(version) that returns true if the version is bad, false otherwise.

โšก Constraint: Minimize the number of API calls - each call is expensive!

Example: If you have versions [1,2,3,4,5] and version 4 was the first bad one, then versions 4 and 5 are bad, while 1,2,3 are good. Your function should return 4.

Input & Output

example_1.py โ€” Basic case
$ Input: n = 5, bad = 4 Versions: [1,2,3,4,5] isBadVersion(1) = false isBadVersion(2) = false isBadVersion(3) = false isBadVersion(4) = true isBadVersion(5) = true
โ€บ Output: 4
๐Ÿ’ก Note: Version 4 is the first bad version. Versions 1, 2, and 3 are good, while versions 4 and 5 are bad.
example_2.py โ€” Edge case - first version bad
$ Input: n = 1, bad = 1 Versions: [1] isBadVersion(1) = true
โ€บ Output: 1
๐Ÿ’ก Note: The only version available is bad, so version 1 is the first (and only) bad version.
example_3.py โ€” Large range
$ Input: n = 10, bad = 7 Versions: [1,2,3,4,5,6,7,8,9,10] Good: [1,2,3,4,5,6] Bad: [7,8,9,10]
โ€บ Output: 7
๐Ÿ’ก Note: Version 7 is the first bad version. Using binary search, we can find this efficiently in about 3-4 API calls instead of 7.

Visualization

Tap to expand
Finding the First Bad Versionv1 โœ“v2 โœ“v3 โœ“v4 โœ—v5 โœ—v6 โœ—v7 โœ—๐Ÿ” Binary Search in ActionInitial range: versions 1-7Check v4 (middle)v4 is bad โ†’ first bad is in range 1-4Check v2.5โ†’v3v3 is good โ†’ first bad is in range 4-4๐ŸŽฏ Result: Version 4 is the first bad version!Binary search used only 2-3 API calls instead of checking all 4 versionsGood VersionBad VersionFirst Bad Version
Understanding the Visualization
1
The Timeline Setup
We have versions 1 through n, where good versions are followed by bad versions: GOOD|GOOD|GOOD|BAD|BAD|BAD
2
Binary Search Strategy
Instead of checking every version, we check the middle and eliminate half the timeline each time
3
Narrow Down
If middle version is good, bug is in second half. If bad, bug is in first half (including middle)
4
Found the Culprit
Continue until our search window contains just one version - the first bad one!
Key Takeaway
๐ŸŽฏ Key Insight: The boundary between good and bad versions creates a perfect binary search scenario, reducing time complexity from O(n) to O(log n) and minimizing expensive API calls!

Time & Space Complexity

Time Complexity
โฑ๏ธ
O(log n)

Each iteration eliminates half of the remaining search space, so we need at most logโ‚‚(n) iterations

n
2n
โšก Linearithmic
Space Complexity
O(1)

Only using constant extra space for the left, right, and mid pointers

n
2n
โœ“ Linear Space

Constraints

  • 1 โ‰ค bad โ‰ค n โ‰ค 231 - 1
  • At least one version is guaranteed to be bad
  • Each call to isBadVersion() should be minimized for optimal performance
Asked in
Facebook 45 Google 38 Microsoft 32 Apple 28
68.0K Views
High Frequency
~15 min Avg. Time
2.2K Likes
Ln 1, Col 1
Smart Actions
๐Ÿ’ก Explanation
AI Ready
๐Ÿ’ก Suggestion Tab to accept Esc to dismiss
// Output will appear here after running code
Code Editor Closed
Click the red button to reopen