Reason About Binary Search with One-Call-Delayed Feedback
OpenAISoftware Engineer · Technical ScreenLast updated
Implement and analyze binary search under a 1-step delayed-feedback protocol where each query response evaluates the previous guess.
Problem Statement
In standard binary search, each query immediately reveals whether the guess was too low, too high, or correct. In distributed or pipelined systems, feedback is often delayed.
You are searching for a hidden integer target in the inclusive range [1, n]. You interact with an oracle through an interface oracle.guess(x: int) -> int | None with the following delayed-feedback specification:
- First Call:
oracle.guess(x)registersxas guess #1 and returnsNone(no previous guess exists). - Call
k(k >= 2):oracle.guess(x)registersxas guess #k and returns the comparison result for guess#(k - 1):-1if guess#(k - 1) target
- Flush / Termination: If you receive
0, the previous guess was the target, and you can return it immediately. If your search narrows down to a single candidate or you need to inspect the result of your last issued guess, you may make an arbitrary valid dummy guess (e.g., within[1, n]) to flush the pending result.
Implement the function find_target(n: int, oracle: DelayedOracle) -> int to find target using O(log n) total calls to oracle.guess.
Function Signature
class DelayedOracle:
def guess(self, x: int) -> int | None:
...
def find_target(n: int, oracle: DelayedOracle) -> int:
pass
Constraints
1 <= target <= n <= 10^9- The total number of calls to
oracle.guessmust be strictly bounded byC * log2(n) + O(1)for a small constantC(e.g., ` None # Guess 4 registered
- oracle.guess(2) -> 1 # Feedback for 4: 4 > 3 (+1). Target in [1, 3].
- oracle.guess(1) -> -1 # Feedback for 2: 2 -1 # Feedback for 1: 1 0 # Feedback for 3: 3 == 3 (0). Found!
Output: 3
### Example 2
```text
Input: n = 1, target = 1
Execution trace:
1. oracle.guess(1) -> None # Guess 1 registered
2. oracle.guess(1) -> 0 # Feedback for 1: 1 == 1 (0). Found!
Output: 1
Notes & Edge Cases
- When
n = 1, a startup guess followed by a flush guess is required to read the feedback. - Handle state correctly when an earlier guess turns out to be the target while another guess was already in flight.
- Your search interval invariant must account for the fact that at any step
k, the feedback received corresponds to guessk - 1, not the most recently submitted guess.
Hints
Hint 1
Because feedback is delayed by one step, you cannot condition guess `k` on the outcome of guess `k - 1`; you only know the outcome up to guess `k - 2`.
Hint 2
A straightforward strategy is paired querying or maintaining a pipeline: issue a guess, and if no prior result is known yet to branch on, make a placeholder or complementary guess before reading the outcome.
Hint 3
Ensure you have a clean flush step: whenever a guess could be the target or is the last remaining candidate, one additional call is needed to observe its feedback if you have not already seen `0`.
Follow-up questions
- What is the theoretically optimal query complexity multiplier `C` such that queries <= `C * log2(n)` when feedback is delayed by `d` steps?
- How does the algorithm change if the oracle does not return `0` for equality, but only `=`?
- If each query incurs network round-trip latency, how would you batch or parallelize guesses across multiple in-flight slots?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.