Jane Street Interview Questions (2026): Real Q&A

Resume screen, then a recruiter call to talk through background and interest, then one or two technical phone screens, then a final onsite or virtual round candidates call a superday, four to six back to back sessions in one day covering coding, probability, trading intuition, and cultural fit. For quant roles the phone screen leans on probability brainteasers and a short betting game rather than a whiteboard algorithm.

Software engineering candidates get a technical phone screen focused on algorithms and problem solving before the onsite, and the onsite itself adds system design and a collaborative coding exercise on top of that. The shape is similar across offices, but which exact rounds happen over Zoom versus in person depends on the region and the role.

No, and the company says so directly. Jane Street's own interviewing page states that most software engineers they hire arrive with no OCaml or functional programming background at all, and it tells candidates not to bother learning it purely to prep for an interview. You can interview in whichever language you're strongest in.

Where OCaml does come up is reading comprehension, not writing. Several candidates report being handed a short OCaml function, often something like a tree or list representation, and asked to explain what it does and reason about its runtime. That's a different skill than writing idiomatic OCaml from scratch, and it's the one worth actually practicing if you've never seen the syntax before.

It varies by region and team, but candidates describe either a HackerRank or Codility-style coding link, or in some locations a shorter logic and data task done in Excel. The coding version tends toward implementation-heavy problems, building up a small system piece by piece, rather than a single clever algorithm you either know or don't.

Correctness matters more than raw speed here. Multiple reports describe interviewers caring most about whether you handle edge cases and avoid off-by-one mistakes, not whether you found the asymptotically optimal approach on the first try.

Conditioning on 'at least 4' throws out 1, 2, and 3, leaving 4, 5, and 6 as the only remaining equally likely outcomes. The expected value of that reduced set is (4 + 5 + 6) / 3 = 5, noticeably higher than the unconditional 3.5, because you've eliminated every low outcome from consideration, not just made them less likely.

The instinct to check is whether you reach for the full conditional probability formula or just recompute the average over the surviving outcomes. For a uniform distribution with a simple threshold cutoff like this one, recomputing directly is faster and just as correct, and interviewers notice when a candidate defaults to heavier machinery than a problem actually needs.

Set up states for how many consecutive heads you currently have: 0, 1, or done at 2. Let E0 be the expected flips remaining from state 0 and E1 from state 1. From state 0, a flip is heads (prob 1/2) moving you to state 1, or tails (prob 1/2) keeping you at state 0: E0 = 1 + 0.5*E1 + 0.5*E0. From state 1, heads finishes it, tails sends you back to state 0: E1 = 1 + 0.5*0 + 0.5*E0.

Solving those two equations gives E0 = 6. The general pattern, expected flips to get n heads in a row is 2^(n+1) - 2, is worth having memorized, but showing the state-machine setup matters more than reciting the formula, since that's what an interviewer actually wants to see you construct live.

Your fair value estimate is a single number, your best guess at what the asset is actually worth right now. Your quote is a two-sided price, a bid and an ask straddling that fair value, and the gap between them, your spread, is compensation for the risk that whoever trades against you knows something you don't.

A wider spread protects you against adverse selection but loses you trades to a competitor quoting tighter. A narrower spread wins more flow but exposes you to bigger losses when someone better informed trades against you. The whole game is finding where that tradeoff sits given how much you actually know versus how much the other side might know.

Model each cell as either a literal value or a formula referencing other cells, and evaluate recursively: a cell's value is either its literal, or the sum of evaluating each cell it references. The recursive structure mirrors exactly how a real spreadsheet resolves formulas.

def evaluate(cell_id, cells, cache=None):
  cache = cache if cache is not None else {}
  if cell_id in cache:
    return cache[cell_id]
  cell = cells[cell_id]
  if cell.is_literal:
    result = cell.value
  else:
    result = sum(evaluate(ref, cells, cache) for ref in cell.references)
  cache[cell_id] = result
  return result

Caching resolved values matters as soon as the same cell gets referenced from two different formulas, otherwise you're recomputing the same subtree repeatedly.

Track cells currently 'in progress' during the recursive evaluation, a visiting set separate from the finished cache. If evaluation reaches a cell that's already marked as currently being visited, that's a cycle, and the right move is to raise an error rather than recurse infinitely.

