Systematic Debugging and Root Cause Analysis Questions

This binary search is functionally correct for typical inputs (it correctly uses an exclusive hi, and the loop invariant "the answer, if present, lies in [lo, hi)" is maintained correctly through both branches), but it carries the single most famous subtle bug in binary search implementations: int mid = (lo + hi) / 2 can overflow when lo + hi exceeds the maximum representable integer.

Verified overflow demonstration

Simulating 32-bit signed integer arithmetic (as a real Java/C int would compute it) with lo = 2147483643, hi = 2147483647 (near Integer.MAX_VALUE): (lo + hi) wraps to a negative number, and dividing gives mid = -3, a negative array index, which would throw an out-of-bounds exception in real code. The correct formula, lo + (hi - lo) / 2, never sums two large values and gives the correct mid = 2147483645.

The loop invariant

At the top of every iteration, the target (if present) is guaranteed to lie within [lo, hi); each branch either returns immediately (found) or shrinks that half-open range on one side, guaranteeing termination since hi - lo strictly decreases.

Corrected implementation

int binarySearch(int[] a, int target) {
    int lo = 0, hi = a.length;
    while (lo < hi) {
        int mid = lo + (hi - lo) / 2;   // overflow-safe
        if (a[mid] == target) return mid;
        else if (a[mid] < target) lo = mid + 1;
        else hi = mid;
    }
    return -1;
}

Complexity

O(log n) time, O(1) space, unchanged by the fix; the fix is purely correctness-preserving, not a performance change.

Edge cases

Empty array (returns -1 immediately, loop never enters), single-element array (both target-present and target-absent), target smaller than every element and larger than every element (both should correctly return -1), duplicate values (returns a valid index of a match, not necessarily the first), and an array large enough (near 2^31 elements) to actually trigger the overflow in practice, which is rare in application code but standard in systems code operating over huge buffers.

Direct answer

The timing is the tell: a freeze starting exactly at the tap and lasting about as long as a network round-trip means something async is actually blocking the main thread, even without Android's explicit main-thread-network exception. Confirm by aligning a system trace's frame gap against the network call's logged timestamps.

Structured elaboration

• Older Android throws NetworkOnMainThreadException for direct blocking calls, but calling .get()/Tasks.await() on an otherwise-async API blocks silently instead.
• Capture Perfetto/systrace during the tap; look for a gap in Choreographer#doFrame (the callback Android's rendering system fires once per rendered frame; a gap here means no frame was drawn during that stretch, i.e. the UI visibly froze) starting at the tap.
• Cross-reference that gap's timestamps against the network call's sent and received timestamps; near-exact alignment confirms the network call as the blocker.
• Add a StrictMode network-detection policy in debug builds to catch a reintroduction.

Worked example

A 2.3-second main-thread gap starting at onClick, matching a request sent at that instant with a response 2.3 seconds later, is checkable evidence the network call itself is blocking.

Trade-offs and pitfalls

Moving the call off-thread fixes the freeze, but the UI update after the response still needs to happen back on the main thread.

What the interviewer probes next

Why NetworkOnMainThreadException doesn't catch every case, and how you'd structure the code to make this hard to reintroduce.

count++ is not one atomic operation: it is read-count, add-one, write-count, and with 100 threads calling increment() concurrently, two threads can both read the same value before either writes back, so one increment is silently lost.

Verified demonstration

Running a deterministic interleaving (thread A reads 0, sleeps, then writes 1; thread B reads 0 before A writes, then writes 1) confirms the lost update directly: two increments were issued, but the final count is 1, not 2, because B's read happened before A's write landed, so A's write overwrote B's already-lost update.

Two correct fixes

1. Synchronize the read-modify-write:

public synchronized void increment() { count++; }
public synchronized int get() { return count; }

Simple and correct; adds lock contention under very high thread counts.
2. Use AtomicInteger:

private final AtomicInteger count = new AtomicInteger(0);
public void increment() { count.incrementAndGet(); }
public int get() { return count.get(); }

