Two Sigma Interview Questions (2026): Real, With Answers

Candidate reports converge on two questions in a 75 to 90 minute window. The first is usually LeetCode-easy-to-medium and meant to be a warm-up, while the second is harder, sometimes described as LeetCode medium-to-hard, and tends to hide a graph or pathfinding problem behind a wordy, business-flavored prompt. A few reports mention the time pressure being the real difficulty, not the algorithms themselves: candidates who could solve both problems on paper still ran out of time getting every edge case through the test harness.

The practical takeaway is to read both problems fully before writing code for either one, so you can budget the harder problem more time up front instead of discovering it late.

Longest string chain asks you to find the longest sequence of words where each word is formed by inserting exactly one letter into the previous word. The key insight is that this is a longest-path problem on an implicit graph, not a string-comparison problem, so it's best solved with dynamic programming over a sorted-by-length word list rather than brute-force pairwise comparison.

def longest_str_chain(words):
  words.sort(key=len)
  best = {}
  result = 1
  for w in words:
    best[w] = 1
    for i in range(len(w)):
      predecessor = w[:i] + w[i+1:]
      if predecessor in best:
        best[w] = max(best[w], best[predecessor] + 1)
    result = max(result, best[w])
  return result

Sorting by length first guarantees every predecessor has already been processed by the time you reach a given word, which is what makes the dynamic programming pass work in a single left-to-right sweep.

The base problem, one transaction, is a single pass tracking the minimum price seen so far and the best profit achievable at each point. The variations that actually matter, multiple transactions, a cooldown period after selling, a transaction fee, or a cap on the number of transactions, each shift the problem from greedy to dynamic programming with explicit state for "holding a share" versus "not holding one."

def max_profit_with_fee(prices, fee):
  cash, hold = 0, -prices[0]
  for p in prices[1:]:
    cash = max(cash, hold + p - fee)
    hold = max(hold, cash - p)
  return cash

What Two Sigma is really checking here is whether you notice the constraint change and adjust your state definition, rather than forcing the original greedy solution to fit a problem it no longer matches.

A hash map stores key-value pairs and uses a hash function to convert each key into an array index, giving average O(1) lookup, insert, and delete. Collisions, two different keys hashing to the same index, get handled either by chaining, each bucket holds a small linked list or array of entries, or by open addressing, probing to the next available slot.

The follow-up worth anticipating is what happens as load factor grows: a good hash map resizes and rehashes once the ratio of entries to buckets crosses a threshold, which is why amortized O(1) is the honest claim, not worst-case O(1). A poorly distributed hash function degrades every operation toward O(n) regardless of resizing.

A process is an independent unit of execution with its own memory space, file descriptors, and address space, isolated from other processes by the operating system. A thread is a unit of execution within a process, threads in the same process share memory and file descriptors, which makes communication between them cheap but also makes them vulnerable to the same class of bugs, race conditions, that don't exist between separate processes.

Creating a new process is expensive, the OS has to allocate a fresh address space, while spawning a thread is comparatively cheap since it reuses the existing process's memory. That cost difference is why high-throughput systems favor threads or async concurrency within a process over spawning new processes per unit of work.

Bandwidth is how much data can move through a connection per unit of time, throughput. Latency is how long a single piece of data takes to travel from sender to receiver, the delay before anything arrives at all. A satellite link can have huge bandwidth and still feel slow because of high latency, while a low-bandwidth connection with near-zero latency can feel snappier for small, frequent requests.

For a trading or market-data system specifically, latency usually dominates the design conversation, since the value of a piece of information decays with every microsecond it takes to arrive, whereas bandwidth constraints mostly show up when you're moving large historical datasets rather than live signals.

Arrays and hash tables underpin most of the real problems the firm actually solves, order books, market data caches, position tracking, so testing fluency there maps more directly to day-to-day work than, say, a tree-balancing algorithm nobody hand-rolls in production. It is not really about the data structure being exotic. It is about whether you reach for the right one instantly instead of working it out from scratch under pressure.

The practical prep implication is to over-index on being fast and correct with arrays, hash maps, and two-pointer or sliding-window techniques, since those show up constantly as building blocks inside harder problems, rather than spending equal time on structures that show up rarely, like tries or segment trees.