def evaluate(cell_id, cells, cache, visiting):
  if cell_id in cache:
    return cache[cell_id]
  if cell_id in visiting:
    raise ValueError(f"circular reference at {cell_id}")
  visiting.add(cell_id)
  cell = cells[cell_id]
  result = cell.value if cell.is_literal else sum(
    evaluate(ref, cells, cache, visiting) for ref in cell.references
  )
  visiting.remove(cell_id)
  cache[cell_id] = result
  return result

This is exactly the kind of edge case Jane Street interviewers are reported to weight heavily, the correct-looking recursive solution that quietly infinite-loops the moment a real spreadsheet user creates a circular reference by accident.

Two trees are structurally equal if both are empty, or both are non-empty with equal values at the root and their left and right subtrees are each recursively equal. It's a clean base-case-plus-recursion problem, and the interesting part of the conversation is usually what happens when candidates are asked to do it in OCaml instead of a language with familiar null handling.

def trees_equal(a, b):
  if a is None and b is None:
    return True
  if a is None or b is None:
    return False
  return (a.value == b.value
      and trees_equal(a.left, b.left)
      and trees_equal(a.right, b.right))

Runtime is O(n) where n is the number of nodes in the smaller tree, since the recursion short-circuits the moment it hits a mismatch.

A variant type lists a fixed set of named cases a value can take, optionally each carrying different attached data, and the compiler forces you to handle every case when you pattern match on it. It's the same underlying idea as a discriminated union in TypeScript, but OCaml treats it as a first-class, deeply idiomatic tool rather than a niche pattern.

type shape =
 | Circle of float      (* radius *)
 | Rectangle of float * float (* width, height *)

let area = function
 | Circle r -> Float.pi *. r *. r
 | Rectangle (w, h) -> w *. h

The compiler warns, or errors under strict settings, if you add a new case to shape and forget to handle it in area. That exhaustiveness check is a large part of why OCaml codebases tend to have fewer 'forgot to handle a new state' bugs than languages without it.

An immutable value can't be changed out from under you after it's created, which means once you've verified a piece of logic is correct given a value's contents, that correctness holds for the value's entire lifetime, not just at the moment you checked it. In a mutable world, a function three call frames away could quietly change a value your current function is relying on.

The practical payoff shows up most in concurrent or multi-threaded code, where shared mutable state is the classic source of race conditions. Immutable data structures sidestep an entire category of bugs by construction, at the cost of allocating new versions of a structure instead of updating one in place, which is a real tradeoff, not a free lunch.

TCP guarantees ordered, reliable delivery through acknowledgments and retransmission, at the cost of latency and connection overhead. UDP just fires packets with no delivery guarantee and no ordering guarantee, but with far less overhead per packet.

Market data feeds are a classic case for UDP multicast: when you're broadcasting the same price update to thousands of subscribers, retransmitting to guarantee delivery to every single one would add latency that matters more than an occasional dropped packet the receiver can detect and request a snapshot to recover from. Order entry, by contrast, almost always needs the reliability guarantees TCP provides, since losing an order silently is a much bigger problem than losing one price tick.

Correlation means two things tend to move together. Causation means one of them is actually the reason the other moves. Two variables can be correlated because one causes the other, because both are driven by some third factor neither of you has measured, or purely by coincidence if you look at enough variables.

A simple way to make this concrete without jargon: ice cream sales and drowning deaths both rise in summer, correlated, but ice cream doesn't cause drowning. Hot weather drives both. The general lesson, that a shared underlying cause can produce a strong correlation with no direct causal link at all, is the part worth stating explicitly rather than assuming the interviewer will infer you understand it.

Jane Street's own materials say a finance background is optional and a problem-solving mindset is what actually matters, so an answer that leans entirely on 'I've always loved markets' without substance behind it tends to fall flat with interviewers who've heard that line many times. A stronger answer connects something specific about how you think, comfort updating quickly on new information, genuine enjoyment of quantifying uncertainty, to what the trading role actually demands day to day.

It's fine, and honest, to say you're drawn to the intellectual style of the place more than to trading as a subject in isolation. Interviewers reportedly care more about whether your reasoning holds together than whether you arrive with a lifelong passion for markets specifically.