Uses a lock-free CPU-level compare-and-swap; typically faster than a full lock under contention because it never blocks a thread, it just retries the CAS.

Trade-offs

synchronized is simpler to reason about for compound operations (e.g., updating two related fields together atomically); AtomicInteger is faster for a single counter specifically but doesn't generalize to multi-field invariants without a more complex lock-free design. For a plain counter under high contention, AtomicInteger (or LongAdder for extremely high contention) is the standard choice.

Direct answer

The closure captures self strongly, and self.onUpdate holds that closure, a reference cycle. (Swift manages memory via ARC, Automatic Reference Counting: it frees an object once nothing holds a strong reference to it, using a running count of those references, so a reference cycle where two objects each strongly hold the other keeps that count above zero forever.) Nothing external breaks it, so ARC's retain count never reaches zero and deinit never fires.

Structured elaboration

Fix by capturing weakly: [weak self] in guard let self = self else { return }. The closure no longer contributes a strong reference, so once the owning screen's reference goes away, the object can actually reach zero and deinitialize.

Worked example

Executed to confirm both the leak and the fix, using deinit as ground truth:

final class ViewModel {
    let id: String
    var onUpdate: (() -> Void)?
    init(id: String) { self.id = id }
    deinit { print("\(id) deinitialized") }
    func subscribeLeaky() { onUpdate = { print(self.id) } }
    func subscribeFixed() { onUpdate = { [weak self] in print(self?.id ?? "-") } }
}
func scopeLeaky() { let vm = ViewModel(id: "leaky"); vm.subscribeLeaky(); vm.onUpdate?() }
func scopeFixed() { let vm = ViewModel(id: "fixed"); vm.subscribeFixed(); vm.onUpdate?() }
scopeLeaky(); scopeFixed()

Output: leaky, fixed, fixed deinitialized. "leaky deinitialized" never prints, proving the leak; "fixed deinitialized" fires right after scopeFixed() returns, proving the fix.

Complexity

Not applicable algorithmically; this is an object-lifetime bug, not a performance one.

Edge cases

If the closure must finish work after dismissal (flushing analytics, say), [weak self] can silently no-op too early; [unowned self] or capturing only the needed value fits better when the closure provably can't outlive self.

Trade-offs and pitfalls

[unowned self] skips the guard let but crashes instead of no-op-ing if self is already deallocated.

What the interviewer probes next

How you'd catch this automatically with the Memory Graph Debugger or Instruments' Leaks template, and when unowned beats weak.

Direct answer

Without the hardware, use the crash tool's device and OS breakdown to find what affected models share, and check whether the crashing path touches anything vendor-specific. Then rent the exact configuration through a device farm for a real repro.

Structured elaboration

• Segment by model, OS version, and manufacturer; concentration on a few models points at an OEM/chipset quirk, an even spread points at a genuine OS-version bug.
• Check for OEM-specific behavior: camera HAL variants (HAL, Hardware Abstraction Layer: the vendor's own driver code sitting between the OS and the camera hardware, exactly where OEM-specific bugs tend to hide), stricter background throttling, manufacturer UI overlays intercepting touch.
• Pull session breadcrumbs from the crash tool to reconstruct the exact action sequence, then reproduce it on a rented device via Firebase Test Lab or AWS Device Farm.
• If still stuck, ship targeted logging behind a flag to a small slice of the affected population for the next release.

Worked example

If 40% of all crashes are one exception, and 90% of those concentrate on 3 models on the same OS build, that's a strong signal to check for OEM-gated code, since a true device-agnostic bug would spread proportionally across the whole install base instead.

Trade-offs and pitfalls

Device farm sessions cost time; reserve them for concentrated, high-impact crashes. Flag-gated logging is safer than a blanket rollout but delays root-causing by a release cycle, usually worth it at 40% share.

What the interviewer probes next

When a crash is worth a device farm session versus accepted as an OEM-side limitation.