Default to composition unless there's a genuine is-a relationship that holds in every case, not just the one you're thinking of right now. Inheritance looks elegant on a whiteboard and turns brittle the moment a new subtype doesn't quite fit the parent's assumptions, forcing you to override a method just to throw an exception or leave it empty.

Under interview time pressure specifically, composition is also just faster to extend live: adding a new behavior means injecting a new object rather than restructuring a class hierarchy you've already half-drawn on the whiteboard. Saying this out loud, and then actually building the class that way, demonstrates the preference rather than just claiming it.

Where did this data come from, and does the collection process introduce any systematic bias, survivorship bias in a dataset of only currently-listed companies is the classic trap. What's missing, and is it missing randomly or is the absence itself informative, data that's missing because a sensor failed behaves very differently from data that's missing because a value was genuinely zero.

What's the time range and frequency, and does the relationship you're about to model actually hold consistently across that whole period or only in part of it. A candidate who asks these before writing any code signals more research maturity than one who jumps straight into a correlation matrix.

Batch processing runs on a fixed schedule or dataset boundary, end-of-day, hourly, over a complete chunk of data, trading latency for simplicity and the ability to reprocess a whole window if logic changes. Stream processing handles events continuously as they arrive, giving low latency but requiring you to design around partial, out-of-order, and possibly duplicate data from the start.

The honest decision rule: pick batch by default unless a specific downstream consumer genuinely needs results within seconds or minutes of an event happening, since stream processing brings real operational complexity, exactly-once semantics, watermarking for late data, that isn't worth paying for if nothing actually consumes the lower latency.

This is a classic group-by-with-ranking problem, best solved with a window function rather than a correlated subquery, which gets slow at scale.

SELECT trade_date, symbol, volume
FROM (
 SELECT
  trade_date,
  symbol,
  volume,
  ROW_NUMBER() OVER (PARTITION BY trade_date ORDER BY volume DESC) AS rn
 FROM daily_trades
) ranked
WHERE rn = 1;

The follow-up worth anticipating is what to do with ties, RANK() instead of ROW_NUMBER() returns every tied top-volume symbol per day rather than arbitrarily picking one, and which behavior is correct depends entirely on what the question actually needs.

This opening question is a warm-up, but it sets the frame for everything after it, so treat it as an opportunity to preview the two or three specific experiences you want to dig into later rather than reciting your resume chronologically. A tight version names your current role, the specific technical or research problem you've spent the most time on recently, and a one-sentence reason this particular role connects to that work.

Interviewers use your answer here to decide which threads to pull on later, so if there's a project you're proud of and want to talk about, mention it here even briefly, since a good interviewer will circle back to whatever you flag as interesting.

Pick an example where the initiative had a real, visible outcome. The weak version of this answer stops at "I noticed a problem." The strong version explains what you actually did about it and what changed as a result. A good structure: the gap you noticed that nobody had assigned anyone to fix, why you decided it was worth your time specifically, what you built or changed, and the measurable or observed result afterward.

Avoid stories where the initiative was low-risk and low-cost, offering to organize a team lunch, in favor of one where you took on some real risk or ambiguity, starting work on something without confirming it was wanted first, and it paid off.

A generic answer about "current technology" or "smart people" is instantly forgettable, since it applies equally to a dozen other firms. A specific answer references something concrete: a particular research area, engineering challenge, or piece of public writing from the firm that connects to work you've actually done or want to do next.

The "why this role" half matters just as much as "why this company." Be able to explain what specifically about the role's day-to-day work, not just its prestige, matches something you're good at or want more of, since interviewers can tell the difference between someone who researched the actual job and someone who researched the company's press coverage.

This question exists because Two Sigma's stated culture assumes everyone is wrong about most things most of the time, so a candidate who can't produce a genuine example of being wrong, or who only offers a trivial one, signals either low self-awareness or an unwillingness to be honest in the interview itself.

Pick an example with real stakes, a technical assumption that shaped a design decision, a forecast that missed, not a low-stakes example like a wrong restaurant recommendation. Explain specifically what evidence changed your mind and how quickly you updated once you saw it, since the speed of updating matters as much as the eventual correction.