Pick an example where the disagreement was substantive, a real technical or strategic difference, not a personality conflict, and where the resolution came from evidence or reasoning rather than someone simply deferring to seniority or getting worn down. Jane Street's stated culture explicitly rewards being persuadable by a good argument regardless of who's making it.

The strongest version of this answer includes a moment where you changed your own mind, not just one where you convinced someone else. Being able to say 'I was initially against it, then they showed me X, and I changed my position' demonstrates exactly the intellectual honesty the firm says it's screening for.

Candidates consistently describe four to eight weeks from application to offer, with Glassdoor's own aggregate data putting the average time to hire for a software engineer role at about 19 days once things are moving, and 17 days across all roles. That gap between the two numbers usually comes down to scheduling superday slots, not slow decision making once you're in the room.

For the superday specifically, several candidates report hearing back the same day or within 24 hours, since Jane Street's interviewers typically debrief right after your sessions finish rather than batching decisions across a longer hiring cycle.

Expected value is 0.5(10) + 0.5(-5) = 2.5, positive, so on a purely expected-value basis you take it every time it's offered. The interesting part of this question isn't the arithmetic, it's whether you say anything about bet sizing relative to your bankroll, since a positive-EV bet you can only take once, with a downside that would meaningfully hurt you, is a different decision than the same bet offered a thousand times.

Jane Street interviewers are explicit that they care less about the number and more about whether you'd actually be comfortable trading on that logic, buying for less than fair value or selling for more, in a live market. Say the EV out loud, then say what you'd actually do with real money on the line.

Count outcomes directly rather than reaching for Bayes' rule first. Out of 36 equally likely pairs, 11 have at least one 4: the six pairs where the first die is 4, the six where the second die is 4, minus the one pair (4,4) counted twice. Of those 11, exactly two sum to 7: (4,3) and (3,4).

So the answer is 2/11. This is a case where Bayes' theorem gets you the same answer but adds bookkeeping you don't need. Interviewers watching you solve it want to see whether you notice that counting is faster before you commit to a heavier method.

Work from the CDF. P(max of two dice ≤ k) = (k/6)^2, since both dice individually need to land at or below k. P(max = k) is then the difference between consecutive CDF values: (k/6)^2 - ((k-1)/6)^2. Summing k times that probability across k = 1 to 6 gives the expected value.

Working it out, the expected max of two dice comes out to 161/36, about 4.47, noticeably higher than a single die's 3.5. The takeaway an interviewer wants isn't just the number, it's that taking the max of two draws instead of one systematically pushes the expectation up, and being able to say why in one sentence is worth more than the arithmetic itself.

There's a clean symmetry argument here that beats brute-force summation. Split the 52 cards into 5 groups: the 4 aces and the 48 non-aces divide the deck into 5 gaps (before the first ace, between aces, and so on), and by symmetry each of the 53 positions relative to those gaps is equally likely to be occupied by a given non-ace.

The general result is that the expected position of the first success among k successes in a shuffled deck of n cards is (n + 1) / (k + 1). Here that's 53 / 5 = 10.6. Deriving that formula from the symmetry argument, rather than memorizing it, is what separates a candidate who understands the structure from one who's seen the specific question before.

First move your fair value estimate toward whatever their trade implied, since a counterparty willing to buy at your ask is signaling their fair value is higher than yours, and that's real information even if you don't know exactly why. Then widen your spread, at least temporarily, because you've just learned there's an informed player at the table and your next quote needs to protect against the same thing happening again.

What interviewers actually want to see is that you update in the direction of the trade rather than getting stubborn about your original number. Being wrong once and refusing to move is a much worse trait in this game than being wrong and adjusting quickly.

Spread width should track your uncertainty about fair value and the perceived sophistication of who you're trading against. Early in a game, when you have little information, a wider spread is defensible because you genuinely don't know enough to quote tight. As trades accumulate and you build a clearer picture of where fair value actually sits, narrowing makes sense, assuming the flow you're seeing looks uninformed rather than adversarial.

The mistake to avoid is treating spread width as fixed. An interviewer watching you quote the same spread on flip one and flip twenty of the same game is a candidate who isn't actually updating on what they've learned, which is the entire point of the exercise.

Track who trades with you and in which direction over the course of the game, not just the last trade. A player who consistently buys right before the price moves up is giving you a signal about their information edge that a single trade wouldn't reveal, and that pattern should push you to quote wider or skew more defensively against that specific counterparty going forward.

