What is the pricing and subscription model for Hi👋SpeedAlgo?

The entire core curriculum of 13 patterns and 225 practice problems is 100% free to access with no credit card required. New accounts get 40 free coins once, the daily claim adds +20 coins once a day, and inviting a friend earns you +25 coins when they complete their first practice step. These are the only ways to earn coins. Each AI coach question costs 1-5 coins, priced by the server according to its size. AI coaching is free with your own Google Gemini, OpenAI or OpenRouter API key (BYOK). Coins also unlock extras for 24 hours: a Recall hint level (1 coin), a Solve solution reveal (2), a LeetCode problem card's solutions (1) and a pattern's extra canonical problems (1). Nothing on the site is sold for money: coins can only be earned, never bought.

What is the refund and cancellation policy?

Hi👋SpeedAlgo sells nothing for money: there are no subscriptions, renewals or charges, so there is nothing to cancel or refund. Nothing on the site is sold for money: coins can only be earned, never bought.

Who creates and maintains the curriculum?

Hi👋SpeedAlgo is developed and maintained by Hi👋WebEnterprise (https://hiwebenterprise.com), an engineering organization focused on developer education, deliberate practice methodologies, and cognitive ergonomics for technical interviews.

How does Hi👋SpeedAlgo prepare candidates for senior and staff SWE interviews?

Rather than rote LeetCode grinding, Hi👋SpeedAlgo uses deliberate practice for each pattern: learn the loop invariant, Big-O proof and edge cases from a side-by-side template and a step-by-step debugger, rebuild the template from memory, then solve a new problem on your own against a graded test suite.

7. Maximum XOR of Two Numbers in an Array • Invariant Proof & Speed-Run

Theory Context•Bit Manipulation

MediumLC 421

Maximum XOR of Two Numbers in an Array (LeetCode 421)

Target Frequency:GoogleAmazonMicrosoft

Given an integer array nums, find the largest value obtainable by XOR-ing any two elements nums[i] and nums[j] (the same index may be reused, i.e. 0 <= i <= j < n).

Worked Examples

Example 1

Input:nums = [3,10,5,25,2,8]

Output:28

Explanation: The maximum result is 5 XOR 25 = 28.

Example 2

Input:nums = [14,70,53,83,49,91,36,80,92,51,66,70]

Output:127

Explanation: 91 XOR 36 = 127, and no other pair does better.

⚖️Formal Constraints & Bounds

1 <= nums.length <= 2 * 10⁵
0 <= nums[i] <= 2³¹ - 1

Deep-Dive & Conceptual Insights

Core Insight

Build the answer bit-by-bit from the most significant bit down. At each bit position, greedily assume the answer can have that bit set, then verify by checking whether two numbers' prefixes-so-far actually XOR to that candidate (via a hash set of prefixes or a walked bit-trie). A greedy bet that isn't provably achievable is simply skipped, so the final result is guaranteed maximal in O(32*N) time.

Real-World Scenario & Production Applications

Finding the two most dissimilar hash fingerprints in a deduplication index, maximizing Hamming distance between error-correcting codewords, and IP-routing longest-prefix-divergence lookups.

Subproblems & Recurrence Decomposition3 Phases

🧩Subproblem 1: Greedy Bit-by-Bit MSB-to-LSB Construction

Build the answer one bit position at a time, from the most significant bit (31) down to the least significant bit (0), growing a mask that exposes longer and longer prefixes of every number.

Mathematical Recurrence / Code Invariant

max_xor, mask = 0, 0
for i in range(31, -1, -1):
    mask |= (1 << i)

Step-by-Step Execution Trace Table

Worked trace: nums = [3, 10, 5, 25, 2, 8]

Bit `i`	mask	Prefix set (masked nums)	candidate = max_xor \vert (1<<i)	Verified?	max_xor after
4	`10000` (16)	{0, 16}	16	Yes (0 ^ 16 = 16)	16
3	`11000` (24)	{0, 8, 24}	24	Yes (0 ^ 24 = 24)	24
2	`11100` (28)	{0, 4, 8, 24}	28	Yes (4 ^ 24 = 28)	28
1	`11110` (30)	{2, 4, 8, 10, 24}	30	No	28
0	`11111` (31)	{2, 3, 5, 8, 10, 25}	29	No	28

Final max_xor = 28, achieved by 5 XOR 25 = 00101 ^ 11001 = 11100 = 28, matching the expected output.

Code Shape

Archetype Code Shape

Python

1	max_xor, mask = 0, 0
2	for i in range(31, -1, -1):
3	mask \|= (1 << i)
4	prefixes = {num & mask for num in nums}
5	candidate = max_xor \| (1 << i)
6	for p in prefixes:
7	if (candidate ^ p) in prefixes:
8	max_xor = candidate
9	break
10	return max_xor

Conceptual Narrative

🧭 Conceptual Foundation & Pattern Intuition

Every earlier bit-manipulation archetype processed ALL 32 bits of ONE number at a time. This archetype reverses that: it processes ONE bit position at a time, across ALL numbers at once, building the answer from its most significant bit down to its least significant bit — greedily locking in every bit it can prove is achievable.

🏔️ The Analogy: Building the Tallest Answer One Floor at a Time, Verified Before You Commit

Imagine constructing a skyscraper's blueprint one floor at a time, starting from the top (bit 31) down to the ground floor (bit 0). At each floor, you ask a greedy question: "Can I add a floor here and still have this building be physically buildable with the materials (numbers) I have?" You never build a floor speculatively and tear it down later — you only ever add a floor once you've proven two of your numbers share every floor built so far except this one, where they differ.

Trick 1 — Growing prefixes (mask |= (1 << i)): The mask exposes just the top (32 - i) bits of every number — everything built "so far", floor by floor.
Trick 2 — Prefix set (prefixes = {num & mask for num in nums}): Recompute every number's current prefix under the new, slightly-longer mask.
Trick 3 — The greedy bet (candidate = max_xor | (1 << i)): Assume you CAN set this floor's bit to 1 in the final answer.
Trick 4 — Verify with the XOR-inverse trick ((candidate ^ p) in prefixes): If some prefix p is in the set, and candidate ^ p is ALSO in the set, then those two prefixes XOR together to exactly candidate — the bet is provably achievable, so max_xor permanently locks in that bit. If no such pair exists, the floor can't be built here, and max_xor keeps its bit at 0 for this position — never regressing, only growing.

🔑 The Key Idea in the Code

This is the hash-set version of a bit-trie walk: instead of building 32 levels of trie nodes and walking root-to-leaf per number, you replay the same greedy "does a complementary prefix exist" check using plain sets, in O(32·N) time and O(N) space.

Quadratic $O(N^2)$ brute-force pair comparison: Comparing every pair of numbers takes $O(N^2)$ time, which TLEs on $N = 2 \cdot 10^5$ . A Binary Trie or prefix hash set greedy bit evaluation achieves $O(31 \cdot N) = O(N)$ time.
Prefix set bit search property: At each bit position from bit 30 down to 0, test if a candidate maximum prefix can be formed: if candidate ^ p exists in the prefix set, p1 ^ p2 == candidate is guaranteed.
Iterating LSB to MSB instead of MSB to LSB: Greedy XOR maximization must make decisions from most significant bit (bit 30) down to least significant bit (bit 0), because a higher bit outweighs all lower bits combined.
Maximum XOR of Two Numbers — rebuilding the WHOLE prefix set every bit, not incrementally: the mask only ever grows (bits are added, never removed), so prefixes = {num & mask for num in nums} must be recomputed fresh each iteration from the ORIGINAL numbers, not from the previous iteration's already-masked prefixes — masking an already-masked value with a larger mask is a no-op and silently breaks the invariant.
Maximum XOR of Two Numbers — checking candidate in prefixes instead of the XOR-inverse: the verification step is NOT "is candidate itself a prefix" — it is "does some prefix p have its partner candidate ^ p also present". Checking membership of candidate directly (rather than candidate ^ p) looks superficially similar but never actually confirms two DIFFERENT numbers combine to the candidate value.
Maximum XOR of Two Numbers — pairing a number with itself: the loop bounds 0 <= i <= j < n technically allow i == j, but x XOR x = 0 is never the maximum unless every element is identical; a trie/hash-set implementation naturally handles this since a number's own prefix is always present in the set, but a hand-rolled O(N^2) baseline must remember not to special-case away legitimate i == j in a way that also breaks i != j pairs.

Senior SWE Reasoning Architecture

4-Phase Thought Process Model

Pattern Recognition Signals

The 10-second spot

Maximum XOR of any pair in an array, O(N) or O(N log(max_value)) time requirement, N up to 2 * 10^5 ruling out O(N^2).

Formulating the Predicate & Invariants

Turning intuition into a boolean rule

Invariant: if two numbers' prefixes under the current mask differ only in the newly-exposed bit, their XOR of that prefix equals the greedy candidate, proving the bit is achievable.

Silent Failure Traps & Edge Cases

Where confident candidates still lose points

Checking all O(N^2) pairs directly: too slow for N up to 2*10^5; must process bit positions, not pairs.
Forgetting that mask must grow monotonically (MSB to LSB) so earlier, more significant bit decisions are never revisited or invalidated by later ones.
Comparing full untruncated numbers rather than their masked prefixes, which breaks the greedy proof.

The 60-Second Interview Pitch

Say this out loud before you type a single line

"I build the answer bit-by-bit from bit 31 down to bit 0. At each position I grow a mask to expose one more bit of every number's prefix, collect those prefixes into a set, and greedily assume the answer's bit here can be 1. I verify by checking whether some prefix p in the set has its XOR-partner (candidate ^ p) also in the set -- if so the bit is provably achievable and I lock it in. This avoids ever comparing all pairs directly, running in O(32*N) = O(N) time and O(N) space. The same idea can be implemented as a walked bit-trie instead of a hash set."

Big-O Invariant Derivation

Complexity & Mathematical Proof

TIME COMPLEXITY

O(N)

Look at the execution steps: For each of the 32 bit positions, rebuild the prefix set (O(N)) and scan it once (O(N)) to verify the greedy bet. Total work is 32 * O(N) = O(32N), which is O(N) since 32 is a fixed constant.

SPACE COMPLEXITY

O(N) Auxiliary

Look at memory allocations: Call stack uses O(1) Iterative. Stores one prefix set of up to N integers per bit position (reused, not accumulated) in O(N) auxiliary space.

Formal Recurrence Relation

T(N) = 32 · O(N) = O(N)

Derivation Progression

Per-Bit Prefix Set Construction

$prefixes = \{num \& mask : num \in nums\}$

Rebuilding the prefix set for one bit position costs O(N).

Per-Bit Greedy Verification Scan

$\exists\, p \in prefixes : (candidate \oplus p) \in prefixes$

Scanning the prefix set to verify the greedy bet costs O(N) per bit position.

Total Across 32 Bit Positions

$32 \cdot O(N) = O(N)$

32 is a fixed constant (not dependent on N), so total time remains linear in N.

Variable Definitions

$N$

Total number of elements in the array

$32$

Fixed bit width of a 32-bit integer (constant, not a function of N)

Memory Architecture & Bounds

🟣 Call Stack

O(1) Iterative

🔵 Auxiliary Heap

O(N) One prefix set of up to N integers per bit position

🟢 Output Space

O(1) Single integer result

Boundary Best / Worst Cases

Best Case

$O(N)$

Average Case

$O(N)$

Worst Case

$O(N)$

Recurrence Tree Topology

Synthesizing vector architecture diagram...

Staff+ Engineering Perspective

Senior SWE Deconstruction & Hardware Caveats

ARCHITECTURAL SIGNALS & INTERVIEW TRIGGERS

The problem asks for the "maximum XOR of two numbers in an array in O(n) runtime." Comparing all pairs takes $O(N^2)$ , which TLEs for $N = 2 \times 10^5$ . The key insight is that the most significant bit (MSB) dominates all lower bits combined: $2^k > \sum_{j=0}^{k-1} 2^j$ . Therefore, we can greedily determine the optimal XOR value bit-by-bit from MSB (bit 30) down to LSB (bit 0)!

CONSTRAINTS & BOUNDS

$N \le 2 \times 10^5$ , values fit in 31 non-negative bits ( $0 \le \text{nums}[i] \le 2^{31} - 1$ ). An $O(31 N) = O(N)$ algorithm is required.

FAANG PRODUCTION TRAPS & EDGE CASES

The primary trap is scanning LSB to MSB; greedy choice only works MSB to LSB because a higher bit outweighs all lower bits. Another trap is rebuilding prefixes naively without masking: mask |= (1 << i) must accumulate prefixes from bit 30 down to $i$ .

Theory Context•Bit Manipulation

MediumLC 421

Maximum XOR of Two Numbers in an Array (LeetCode 421)

Target Frequency:GoogleAmazonMicrosoft

Given an integer array nums, find the largest value obtainable by XOR-ing any two elements nums[i] and nums[j] (the same index may be reused, i.e. 0 <= i <= j < n).

Worked Examples

Example 1

Input:nums = [3,10,5,25,2,8]

Output:28

Explanation: The maximum result is 5 XOR 25 = 28.

Example 2

Input:nums = [14,70,53,83,49,91,36,80,92,51,66,70]

Output:127

Explanation: 91 XOR 36 = 127, and no other pair does better.

⚖️Formal Constraints & Bounds

1 <= nums.length <= 2 * 10⁵
0 <= nums[i] <= 2³¹ - 1

Deep-Dive & Conceptual Insights

Core Insight

Real-World Scenario & Production Applications

Finding the two most dissimilar hash fingerprints in a deduplication index, maximizing Hamming distance between error-correcting codewords, and IP-routing longest-prefix-divergence lookups.

Subproblems & Recurrence Decomposition3 Phases

🧩Subproblem 1: Greedy Bit-by-Bit MSB-to-LSB Construction

Build the answer one bit position at a time, from the most significant bit (31) down to the least significant bit (0), growing a mask that exposes longer and longer prefixes of every number.

Mathematical Recurrence / Code Invariant

max_xor, mask = 0, 0
for i in range(31, -1, -1):
    mask |= (1 << i)

Step-by-Step Execution Trace Table

Worked trace: nums = [3, 10, 5, 25, 2, 8]

Bit `i`	mask	Prefix set (masked nums)	candidate = max_xor \vert (1<<i)	Verified?	max_xor after
4	`10000` (16)	{0, 16}	16	Yes (0 ^ 16 = 16)	16
3	`11000` (24)	{0, 8, 24}	24	Yes (0 ^ 24 = 24)	24
2	`11100` (28)	{0, 4, 8, 24}	28	Yes (4 ^ 24 = 28)	28
1	`11110` (30)	{2, 4, 8, 10, 24}	30	No	28
0	`11111` (31)	{2, 3, 5, 8, 10, 25}	29	No	28

Final max_xor = 28, achieved by 5 XOR 25 = 00101 ^ 11001 = 11100 = 28, matching the expected output.

Code Shape

Archetype Code Shape

Python

1	max_xor, mask = 0, 0
2	for i in range(31, -1, -1):
3	mask \|= (1 << i)
4	prefixes = {num & mask for num in nums}
5	candidate = max_xor \| (1 << i)
6	for p in prefixes:
7	if (candidate ^ p) in prefixes:
8	max_xor = candidate
9	break
10	return max_xor

Conceptual Narrative

🧭 Conceptual Foundation & Pattern Intuition

🏔️ The Analogy: Building the Tallest Answer One Floor at a Time, Verified Before You Commit

Trick 1 — Growing prefixes (mask |= (1 << i)): The mask exposes just the top (32 - i) bits of every number — everything built "so far", floor by floor.
Trick 2 — Prefix set (prefixes = {num & mask for num in nums}): Recompute every number's current prefix under the new, slightly-longer mask.
Trick 3 — The greedy bet (candidate = max_xor | (1 << i)): Assume you CAN set this floor's bit to 1 in the final answer.
Trick 4 — Verify with the XOR-inverse trick ((candidate ^ p) in prefixes): If some prefix p is in the set, and candidate ^ p is ALSO in the set, then those two prefixes XOR together to exactly candidate — the bet is provably achievable, so max_xor permanently locks in that bit. If no such pair exists, the floor can't be built here, and max_xor keeps its bit at 0 for this position — never regressing, only growing.

🔑 The Key Idea in the Code

Quadratic $O(N^2)$ brute-force pair comparison: Comparing every pair of numbers takes $O(N^2)$ time, which TLEs on $N = 2 \cdot 10^5$ . A Binary Trie or prefix hash set greedy bit evaluation achieves $O(31 \cdot N) = O(N)$ time.
Prefix set bit search property: At each bit position from bit 30 down to 0, test if a candidate maximum prefix can be formed: if candidate ^ p exists in the prefix set, p1 ^ p2 == candidate is guaranteed.
Iterating LSB to MSB instead of MSB to LSB: Greedy XOR maximization must make decisions from most significant bit (bit 30) down to least significant bit (bit 0), because a higher bit outweighs all lower bits combined.
Maximum XOR of Two Numbers — rebuilding the WHOLE prefix set every bit, not incrementally: the mask only ever grows (bits are added, never removed), so prefixes = {num & mask for num in nums} must be recomputed fresh each iteration from the ORIGINAL numbers, not from the previous iteration's already-masked prefixes — masking an already-masked value with a larger mask is a no-op and silently breaks the invariant.
Maximum XOR of Two Numbers — checking candidate in prefixes instead of the XOR-inverse: the verification step is NOT "is candidate itself a prefix" — it is "does some prefix p have its partner candidate ^ p also present". Checking membership of candidate directly (rather than candidate ^ p) looks superficially similar but never actually confirms two DIFFERENT numbers combine to the candidate value.
Maximum XOR of Two Numbers — pairing a number with itself: the loop bounds 0 <= i <= j < n technically allow i == j, but x XOR x = 0 is never the maximum unless every element is identical; a trie/hash-set implementation naturally handles this since a number's own prefix is always present in the set, but a hand-rolled O(N^2) baseline must remember not to special-case away legitimate i == j in a way that also breaks i != j pairs.

Senior SWE Reasoning Architecture

4-Phase Thought Process Model

Pattern Recognition Signals

The 10-second spot

Maximum XOR of any pair in an array, O(N) or O(N log(max_value)) time requirement, N up to 2 * 10^5 ruling out O(N^2).

Formulating the Predicate & Invariants

Turning intuition into a boolean rule

Invariant: if two numbers' prefixes under the current mask differ only in the newly-exposed bit, their XOR of that prefix equals the greedy candidate, proving the bit is achievable.

Silent Failure Traps & Edge Cases

Where confident candidates still lose points

Checking all O(N^2) pairs directly: too slow for N up to 2*10^5; must process bit positions, not pairs.
Forgetting that mask must grow monotonically (MSB to LSB) so earlier, more significant bit decisions are never revisited or invalidated by later ones.
Comparing full untruncated numbers rather than their masked prefixes, which breaks the greedy proof.

The 60-Second Interview Pitch

Say this out loud before you type a single line

"I build the answer bit-by-bit from bit 31 down to bit 0. At each position I grow a mask to expose one more bit of every number's prefix, collect those prefixes into a set, and greedily assume the answer's bit here can be 1. I verify by checking whether some prefix p in the set has its XOR-partner (candidate ^ p) also in the set -- if so the bit is provably achievable and I lock it in. This avoids ever comparing all pairs directly, running in O(32*N) = O(N) time and O(N) space. The same idea can be implemented as a walked bit-trie instead of a hash set."

Big-O Invariant Derivation

Complexity & Mathematical Proof

TIME COMPLEXITY

O(N)

SPACE COMPLEXITY

O(N) Auxiliary

Look at memory allocations: Call stack uses O(1) Iterative. Stores one prefix set of up to N integers per bit position (reused, not accumulated) in O(N) auxiliary space.

Formal Recurrence Relation

T(N) = 32 · O(N) = O(N)

Derivation Progression

Per-Bit Prefix Set Construction

$prefixes = \{num \& mask : num \in nums\}$

Rebuilding the prefix set for one bit position costs O(N).

Per-Bit Greedy Verification Scan

$\exists\, p \in prefixes : (candidate \oplus p) \in prefixes$

Scanning the prefix set to verify the greedy bet costs O(N) per bit position.

Total Across 32 Bit Positions

$32 \cdot O(N) = O(N)$

32 is a fixed constant (not dependent on N), so total time remains linear in N.

Variable Definitions

$N$

Total number of elements in the array

$32$

Fixed bit width of a 32-bit integer (constant, not a function of N)

Memory Architecture & Bounds

🟣 Call Stack

O(1) Iterative

🔵 Auxiliary Heap

O(N) One prefix set of up to N integers per bit position

🟢 Output Space

O(1) Single integer result

Boundary Best / Worst Cases

Best Case

$O(N)$

Average Case

$O(N)$

Worst Case

$O(N)$

Recurrence Tree Topology

Synthesizing vector architecture diagram...

Staff+ Engineering Perspective

Senior SWE Deconstruction & Hardware Caveats

ARCHITECTURAL SIGNALS & INTERVIEW TRIGGERS

CONSTRAINTS & BOUNDS

$N \le 2 \times 10^5$ , values fit in 31 non-negative bits ( $0 \le \text{nums}[i] \le 2^{31} - 1$ ). An $O(31 N) = O(N)$ algorithm is required.

FAANG PRODUCTION TRAPS & EDGE CASES

Bit i

mask

Prefix set (masked nums)

candidate = max_xor \vert (1<<i)

Verified?

max_xor after

10000 (16)

{0, 16}

Yes (0 ^ 16 = 16)

11000 (24)

{0, 8, 24}

Yes (0 ^ 24 = 24)

11100 (28)

{0, 4, 8, 24}

Yes (4 ^ 24 = 28)

11110 (30)

{2, 4, 8, 10, 24}

11111 (31)

{2, 3, 5, 8, 10, 25}

🧭 Conceptual Foundation & Pattern Intuition

🏔️ The Analogy: Building the Tallest Answer One Floor at a Time, Verified Before You Commit

Trick 1 — Growing prefixes (mask |= (1 << i)): The mask exposes just the top (32 - i) bits of every number — everything built "so far", floor by floor.
Trick 2 — Prefix set (prefixes = {num & mask for num in nums}): Recompute every number's current prefix under the new, slightly-longer mask.
Trick 3 — The greedy bet (candidate = max_xor | (1 << i)): Assume you CAN set this floor's bit to 1 in the final answer.
Trick 4 — Verify with the XOR-inverse trick ((candidate ^ p) in prefixes): If some prefix p is in the set, and candidate ^ p is ALSO in the set, then those two prefixes XOR together to exactly candidate — the bet is provably achievable, so max_xor permanently locks in that bit. If no such pair exists, the floor can't be built here, and max_xor keeps its bit at 0 for this position — never regressing, only growing.

🔑 The Key Idea in the Code

Bit i

mask

Prefix set (masked nums)

candidate = max_xor \vert (1<<i)

Verified?

max_xor after

10000 (16)

{0, 16}

Yes (0 ^ 16 = 16)

11000 (24)

{0, 8, 24}

Yes (0 ^ 24 = 24)

11100 (28)

{0, 4, 8, 24}

Yes (4 ^ 24 = 28)

11110 (30)

{2, 4, 8, 10, 24}

11111 (31)

{2, 3, 5, 8, 10, 25}