Friend circles gives you a matrix or adjacency list describing pairwise connections and asks how many distinct connected groups exist. The tell is that relationships are symmetric and transitive: if A is friends with B and B is friends with C, A and C end up in the same circle even without a direct connection. That transitivity is exactly what union-find (disjoint set union) is built to track efficiently.

def find(parent, x):
  while parent[x] != x:
    parent[x] = parent[parent[x]]
    x = parent[x]
  return x

def num_circles(matrix):
  n = len(matrix)
  parent = list(range(n))
  for i in range(n):
    for j in range(i + 1, n):
      if matrix[i][j] == 1:
        parent[find(parent, i)] = find(parent, j)
  return len(set(find(parent, i) for i in range(n)))

Candidates repeatedly describe questions dressed up as scheduling systems, order matching, or resource allocation, where the underlying ask is a heap, interval-merging, or greedy-with-sorting problem. A typical version gives you a stream of timestamped events, each with a start and duration, and asks you to compute something like maximum concurrent load or total idle time.

The pattern that works is to strip the business framing immediately: identify whether events need to be processed in time order (sort plus a min-heap of active intervals) or whether you actually just need interval overlap counting (a sweep line over start and end events). Most of these collapse to one of those two templates once you see past the wording.

Candidates who described a pathfinding OA question said it was conceptually simple, breadth-first search on a grid, but lengthy to implement cleanly with obstacles, multiple start points, or a shortest-path-with-cost twist. The trap under time pressure is over-engineering: reaching for Dijkstra or A* when uniform-cost BFS solves the stated problem in far less code.

from collections import deque

def shortest_path(grid, start, end):
  rows, cols = len(grid), len(grid[0])
  queue = deque([(start, 0)])
  visited = {start}
  while queue:
    (r, c), dist = queue.popleft()
    if (r, c) == end:
      return dist
    for dr, dc in [(-1,0),(1,0),(0,-1),(0,1)]:
      nr, nc = r + dr, c + dc
      if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] != 1 and (nr, nc) not in visited:
        visited.add((nr, nc))
        queue.append(((nr, nc), dist + 1))
  return -1

Default to BFS for unweighted grids. Only escalate to a weighted-graph algorithm if the prompt actually specifies variable movement cost.

An LRU cache needs O(1) lookup and O(1) reordering on every access, which a hash map alone can't give you since it has no notion of recency, and a linked list alone can't give you since it has no O(1) lookup by key. Combining a hash map, key to node, with a doubly linked list, ordered by recency, solves both at once.

class Node:
  def __init__(self, key, val):
    self.key, self.val = key, val
    self.prev = self.next = None

class LRUCache:
  def __init__(self, capacity):
    self.cap = capacity
    self.map = {}
    self.head = Node(0, 0)
    self.tail = Node(0, 0)
    self.head.next, self.tail.prev = self.tail, self.head

  def _remove(self, node):
    node.prev.next, node.next.prev = node.next, node.prev

  def _add_front(self, node):
    node.next, node.prev = self.head.next, self.head
    self.head.next.prev = node
    self.head.next = node

  def get(self, key):
    if key not in self.map:
      return -1
    node = self.map[key]
    self._remove(node)
    self._add_front(node)
    return node.val

  def put(self, key, val):
    if key in self.map:
      self._remove(self.map[key])
    node = Node(key, val)
    self.map[key] = node
    self._add_front(node)
    if len(self.map) > self.cap:
      lru = self.tail.prev
      self._remove(lru)
      del self.map[lru.key]

This is reservoir sampling. Fill a reservoir of size k with the first k items, then for each subsequent item at index i (0-indexed, i greater than or equal to k), generate a random number between 0 and i inclusive, and if that number is less than k, replace the reservoir slot at that random index with the current item.

import random

def reservoir_sample(stream, k):
  reservoir = []
  for i, item in enumerate(stream):
    if i < k:
      reservoir.append(item)
    else:
      j = random.randint(0, i)
      if j < k:
        reservoir[j] = item
  return reservoir

The proof that every item ends up with equal probability k/n of being in the final reservoir is worth being able to sketch, since interviewers often ask you to justify correctness rather than just produce the code.

