Two Sigma OA Interview Experience (2026) - Peak Concurrent Traffic & Pipeline Throughput, Offer

The only subtlety is the tie-break when a disconnect and a connect happen at the same instant. Because endpoints are inclusive, a session ending at t=6 and a session starting at t=6 should both be "active" at t=6, so connect events must come before disconnect events in the same timestamp. If you flip this, you get a transient dip and your peak detection is off by one.

Also, the problem asks for the earliest peak time, not just the peak count. Once concurrency climbs to a new max, record the current timestamp and stop updating until a strictly larger value appears.

Approach: emit two events per session tagged connect/disconnect, sort by (time, kind) with connects sorting first, then walk events tracking a running count. Whenever the running count strictly exceeds the previous max, snapshot the timestamp. Return that snapshot at the end.

O(n log n) from the sort. I verified on start=[1,6,2,9], end=[8,7,6,10] → 6 by walking the events on scratch paper. Got full credit.

Problem 2: Maximum Pipeline Throughput

Problem: A pipeline has n stages in series. Stage i has base throughput throughput[i] and cost-per-upgrade scaling cost[i] . If stage i is upgraded x times, its throughput becomes throughput[i] (1 + x) . Given a total budget B , maximize the minimum throughput across all stages (the bottleneck defines the pipeline).

Max-the-min with a budget constraint. This is binary search on the answer. Pick a candidate throughput T . For each stage, compute the minimum number of upgrades needed to reach T: x i = max(0, ceil(T / throughput[i]) - 1) . Sum x i scaling cost[i] . If total <= B, T is feasible. Binary search the largest feasible T.

Verified on throughput=[4,2,7], scaling cost=[3,5,6], budget=32 → 10. Full credit.

The trap is the upper bound for binary search. If you set hi = max(throughput) budget you'll be off on edge cases where one stage can absorb the entire budget. Better to cap it using min(throughput) + (budget // min(cost) + 1) max(throughput) , or just use a safely huge number like 10 12 since the feasibility check short-circuits anyway. Overall runtime is O(n log(range)).

Tech Screen (45 min)

A week after the OA I got a phone-screen invite. One live-coding round with an engineer. The question was: implement a HashMap from scratch supporting put(key, value) and get(key) . Do not use any language-provided hash table.

I went with the textbook approach: a bucket array of fixed initial size, each bucket a linked list of (key, value) nodes, Java-style hashCode on the key mod bucket count for the index. For collisions, walk the list and update in place if the key already exists, otherwise append. For get , walk the bucket and return the value or a sentinel if absent.

The follow-up was about resizing. At what load factor do we double the bucket count, and what does that cost? I answered 0.75 (Java default), and the amortized put is still O(1) because rehashing happens every time the table fills, which is geometrically spaced. The interviewer pushed on: "What if you can't afford an O(n) stall during resize?" That led to incremental rehashing: keep both old and new tables during the migration and move one bucket per subsequent put .

Got the offer two weeks after this round.

Practice it: [[problem/639?company=32|Design HashMap]]

Result

Offer for a SWE new grad role in NYC. Comp was within $5k of a Jane Street offer I had in the same cycle. Two Sigma was more engineering-flavored and less trader-facing, which suited me.

Tips

1. For Two Sigma's OA, spend the first 5 minutes modeling before you code. Both problems have a standard algorithm underneath (sweep line, binary-search-the-answer) but the modeling step from prose to algorithm is where most candidates lose time. Sketch it on paper first.
2. Binary-search-on-the-answer is the highest-value pattern for Two Sigma. It shows up on the OA, it shows up in onsites. If you can't write a feasibility function in under 5 minutes, drill it. The template is stable: function `feasible(T)`, monotone predicate, walk lo/hi until they meet.
3. For the HashMap tech screen, know the internal structure of `java.util.HashMap`. Bucket array, linked list buckets (treeified to red-black trees past threshold 8 in Java 8+), 0.75 default load factor, power-of-two sizing. The follow-ups always probe these numbers.
4. Handle event-tie ordering explicitly in sweep-line problems. If endpoints are inclusive, connects come before disconnects at the same timestamp. Write that comment in your code even when it's not strictly needed, it signals you know the trap.
5. If you have two good approaches and time pressure, go with the one you can test faster. On Problem 2, there's also a priority-queue greedy that expands cheapest-marginal-upgrade iteratively. It works but is harder to verify in 30 minutes than binary search. I'd choose binary search every time.
6. For the tech screen, talk through tradeoffs even when not asked. When I implemented open addressing's cousin (chained lists), I mentioned that open addressing has better cache locality but worse worst-case. The interviewer picked it up and we spent 10 minutes on that, which replaced a hypothetical follow-up I may have flubbed.

Two Sigma is a modeling shop. If you can translate a messy scenario into a clean algorithmic problem under time pressure, you will do well. That is the whole test.