This is also where the 'teachable' quality Jane Street explicitly says it looks for shows up. A candidate who notices a pattern across rounds three and four and adjusts by round five is demonstrating exactly the kind of live learning the game is designed to surface.

Split each topic into segments on the delimiter and match a subscription pattern against a published topic segment by segment, where a wildcard segment matches anything in that position. Storing subscriptions as a trie keyed by segment scales better than scanning every registered pattern on every publish once the subscriber count grows.

def matches(pattern_segments, topic_segments):
  if len(pattern_segments) != len(topic_segments):
    return False
  return all(
    p == "*" or p == t
    for p, t in zip(pattern_segments, topic_segments)
  )

def publish(self, topic, message):
  topic_segments = topic.split(".")
  for pattern, callbacks in self.subscribers.items():
    if matches(pattern.split("."), topic_segments):
      for cb in callbacks:
        cb(message)

Worth flagging out loud: this simple version doesn't handle a trailing multi-level wildcard like billing.# matching any depth, which is a real feature in systems like MQTT. Naming that gap yourself shows you know where the simple version stops being production-ready.

Model the board as a graph where dots are nodes and drawn arrows are directed edges, tagged with which player drew them. A 'completed shape' is a specific structural pattern in that graph, so scoring comes down to walking the graph once and counting how many times that pattern closes, attributing each completion to whichever player drew the edge that finished it.

The actual scoring rule reported for this one varies by which version of the game an interviewer uses, so the honest answer is that the graph-representation approach is the transferable skill here, not a specific formula. Interviewers are reported to care most about how cleanly you model the board as a data structure before you write a single line of scoring logic.

O(n) time where n is the number of nodes in the smaller of the two trees, since the recursion visits each node once and short-circuits immediately on the first mismatch. Space is O(h) for the recursion stack, where h is the tree's height, which becomes O(n) in the worst case of a completely unbalanced tree.

If asked to optimize further, the honest answer is that O(n) is already optimal for exact equality, since you fundamentally need to look at every node in the smaller tree to prove two trees match. The more interesting optimization conversation is converting the recursive version to iterative with an explicit stack, which trades code readability for avoiding a stack overflow on a very deep tree.

Pattern matching destructures a value's shape while branching on it, in one step, rather than branching first and then manually pulling data out of the matched case. Matching on a variant type also gets you compiler-enforced exhaustiveness, missing a case is a compile error or warning, not a silent runtime bug the way a missing switch case or an unhandled elif branch would be.

type result = Ok of int | Error of string

let describe = function
 | Ok n -> Printf.sprintf "got %d" n
 | Error msg -> Printf.sprintf "failed: %s" msg

A Java switch on an enum can get close to this with modern pattern matching features, but the deep integration between variant types, pattern matching, and exhaustiveness checking across the whole language is more central to how OCaml code gets written day to day.

Start with the type signature, since OCaml's type inference means even a short signature tells you a lot: what goes in, what comes out, and whether the function might fail. Then walk the pattern match case by case, treating each branch as its own small piece of logic rather than trying to hold the whole function in your head at once.

Say your reasoning out loud as you go, including where you're uncertain. Jane Street's interviewers are explicitly looking for how you work through something unfamiliar with hints, not whether you already know OCaml syntax cold, so narrating your process is more valuable here than getting to the right answer silently and fast.

A purely functional order book, where every update returns a new version of the structure instead of mutating the existing one, gives you cheap, safe snapshots: you can hold a reference to the book as it looked at any past point without worrying that a later update silently changed it. That's valuable for replaying history or reasoning about concurrent readers.

The cost is allocation. Every update creates new data, structural sharing keeps this cheaper than it sounds for tree-like structures, but it's still real overhead compared to updating a mutable array in place. For something latency-sensitive like a live order book on the hot path, many real systems accept the mutability risk deliberately and control it with careful ownership rules instead, which is itself a defensible answer if you explain the reasoning.

Shared memory is the fastest option, since both processes read and write the same physical memory region with no copying or serialization, but you take on the full complexity of synchronization yourself, locks or lock-free structures, to avoid corrupting state when both sides touch it at once. A local Unix domain socket or pipe adds a copy and some kernel overhead but hands you a much simpler, already-synchronized communication model.