Pre-order traversal with an explicit marker for null children makes this reconstructible unambiguously. Serialize by writing each node's value followed by recursing left then right, using a sentinel like "#" for missing children. Deserialize by consuming tokens in the same pre-order sequence, since the position of each null marker tells you exactly where a subtree ends.

def serialize(root):
  if not root:
    return "#"
  return f"{root.val},{serialize(root.left)},{serialize(root.right)}"

def deserialize(data):
  values = iter(data.split(","))
  def build():
    val = next(values)
    if val == "#":
      return None
    node = TreeNode(int(val))
    node.left = build()
    node.right = build()
    return node
  return build()

In-order traversal alone can't do this reconstruction since it doesn't preserve enough structural information without a second traversal paired alongside it.

Pandas questions in a quant OA are testing whether you can manipulate tabular data fluently, not whether you know the entire pandas API by heart. Typical asks involve grouping, aggregating, and reshaping a dataset, computing a rolling statistic, joining two dataframes on a key, or handling missing values in a way that doesn't silently distort the result.

import pandas as pd

def rolling_zscore(df, column, window):
  rolling_mean = df[column].rolling(window).mean()
  rolling_std = df[column].rolling(window).std()
  return (df[column] - rolling_mean) / rolling_std

The distinguishing factor between candidates isn't syntax recall, it's whether they think about edge cases unprompted: what happens at the start of the window before enough data exists, what a zero standard deviation does to the calculation.

A Gaussian mixture models data as coming from several normal distributions combined, each with its own mean, variance, and mixing weight, which is the right tool whenever the data visibly has more than one mode or cluster that a single bell curve can't capture, returns that behave differently in calm versus volatile regimes, for example.

Fitting one typically uses expectation-maximization: guess initial parameters, compute the probability each point belongs to each component (the E-step), then update each component's mean, variance, and weight based on those soft assignments (the M-step), repeating until the parameters stop moving. The moments, mean and variance of the overall mixture, aren't just the average of the components' individual moments, you have to account for the extra variance introduced by the components themselves being spread apart.

Overfitting means a model has learned the noise in your training data as if it were signal, so it performs great on data it's already seen and poorly on anything new. The plain-language version: it memorized the answers to last year's test instead of learning the underlying material, so this year's slightly different questions trip it up.

Detecting it is a matter of comparing training error to held-out validation or test error, a large gap where training error is low but validation error is high is the classic signature. Cross-validation, regularization like ridge or lasso penalties on coefficient size, and simply having more data all address it from different angles, and a strong answer names which of these fits the specific failure mode being discussed rather than listing all three generically.

Let p be the probability the first flipper wins. On their turn, they win outright with probability 1/2. If they don't (prob 1/2), the second flipper now faces the exact same situation the first flipper originally faced, so the second flipper's win probability from that point is p, meaning the first flipper's remaining win probability is 1 - p.

# p = 1/2 + 1/2 * (1 - p)
# p = 1/2 + 1/2 - p/2
# 1.5p = 1
# p = 2/3

The first flipper wins with probability 2/3. The clean way to present this is the recursive self-similarity argument above rather than summing an infinite geometric series, since it's faster to derive under pressure and less error-prone.

A solid answer separates three concerns clearly: extraction, pulling from source systems reliably even when a source is briefly unavailable, transformation, the actual business logic and data quality rules, and load, writing to the destination in a way that's safe to retry. Naming a specific orchestration tool, Airflow, Dagster, or similar, and explaining how it handles retries, backfills, and dependency ordering between tasks shows you've operated one in production, not just read about it.

The part worth volunteering unprompted is how you catch bad data before it lands: schema validation at ingestion, row-count and null-rate checks between pipeline stages, and alerting on anomalies rather than discovering a broken pipeline three days later when a downstream report looks wrong.

MapReduce writes intermediate results to disk between every map and reduce stage, which makes it durable and simple to reason about but slow for anything iterative. Spark keeps intermediate data in memory across stages by default, which makes it dramatically faster for iterative workloads, machine learning training loops, interactive queries touching the same dataset repeatedly, at the cost of needing enough cluster memory to hold that working set.

In practice, plain MapReduce is rare to reach for on a new project in 2026, Spark's expressiveness and speed have made it the default for almost everything MapReduce used to handle. The honest case for still knowing MapReduce is that some legacy pipelines at older financial institutions still run on it, and understanding its disk-based, fault-tolerant model helps explain why Spark's design choices exist in the first place.

Layer checks at the boundary where data enters your system, not just at the end. Schema checks catch structural breaks immediately, a column renamed or dropped upstream. Statistical checks, row counts within an expected range of the historical average, null rates below a threshold, values within a plausible min/max, catch content problems that pass schema validation but are still wrong, a feed that silently starts reporting prices in cents instead of dollars, for example.

The design choice that matters most is what happens when a check fails: halting the pipeline and alerting a human is almost always safer than silently proceeding with bad data and letting it propagate into a dashboard or model that someone trusts. A pipeline that fails loudly and rarely beats one that never fails but occasionally lies.

This question is really asking whether you understand what the firm actually values, described by candidates as intellectual rigor without arrogance, and whether you can point to real evidence from your own history rather than reciting the phrase back. A strong answer names a specific moment you changed your position because someone showed you good evidence, not just a moment you were right.

Avoid generic alignment claims, "I value data-driven decisions" without a concrete story attached reads as rehearsed. Pair the value with a specific example: a time you built something, got contradicting evidence, and updated your approach instead of defending the original plan.

Pick traits you can immediately back with a concrete example, not aspirational adjectives. Curiosity that shows up as actually digging into why a result looked wrong instead of accepting it, intellectual honesty that shows up as flagging your own uncertainty to a team before it becomes a bigger problem, and persistence that shows up as sticking with a genuinely hard debugging problem past the point where most people would have given up.

The alignment part matters as much as the traits themselves. Connect each trait explicitly to something Two Sigma has said about itself, treating assumptions as provisional, valuing evidence over confidence, rather than leaving the interviewer to infer the connection.

Structure this around the decision that was actually in question, not just the analysis itself. State what choice was on the table, what the default or intuitive answer would have been without data, what you actually measured, and how the result changed the outcome from what would have happened otherwise.

The strongest version of this answer includes a moment where the data contradicted what you or your team initially expected, since that's the part that demonstrates you followed the evidence rather than confirming a decision that was already made. If your example doesn't have that tension, it's worth picking a different story that does.

Pick a disagreement about substance, a technical approach, a modeling assumption, a priority call, rather than an interpersonal or personality conflict, since the former demonstrates how you handle intellectual disagreement, which is closer to what the role actually requires day to day.

Describe both positions fairly before explaining how it got resolved, since an answer that makes the other person obviously wrong from the start reads as one-sided and undermines the "intellectual honesty" quality the interviewer is actually screening for. The best resolutions usually involve someone, possibly you, updating their view based on evidence rather than one side simply winning the argument.

Frame this around a specific, concrete piece of feedback rather than a general performance concern, feedback about a specific decision, piece of code, or approach is easier to deliver constructively and easier for the other person to actually act on than vague feedback about attitude or style.

Describe how you delivered it, privately, directly, focused on the work rather than the person, and what happened afterward. The strongest versions of this story include a moment where you checked whether your feedback actually landed, rather than assuming it did just because the conversation ended cordially.

String decoding problems, think run-length encoding variants like 3[a2[c]] expanding to accaccacc, are almost always solved with a stack that tracks the current string being built and the repeat count each time you enter a bracket. The hard part isn't the concept, it's handling nested brackets and multi-digit counts correctly without an off-by-one error.

def decode_string(s):
  stack = []
  current_str, current_num = "", 0
  for ch in s:
    if ch.isdigit():
      current_num = current_num * 10 + int(ch)
    elif ch == "[":
      stack.append((current_str, current_num))
      current_str, current_num = "", 0
    elif ch == "]":
      prev_str, num = stack.pop()
      current_str = prev_str + current_str * num
    else:
      current_str += ch
  return current_str

Whenever a problem says "decode" or "expand" a compressed representation, a stack of partial results is almost always the right first instinct, since it naturally mirrors the nested structure without needing recursion.