Going over the network, even loopback, adds a full networking stack's worth of overhead on top of that. The right choice depends on how much complexity you're willing to own yourself: shared memory buys you speed at the cost of you writing the synchronization correctly, which is a genuinely hard thing to get right under pressure.

The thread issues a read system call, and if there's no data available yet, the kernel moves that thread out of the running state and into a waiting state, so the CPU can schedule other runnable threads instead of spinning uselessly. The kernel registers interest in that socket's file descriptor and, once data arrives, marks the thread as runnable again so the scheduler picks it back up.

This is exactly why a thread-per-connection server can scale to thousands of idle connections cheaply, blocked threads cost memory for their stack but no CPU time, but eventually hits a wall on thread creation and context-switching overhead once the number of simultaneously active connections gets large, which is the usual motivation for moving to an event loop or async model instead.

A stationary series has statistical properties, mean, variance, autocorrelation structure, that don't change over time. A non-stationary series has properties that drift, a trending mean, growing variance, or both, which means a relationship you fit on one stretch of the series may simply not hold on a later stretch, not because your model was wrong, but because the thing it's modeling changed underneath it.

Most raw financial price series are non-stationary, which is exactly why a lot of modeling work happens on transformed series instead, returns rather than levels, or differenced series, that are closer to stationary and therefore more likely to have a relationship that actually persists out of sample. Fitting a model directly on a non-stationary raw price series and expecting the fitted relationship to hold going forward is a common and costly mistake.

A p-value is the probability of seeing a result at least as extreme as what you observed, if there were actually no real effect at all and everything you saw was just random noise. A small p-value means the pattern you found would be unlikely to show up by chance alone, which is evidence, not proof, against the 'nothing's really going on here' explanation.

The point worth adding unprompted: a p-value says nothing about how large or practically meaningful an effect is, only how unlikely it'd be to see by pure chance. A tiny, commercially irrelevant effect can produce a very small p-value if you have enough data, which is a common way p-values get misused in practice.

This question is looking for genuine intellectual flexibility, not a story where you learned a new tool and it happened to work better. The strongest examples involve a belief you held with real confidence, backed by past experience that had reinforced it, that turned out to be actively wrong in a new context, and describe what specifically made you notice the mismatch before it caused real damage.

Avoid picking an example that's really just 'I didn't know X, then I learned X.' That's ordinary learning. What's being tested here is whether you can catch yourself being wrong about something you were confident in, which is a meaningfully different and rarer skill.

Multiple candidates report that Jane Street interviewers deliberately hand out problems that are meant to be too hard to finish solo, specifically to see how you use hints and whether you can be productively taught mid-problem. The wrong response is silently grinding without saying anything, or bluffing confidence you don't actually have.

The better response is narrating where you're stuck specifically, not just 'I'm stuck', and treating a hint as new information to fold into your reasoning rather than a rescue you passively wait for. Interviewers explicitly say they're evaluating whether you're teachable, and a candidate who visibly incorporates a hint and moves forward is demonstrating exactly that.

Ask what specifically they're seeing that you're missing, rather than immediately either capitulating without understanding why or defending your original answer out of pride. The goal is to actually update your reasoning, not just perform agreement to move the conversation along.

If, after genuinely considering their point, you still think your original reasoning holds in some specific way, it's fine to say so, respectfully and with your actual reasoning attached. Jane Street's own description of its culture explicitly values being right through argument over deferring to whoever's more senior in the room, which cuts both ways: it protects you if you're right, but only if you've actually thought it through rather than just being stubborn.

The game: flip a coin until it lands heads, and you're paid 2^n dollars where n is the number of flips it took. The expected payout is the sum over all n of (1/2^n) * 2^n, which is 1 + 1 + 1 +... forever, an infinite expected value. Yet almost nobody would pay more than a modest fixed amount, maybe $20 or $30, to play once.

The resolution most economists reach for is that expected monetary value isn't the same thing as expected utility, and utility functions for money are typically concave, each additional dollar matters less than the one before it, which caps the 'fair' price you'd pay even though the raw dollar expectation is unbounded. There's also a practical angle worth raising: no real counterparty can actually pay out an arbitrarily large sum, so the theoretical infinite tail of the distribution is never really available to you in practice. A good answer touches both the utility argument and the counterparty-limit argument, not just one.