LFU (least frequently used) evicts based on access count rather than recency, and ties at the same frequency get broken by recency, LFU is effectively LRU-within-a-frequency-bucket. The naive implementation, a hash map tracking counts plus a heap, gives O(log n) operations. The O(1) version needs a hash map of key to (value, frequency), a hash map of frequency to an ordered set or doubly linked list of keys at that frequency, and a pointer tracking the current minimum frequency.

This is the question that separates candidates who've implemented complex data structures under pressure before from those who haven't. Most candidates get the naive heap-based version working and only sketch the O(1) approach verbally, which is a reasonable outcome given the time available in a single round.

The common pattern is shortest-path-with-state, where the graph search (BFS or Dijkstra) needs to track an additional dimension beyond just position, remaining fuel, number of stops used, keys collected, and dynamic programming is layered on top to avoid recomputing the same (position, state) pair repeatedly. A classic example is cheapest flights within k stops, where the state is (city, stops used so far) instead of just city.

def cheapest_flight(n, flights, src, dst, k):
  INF = float("inf")
  dist = [INF] * n
  dist[src] = 0
  for _ in range(k + 1):
    new_dist = dist[:]
    for u, v, w in flights:
      if dist[u] != INF and dist[u] + w < new_dist[v]:
        new_dist[v] = dist[u] + w
    dist = new_dist
  return dist[dst] if dist[dst] != INF else -1

Recognizing that "shortest path with a constraint" usually means expanding your state space, not switching algorithms entirely, is the transferable lesson here.

A Markov chain models a system where the next state depends only on the current state, not on the full history that led there, the memoryless property. States and transition probabilities between them fully describe the system's future evolution. A simple financial framing: modeling a market as being in one of a few discrete regimes, trending, mean-reverting, high-volatility, where the probability of transitioning between regimes tomorrow depends only on today's regime.

import numpy as np

transition_matrix = np.array([
  [0.8, 0.15, 0.05], # from trending
  [0.2, 0.7, 0.1],  # from mean-reverting
  [0.3, 0.3, 0.4],  # from high-volatility
])

def steady_state(matrix, iterations=1000):
  n = matrix.shape[0]
  state = np.ones(n) / n
  for _ in range(iterations):
    state = state @ matrix
  return state

The honest caveat worth stating unprompted: markets clearly aren't truly memoryless, momentum and mean-reversion effects imply longer dependencies, so a Markov model is a simplification useful for tractability, not a claim that the memoryless assumption is literally true.

Start with look-ahead bias, is any piece of information used at time t actually only available after time t in the real world, a shifted timestamp or a data revision that leaked future knowledge into the historical dataset is the single most common cause of an implausibly good backtest. Next, check for survivorship bias in the universe of instruments tested, and multiple-testing bias, if the strategy was the best of hundreds of parameter combinations tried, the reported Sharpe ratio overstates true out-of-sample performance because you're seeing the winner of a large search, not a single honest test.

Transaction costs and slippage assumptions are the other place backtests quietly flatter themselves, a strategy that trades frequently in a size the real market can't absorb at the modeled price will look great on paper and lose money live. A candidate who names two or three of these specific failure modes, rather than a vague "backtests can be misleading," is demonstrating they've actually debugged one before.

Candidate reports specifically flag this question's structure: expectation, actual outcome, why it diverged, and what you took away. Two Sigma's own emphasis on this format suggests they're testing whether you can separate "the project failed" from "I learned something specific and durable from it," which are very different answers.

Walk through the hypothesis you started with and why it seemed reasonable at the time, not with the benefit of hindsight. Describe concretely what the data or results actually showed instead. Name the specific reason for the gap, a bad assumption, an overlooked confound, insufficient data, rather than a vague "it just didn't work." Close with what you'd do differently and, ideally, evidence you've since applied that lesson somewhere else.

Build a prefix sum array of the weights, then generate a random number between 1 and the total weight, and binary search the prefix sum array for the first value greater than or equal to that random number. Items with larger weights occupy a wider range in the prefix sum array, so they're proportionally more likely to be the binary search result.

import random, bisect

class WeightedPicker:
  def __init__(self, weights):
    self.prefix = []
    total = 0
    for w in weights:
      total += w
      self.prefix.append(total)
    self.total = total

  def pick_index(self):
    target = random.randint(1, self.total)
    return bisect.bisect_left(self.prefix, target)

Construction is O(n), each pick is O(log n). The insight interviewers are looking for is recognizing that "probability proportional to weight" is a range-mapping problem, not something you solve with repeated random sampling.

Start by pinning down the operations that matter: insert, delete, cursor movement, undo, redo. The core data structure decision is what backs the text buffer, a plain array is simple but makes insert/delete O(n), a gap buffer or piece table gets you fast local edits near the cursor at the cost of more bookkeeping. For an interview, a gap buffer is usually the sweet spot: easy enough to explain in a whiteboard-length answer, and it demonstrates you know the naive array approach isn't what production editors actually use.

class TextEditor:
  def __init__(self):
    self.buffer = []
    self.cursor = 0
    self.undo_stack = []

  def insert(self, text):
    self.undo_stack.append(("delete", self.cursor, len(text)))
    self.buffer[self.cursor:self.cursor] = list(text)
    self.cursor += len(text)

  def delete(self, count):
    deleted = "".join(self.buffer[self.cursor:self.cursor + count])
    self.undo_stack.append(("insert", self.cursor, deleted))
    del self.buffer[self.cursor:self.cursor + count]

Undo is the part interviewers probe hardest. A stack of inverse operations, as sketched above, is the cleanest general answer, and it naturally extends to redo with a second stack.

This is a comparator design question dressed up in domain language. The clean answer is to keep the record class free of sorting opinions and inject a comparator, or in Python, a key function, at call time, so the same class supports sorting by timestamp in one context and by dollar value in another without subclassing or adding flags to the record itself.

class Trade:
  def __init__(self, timestamp, value):
    self.timestamp = timestamp
    self.value = value

trades_by_time = sorted(trades, key=lambda t: t.timestamp)
trades_by_value = sorted(trades, key=lambda t: t.value, reverse=True)

The design principle being tested is separation of data from ordering policy. A candidate who bakes a fixed comparison method into the class itself has to modify that class every time a new sort criterion shows up, which is exactly the coupling a comparator or strategy pattern avoids.

Token bucket is usually the right default: each client has a bucket that refills at a fixed rate up to a cap, and each request consumes a token, so bursts up to the bucket size are allowed while sustained rate stays bounded. Fixed-window counters are simpler but let a client burst up to 2x the limit right at the window boundary, which is a real weakness worth naming if you propose one.

import time

class TokenBucket:
  def __init__(self, rate, capacity):
    self.rate, self.capacity = rate, capacity
    self.tokens = capacity
    self.last_check = time.time()

  def allow(self):
    now = time.time()
    self.tokens = min(self.capacity, self.tokens + (now - self.last_check) * self.rate)
    self.last_check = now
    if self.tokens >= 1:
      self.tokens -= 1
      return True
    return False

The follow-up interviewers reach for is what happens across multiple servers, sliding-window logs stored in a shared store like Redis, since an in-memory bucket per server undercounts a client hitting several instances behind a load balancer.

Model spot size as an enum (compact, large, motorcycle) and vehicles as requiring a minimum spot size, then each level maintains a small set of available-spot-by-size indexes so a lookup doesn't have to scan every spot linearly. Assigning the nearest available spot on entry is a straightforward priority queue per size category, ordered by distance from the entrance.

class ParkingLot:
  def __init__(self, levels):
    self.levels = levels

  def park(self, vehicle):
    for level in self.levels:
      spot = level.find_spot(vehicle.size)
      if spot:
        spot.assign(vehicle)
        return spot
    return None

This is a classic that shows up across firms, not unique to Two Sigma, but it's a reasonable proxy for whether you can decompose an ambiguous prompt into concrete classes without over-designing it into a distributed system it doesn't need to be.

Start by clarifying what's actually being predicted and why it matters, the target variable and the cost of getting it wrong in each direction, before touching features or models. Two Sigma's own framing for this track emphasizes exactly this: candidates who ask how the data was collected, what biases it carries, and what's missing outperform candidates who jump straight to picking an algorithm.