Quote one moves your midpoint to reflect the new fair value immediately, full stop, before anything else. Delaying that update to protect your existing position is backwards, the market doesn't care what you're holding, only what's actually true now. Quote two should also skew around your existing inventory: if you're already long, you want to make it slightly cheaper to sell to you and slightly more expensive to buy from you, nudging your position back toward flat rather than compounding the risk.

Quote three depends on how the market reacts to quotes one and two. If flow keeps hitting the same side, that's more information, and you keep adjusting fair value and skew in that direction. If flow reverses or dries up, you can start easing the inventory skew back toward a neutral quote. The core idea an interviewer is testing is whether you separate 'what's true' from 'what I'm holding', and update the first before letting the second distort your price.

Inventory risk management is the main reason. If you're already carrying a large long position, quoting your true fair value symmetrically means you're just as likely to get bought from as sold to, which does nothing to reduce your existing risk. Skewing your quote, lowering both your bid and ask below fair value, makes it cheaper for someone to sell to you and more expensive for someone to buy from you, which nudges your position back toward flat even at the cost of a slightly worse expected price on any single trade.

The second reason is defensive: if you suspect a specific counterparty is consistently better informed than you, quoting away from your estimate in their direction is a way to reduce how much they can extract from you, accepting a worse average price in exchange for lower variance against someone you can't out-inform.

OCaml's built-in list is a singly linked list, so any recursive function that walks it element by element is O(n) time, one step per element, and if it isn't tail-recursive, O(n) space too, since each recursive call adds a frame to the call stack before any of them return.

(* not tail recursive: builds up n stack frames before returning *)
let rec length = function
 | [] -> 0
 | _ :: rest -> 1 + length rest

(* tail recursive: accumulator carries the result, no stack buildup *)
let length_tr lst =
 let rec aux acc = function
  | [] -> acc
  | _ :: rest -> aux (acc + 1) rest
 in
 aux 0 lst

The non-tail-recursive version can blow the stack on a long enough list, since OCaml doesn't guarantee tail-call optimization for every recursive shape by default the way some languages do for all recursion. Rewriting with an accumulator so the recursive call is the very last thing that happens turns it into a loop underneath, flat space instead of growing with the list.

BGP, the Border Gateway Protocol, is the protocol that autonomous systems, meaning large networks like ISPs and data centers, use to advertise which IP ranges they can route to and negotiate the paths traffic takes between them across the public internet. It's what makes the internet a network of networks rather than one flat address space.

For a trading firm, BGP matters directly when latency between two points, say a firm's servers and an exchange's matching engine, depends on which physical path traffic actually takes, and BGP-driven route changes can add milliseconds of round-trip latency that matter enormously in a low-latency trading context. Firms serious about this often route around public BGP entirely for their most latency-sensitive links, using dedicated point-to-point connections or microwave links instead, precisely because BGP's constantly-shifting path selection isn't something you want in your critical path when microseconds matter.

This happens because network paths, switch buffering, and even NIC-level timing differences mean two physically separate machines rarely receive the exact same sequence of packets in the exact same order, even off the same multicast feed. The fix isn't to try to force network-level ordering, that's fighting physics, it's to make ordering explicit in the data itself: every message carries a sequence number or exchange timestamp, and each consumer reorders locally based on that field rather than trusting arrival order.

You also need a policy for gaps: if sequence number 1004 arrives before 1003, do you wait briefly for 1003 to show up, or proceed and reconcile later if it never does. That's a real latency-versus-correctness tradeoff, and there's no universally right answer, the right choice depends on how costly a wrong decision made on stale or out-of-order data actually is for that specific system.

Raw accuracy is the wrong lens here, because it treats every prediction the same regardless of stated confidence. Look at calibration instead: bucket predictions by the confidence the model reports, and check whether, within each bucket, the actual outcome rate matches the stated confidence. A model that says '90 percent confident' and is right about 90 percent of the time in that bucket is calibrated. A model that's badly overconfident on its misses will show buckets where stated confidence is high but real accuracy is much lower.

In a trading context specifically, a poorly calibrated but similarly accurate model is more dangerous than a well-calibrated one, because position sizing and risk decisions usually scale with stated confidence. A model whose confidence doesn't actually track its real accuracy will systematically size positions wrong on exactly the trades where it's most likely to be badly off, even if its headline accuracy number looks fine.