After the target is clear, walk through candidate features grounded in domain reasoning rather than a generic list, then discuss model choice as a trade-off, a simple linear model that's interpretable and fast to retrain versus a more flexible model that might capture nonlinearity at the cost of overfitting risk and slower iteration. Close by naming how you'd validate the choice out of sample and what would make you distrust your own result.

A typical shape: a message queue or log (Kafka is the common default) absorbing incoming events durably and decoupling producers from consumers, a stream processor consuming from that log to compute rolling aggregates or enrich events, and a serving layer, a fast key-value store or time-series database, that downstream dashboards and alerts actually query.

Producers -> Kafka topic -> Stream processor (aggregation/enrichment) -> Serving store -> Dashboards/Alerts
                  |
               Cold storage (batch reprocessing, backfill)

The detail interviewers probe is what happens when the stream processor falls behind or crashes: does the design tolerate replaying from the log without producing duplicate or double-counted aggregates downstream, idempotent writes and clear offset tracking are the answer, not "it just won't crash."

The three realistic options are a single global lock (simple, correct, but serializes every operation and kills throughput under contention), striped or fine-grained locking (partition the hash map into segments, each with its own lock, so unrelated keys don't block each other), and a lock-free structure using compare-and-swap (highest throughput, hardest to get correct, and rarely worth building yourself instead of using a language's existing concurrent map).

import threading

class StripedMap:
  def __init__(self, num_stripes=16):
    self.stripes = [dict() for _ in range(num_stripes)]
    self.locks = [threading.Lock() for _ in range(num_stripes)]

  def _stripe(self, key):
    idx = hash(key) % len(self.stripes)
    return self.stripes[idx], self.locks[idx]

  def put(self, key, value):
    stripe, lock = self._stripe(key)
    with lock:
      stripe[key] = value

Read-write locks are the middle ground worth mentioning too: they let multiple concurrent readers through simultaneously and only block on a writer, which fits workloads with far more reads than writes, common in caching layers.

The core structure is two priority queues, one for buy orders sorted by highest price first, one for sell orders sorted by lowest price first, with ties broken by earliest timestamp (price-time priority, the standard rule real exchanges use). On every new order, check whether the best opposing price crosses, the highest bid meets or exceeds the lowest ask, and if so, match and fill quantities, partially filling and re-queuing the remainder if sizes don't line up exactly.

import heapq

class OrderBook:
  def __init__(self):
    self.buys = []  # max-heap: store as (-price, time, qty)
    self.sells = [] # min-heap: (price, time, qty)

  def add_buy(self, price, time, qty):
    while self.sells and self.sells[0][0] <= price and qty > 0:
      best_ask, t, ask_qty = heapq.heappop(self.sells)
      traded = min(qty, ask_qty)
      qty -= traded
      ask_qty -= traded
      if ask_qty > 0:
        heapq.heappush(self.sells, (best_ask, t, ask_qty))
    if qty > 0:
      heapq.heappush(self.buys, (-price, time, qty))

Interviewers here are less interested in a textbook-perfect matching engine and more in whether you naturally reach for price-time priority and partial fills without being prompted, since that's the domain knowledge that separates a generic OOD answer from one tailored to a trading firm.

The common pattern is tiered storage: recent, hot data (say, the last few days or weeks) sits in a fast columnar time-series store or an in-memory cache optimized for point and range queries, while older data gets rolled off into cheaper, append-only columnar storage, Parquet files on object storage, partitioned by date and symbol, that's optimized for scan-heavy analytical queries rather than low-latency point lookups.

Hot tier (last N days):  fast KV/time-series store, low-latency point + range queries
Warm/cold tier (older):  partitioned columnar files (date/symbol), optimized for bulk scans
Compaction job:       periodically migrates aged-out hot data into the cold tier

Partitioning by both date and symbol matters because most queries filter on one or both, a query for a single symbol's history over months shouldn't have to scan every symbol's data for that period. The trade-off worth naming out loud is that this tiering adds real operational complexity, a compaction job that migrates data between tiers on a schedule, and that complexity has to be justified by an actual query pattern, not built speculatively.