Pick a real example with genuine stakes, not a disagreement that was resolved trivially or where you were clearly right from the start. The strongest answers show a disagreement that took real work to resolve, where you had to build evidence, run an experiment, or find a concrete counterexample rather than just restating your opinion more forcefully.

Be honest if the resolution wasn't clean, if you ended up compromising, or if you were partially wrong and partially right. A tidy story where you were fully vindicated reads as less credible than one with actual texture, and Jane Street's interviewers are reported to probe follow-up details specifically to check whether a story holds up under questioning.

Avoid a generic answer about 'learning the codebase and asking good questions.' A stronger answer is specific about how you'd actually validate you were contributing: shipping something small and correct rather than something ambitious and half-finished, getting feedback early rather than disappearing to build in isolation, and being explicit about what you don't yet know rather than quietly guessing.

It's reasonable to say the honest answer is that in a genuinely new domain, the first real signal of value is often just correctly identifying what you don't understand yet and asking about it directly, rather than shipping something visible in week one. Overclaiming early impact in an interview answer tends to read as less credible than an honest, specific plan for ramping up.

The core is a dictionary mapping topic name to a list of subscriber callbacks. Publishing looks up the topic and calls each registered subscriber with the message; subscribing appends a callback to that topic's list.

class MessageBroker:
  def __init__(self):
    self.subscribers = {}

  def subscribe(self, topic, callback):
    self.subscribers.setdefault(topic, []).append(callback)

  def publish(self, topic, message):
    for callback in self.subscribers.get(topic, []):
      callback(message)

The obvious follow-up interviewers ask right after this is what happens when a subscriber's callback throws, and whether one bad subscriber should be able to block delivery to the others. Raising that yourself before being asked is a good signal.

A single-threaded consumer reading off one ordered queue is the simplest way to guarantee order, since there's no possibility of two updates processing concurrently and finishing out of sequence. The tradeoff is throughput: a single consumer caps how fast you can process updates, and if that becomes the bottleneck, you need to partition the stream, by symbol, for example, so each partition still processes strictly in order while different partitions run in parallel.

The detail that trips people up is what happens at the partition boundary: if two updates for the same symbol can arrive on different partitions due to how the data is sharded upstream, you've broken the ordering guarantee you were trying to build. Getting the partition key right, so anything that needs relative ordering always lands on the same partition, matters more than the concurrency mechanism you pick within a partition.

That gap is the signature of overfitting, the model has learned patterns specific to the training set, including its noise, rather than a generalizable relationship. First check the ratio of model complexity to data size: too many parameters relative to how much data you have is the single most common cause. Then check whether you evaluated on a truly held-out set, or accidentally let information from the test set leak into training, through feature engineering done on the full dataset before the split, for instance.

If complexity and leakage both check out, look at whether the out-of-sample data actually comes from the same distribution as training. A model that looks like it's overfitting might instead be encountering a genuine regime shift, market conditions that are structurally different from the training period, which calls for a different fix, sturdier features or a shorter training window, rather than just regularizing harder.

Randomized assignment is the core requirement: split incoming order flow between the old and new pricing model randomly, not by any factor that correlates with the outcome you're measuring, so any difference in fill rate you observe is attributable to the model change and not to some confound like time of day or order size sneaking in through a non-random split.

You'd also want to define your success metric and minimum detectable effect before looking at any results, and calculate roughly how much data you need to distinguish real improvement from noise at a reasonable confidence level. Running the test until the numbers happen to look favorable, rather than for a duration decided up front, is the classic way this kind of experiment quietly turns into a statistical fishing expedition.

The core difficulty is that a naive single-pass simulation assumes events process strictly in arrival order and never gets revisited. A late-arriving correction breaks that assumption, so you need to store enough state to replay from the point the correction applies, rather than just appending the new event and moving on.

One workable approach: keep an append-only log of events tagged with logical timestamps, and maintain a snapshot of derived state at each timestamp boundary. When a late event arrives with a timestamp earlier than the current position, invalidate every snapshot after that timestamp and replay forward from the last valid one. This is more expensive per correction than a pure append-only model, but it's correct, and the tradeoff between replay cost and correctness is exactly what an interviewer wants you to articulate, not just code silently.