Descriptions of the Software Engineer role at Two Sigma in this guide's sources centre on the systems behind quantitative research and automated trading. The areas named are distributed execution platforms for statistical models, low-latency market data gateways and order routing engines, data pipelines that clean and normalise financial and alternative datasets, and developer tools, custom databases and analytical libraries used to backtest and validate strategies. Engineers are described as working alongside quantitative researchers, platform engineers and site reliability specialists, and as owning their software from specification through testing and production monitoring.
The reported interview questions follow the same lines. On the algorithms side, candidates list shortest paths on a grid with obstacles, currency conversion graphs, a maximum set of non-adjacent nodes, Huffman encoding and decoding, and Trie-backed word search. On the systems side, they list a thread-safe LRU cache with TTL eviction, a malloc/free allocator over a fixed byte array, a thread-safe random generator that never repeats, and processes versus threads and IPC. Debugging exercises are reported on a binary search tree, a tree map under concurrent insert and delete, a filtering iterator and a slotted allocator. Financial terms such as order books, exchanges and currency tables often set the scene, but the problems themselves are data structures, concurrency and design.
Candidate reports also describe coding in a real IDE, with code that is expected to run and come with unit tests, rather than pseudo-code. So prepare to finish working, tested code, not just to reach the right idea. The loop section below separates what each stage emphasises. The plan turns the reported categories into one focused day each. Confirm the current format, language options and environment with your recruiter, because the stages here are what candidates describe, not a process Two Sigma has published.
Online Assessment
reportedCandidates describe an automated online assessment on a competitive coding platform with 2 to 3 algorithmic questions of medium to hard difficulty. The emphasis is on string parsing, array manipulation and graph traversal, with object-oriented design sometimes appearing. No interviewer is present to hear what you meant, so the code has to stand on its own against inputs you have not seen. Get a correct version of every question submitted before you optimise any one of them. Read the input bounds as a statement of which complexity is acceptable, and parse strings defensively rather than trusting the examples' formatting.
What to demonstrate
- Correctness beyond the worked examples: empty strings, single elements, disconnected graphs, unreachable targets and duplicate values
- Whether the complexity of your solution fits the stated input bounds
- Parsing discipline on string-heavy prompts: delimiters, repeated whitespace, malformed or missing tokens
How to prepare
- Do timed sets of two or three problems that mix string parsing, array manipulation and a graph traversal, and submit a correct brute force for each before optimising any
- Before every submission, run empty, single-element and all-duplicate inputs yourself and compare them with what you predicted
- Write BFS on a grid with obstacles from a blank file until you no longer look up the queue or visited-set API in your chosen language
Initial Technical Screen
reportedCandidates report a pair-programming call with a senior engineer in a shared coding environment. It combines a short resume review with either a live technical problem or a debugging scenario on code you did not write. Because the session is paired, your process is visible as it happens. Clarify the ambiguous parts of the prompt, state the approach and its complexity, then write code that runs. In a debugging scenario, reproduce the failure with a concrete input before changing anything, explain the root cause, and make the smallest fix that accounts for it instead of rewriting the function.
What to demonstrate
- How you clarify ambiguous requirements before coding and how you use a hint when one is offered
- Whether the code in the shared environment runs, handles null and edge inputs, and comes with test cases
- In a debugging scenario, whether you isolate the failing case and name the root cause before editing
- Whether the projects on your resume hold up to a direct follow-up question
How to prepare
- Pair with someone who plays the interviewer and narrate each decision while typing; ask them to stop you whenever the narration and the code disagree
- Practise debugging on code you did not write: have a friend plant two bugs in a data structure, then find each through a failing test before fixing it
- For each project on your resume, prepare one technical decision you made and the alternative you rejected
Final Interview Stage
reportedCandidates describe the final stage as a 'Superday', held virtually or in person, with back-to-back technical rounds in the morning and behavioral rounds in the afternoon. Reports also describe a morning gate: if the morning technical sessions do not meet the bar, the afternoon behavioral rounds may be cancelled. Prepare for the day as a whole. Treat each technical round as if it has to stand on its own, and have a way to reset between rounds so that a rough one does not carry into the next.
What to demonstrate
- Reaching working code with tests, since candidates who do not produce functional code are reported to rarely move forward
- Whether code quality holds late in the day: naming, modular functions, edge-case handling and tests
- Whether you talk through your reasoning, clarify requirements before coding and take a hint when one is offered
How to prepare
- Run at least one mock with two or three technical problems from different categories back to back, in an IDE, with no long break between them
- Write a short reset routine for between rounds: one line on what went wrong, then set it aside until the day is over
- Prepare the behavioral stories before the day, because you will not know in advance whether the afternoon goes ahead
Technical Evaluation
reportedThe morning technical sessions are reported to cover advanced algorithms, system design, object-oriented modelling and hands-on debugging. Candidates report writing code in an IDE that is expected to run with unit tests. Example scenarios reported for the technical evaluations include an in-memory order management system that matches buy and sell limit orders by price-time priority, a thread-safe in-memory cache with configurable TTL eviction and low lock contention, and a malloc replacement over a backing byte array that manages block allocation and coalescing. Expect financial vocabulary as context around ordinary data structure, concurrency and design problems.
What to demonstrate
- Reaching the optimal time and space complexity without missing boundary conditions
- A working understanding of locks, memory allocation and IPC trade-offs, not only their names
- Clear class responsibilities, encapsulated state and a small interface in object-oriented modelling
- Tests that exercise adversarial inputs to your own data structures
How to prepare
- For each systems question in the reported list, write down which thread owns which state and what protects it before you write code
- Implement a price-time priority matcher with partial fills and cancel-by-id, and test crossing orders at equal prices
- Rehearse the structure for debugging: failing input, root cause, minimal fix, then a regression test that stays in the file
Behavioral Rounds
reportedCandidates report these as afternoon behavioral interviews that take place only if the morning technical sessions cleared the bar. The reported prompts are about ownership and judgement in technical work. They ask about a complex project you took from design to production and its architectural decisions, a technical disagreement with a senior lead over architecture or tool selection, a production bug under a tight deadline and how you prevented a repeat, and why you want Two Sigma and quantitative financial engineering. Each of these is an engineering story, so prepare the technical detail behind it as carefully as the narrative.
What to demonstrate
- Ownership: whether the project you describe ran from design through production and what happened when it broke
- How a disagreement with a more senior engineer was settled, and with what evidence
- How you diagnosed a production bug under pressure and what you changed so it would not recur
How to prepare
- Pick four projects and write each out to the level of the code you changed and the alternative you rejected, so a third follow-up question does not exhaust the story
- Map the reported prompts (end-to-end project, disagreement with a senior lead, production bug under deadline, why Two Sigma) to specific projects in advance
- Write a 'why Two Sigma' answer from your own interests in the problem areas this guide lists, not from claims about the firm
9 candidate reports. Individual accounts describe a particular role and hiring cycle.
Two Sigma Data Scientist Interview Experience — Nailed the Good-Pair Expectation Problem, Still Rejected
View report detailsTwo Sigma Intern Data Scientist Interview Experience — A Markov Chain Curveball and a DP Fix Five Minutes Too Late
View report detailsTwo Sigma New Grad Software Engineer Interview Experience — Two OA Questions, Advanced the Next Day
I applied for Two Sigma's New Grad SWE role. I didn't have much hope going in — not long after a mass application round, I got an OA invite: two problems to solve together in one time-limited session. Before applying I'd heard this company has a lot of rejection stories, so I specifically went and dug through the forum to do my homework. Several posts said the OA questions on the forum were the a…
Read full experienceTwo Sigma Software Engineer Interview Experience — Trie-Tree OA, Rejected on a Permutation Question
View report detailsTwo Sigma Software Engineer Interview Experience — Order Matching Coding Round Plus a GenAI Manager Round
View report detailsPracHub editorial advice for the preparation topics above.
Treating the Superday as one combined score and banking on the afternoon behavioral rounds to make up for a weak technical morning.
Candidate reports describe the afternoon behavioral rounds as cancellable when the morning technical sessions do not meet the bar. Prepare as though every morning round is a separate gate: rehearse back-to-back technical problems without a long break, and keep a short reset routine for between rounds so one bad problem does not spill into the next.
Reaching the right idea in an IDE-based round but running out of time before the code runs, or never writing a test for it.
Reports describe coding in a real IDE where working code with unit tests is expected. Get a correct brute force running first, state its cost, and improve it with the working version still in place. Write two or three small tests as you build (empty input, one element, the example from the prompt), so that 'does it work' is answered by output rather than by assertion.
Guarding get() in the thread-safe LRU cache with a shared read lock, even though get moves the entry to the front of the recency list.
In an LRU cache every get is a write to the recency order, and with TTL it may also evict an expired entry. A read lock lets two readers relink the same list nodes at once. Start with one mutex over the map and the list, say that it serialises everything, and then discuss finer options, such as sharding by key or approximate recency, as trade-offs with their correctness cost stated. Apply the same discipline to the non-repeating random generator: the swap and the shrinking bound in a partial Fisher-Yates shuffle must happen under one lock.
On the currency conversion question, adding raw exchange rates along a path, or calling the no-revisit maximum path a shortest-path problem without qualification.
Rates multiply along a path. Take edge weights of -log(rate), and a product greater than 1 around a cycle becomes a negative cycle, which Bellman-Ford detects in O(V·E). When no such cycle exists, Bellman-Ford on those weights already gives the best conversion as a shortest path, which is simple, in polynomial time. Only when arbitrage (negative) cycles exist and the prompt forbids revisiting nodes does the question become a best simple path search, which is NP-hard in general. Say so, and use a DFS with a visited set when the currency count is small.
Rewriting a buggy tree map, BST or filtering iterator from scratch in a debugging exercise instead of locating the fault.
Reproduce the failure with a concrete input first, then narrow it down: which operation, which boundary case (deleting a node with two children, a missing parent-pointer update, a hasNext() that consumes an element when called twice). Explain the root cause, make the minimal fix, and leave the failing input behind as a unit test. A rewrite hides whether you understood the bug and can introduce new ones.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Given exchange rates between multiple international currencies, constr…
Given exchange rates between multiple international currencies, construct a graph traversal to detect currency arbitrage opportunities or compute the maximum output conversion path without revisiting nodes.
Approach
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
- Choose the data structure from the access pattern, not from familiarity.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Given a directed acyclic graph (DAG) representing trading accounts or …
Given a directed acyclic graph (DAG) representing trading accounts or dependencies, find the maximum set of nodes that do not share a direct edge relationship.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Given an $m \times n$ grid with obstacles, find the shortest path from…
Given an $m \times n$ grid with obstacles, find the shortest path from the origin $(0, 0)$ to a target destination $(x, y)$.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Implement a Huffman coding tree encoder and decoder, optimizing for tr…
Implement a Huffman coding tree encoder and decoder, optimizing for tree construction speed and bit-level string manipulation.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- Restate the input: its shape, its size, and what is guaranteed about it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Design an in-memory dynamic memory allocator (`malloc` and `free`) ope…
Design an in-memory dynamic memory allocator (malloc and free) operating over a fixed-size byte array, accounting for fragmentation and slotted allocation.
Approach
- Say what the runtime actually does before reasoning about the code.
- Distinguish a value from a reference to it, and say which one you handed out.
- Identify the window where an invariant is briefly untrue.
Follow-up
- How would you prove the race exists rather than suspect it?
- What happens if two callers reach this at the same time?
Write a thread-safe random number generator that guarantees unique, no…
Write a thread-safe random number generator that guarantees unique, non-repeating selections across a designated integer range without using standard library shortcuts.
Approach
- Name what is shared across threads and what owns each piece of state.
- Say what the runtime actually does before reasoning about the code.
- Identify the window where an invariant is briefly untrue.
Follow-up
- Where could this allocate more than you expect?
- What happens if two callers reach this at the same time?
Publish top instruments by traded notional every second
Fills stream in as (instrument_id, last_qty, last_px, contract_multiplier), with last_px an integer at the instrument's price_scale. Roughly 10^7 fills a day across 10^5 instruments. Publish the fifty instruments with the highest cumulative traded notional for the session, refreshed once a second, using exact integer arithmetic. Per-fill work must be O(1), and the per-second emit must not rescan all 10^5 instruments in the common case. Trade cancels and corrections can reduce an instrument's total. Give the accumulator width you need, and the argument that your pruning cannot drop a qualifying instrument.
Approach
- Size the accumulator before choosing the algorithm. A single fill of 10^6 lots at a price of 100 carried at price_scale 9 is 10^6 x 10^11 = 10^17 in scaled units, so an int64 session total overflows after about 92 such fills (9.22e18 / 1e17). Accumulate in int128, or rescale to a coarser notional unit at ingest and document the rounding; a double is out on the usual grounds, since it is exact only to 2^53.
- Per fill: one open-addressed hash map lookup on instrument_id, one 128-bit add, and an insert into a dirty set — O(1) expected, no allocation, no ordering work at all between emits.
- Per emit: maintain tau, the current fiftieth-largest total. Candidates are the previous top fifty plus the dirty instruments whose total exceeds tau. Select with a bounded min-heap of size 50, which is O(c log 50) for c candidates, and c is a few thousand per second rather than 10^5.
- State the precondition that makes the pruning sound: while totals only increase, an untouched instrument below tau cannot have crossed it, because nothing changed its value. Cancels and corrections break exactly that precondition, so a corrected instrument must enter the dirty set and, if it falls out of the top fifty, the replacement may be an instrument the pruning skipped.
- Close that hole rather than ignoring it: keep a reserve of the top 200 and refill from it when a member drops, falling back to a full O(m) quickselect over all 10^5 totals when the reserve is exhausted. The fallback runs rarely, is bounded, and is the reason the output is correct rather than usually correct.
- Report both costs: amortised O(1) per fill, O(c log k) per emit with an O(m) worst case, and note that the emit runs on its own thread off a snapshot so it never sits in the fill path.
Worked solution 30 min
- Compute the overflow point by hand for the worst realistic fill (qty 10^6, px 100 at price_scale 9) and confirm the count at which an int64 total wraps.
- Build a fixture of 20 instruments with k = 3, feed fills so totals are 100, 90, 80, 70, ... and record tau after the first emit.
- Send a fill of size 5 to the instrument at 70, taking its running total to 75, and confirm it is pruned without entering the heap because 75 is still below tau; then send a further fill of size 20 to that same instrument, taking it to 95, and confirm it now enters the heap and displaces the instrument at 80.
- Send a trade cancel that removes 30 from the instrument at 100 and confirm the reserve supplies the replacement rather than the pruned set being consulted.
- Drain the reserve deliberately with a run of cancels and confirm the quickselect fallback fires and returns the same answer as a brute-force sort.
Follow-up
- Make it a rolling five-minute window rather than a session total. What state does each instrument now need, and what does that do to memory at 10^5 instruments?
- Two instruments tie exactly at the fiftieth place. What is your tie-break, and why does an unstable one make the output non-reproducible in replay?
- The totals are in mixed currencies. Where does the FX conversion go, and what happens to the ranking when a rate updates mid-second?
Denormalising instrument attributes onto the position snapshot
A risk dashboard reads every open position for a desk once a second, roughly 50,000 rows, and each row needs price_scale, contract_multiplier and currency from instrument_version resolved as of now, plus a mark price. Today that is a range-predicate join per row against an effective-dated table. Propose a model that serves this read, state exactly which columns you copy and what makes the copy safe, and say what happens to yesterday's snapshot rows when a vendor correction changes an instrument version that was already in effect.
Approach
- Characterise the read before choosing a shape: 50,000 rows a second, attributes immutable within a version, versions changing at most daily for almost every instrument. Be accurate about why the as-of join costs what it does, because the tempting explanation is wrong. The join carries instrument_id equality alongside the effective-dating predicate, so the planner hashes or merges on that key and applies effective_from <= now() AND (effective_to IS NULL OR effective_to > now()) as a filter qual; a range predicate does not prevent a hash join. The real costs are that the scanned side is the whole version history rather than the single row per instrument actually in effect, that two correlated inequalities are a selectivity the planner estimates badly, and that the answer is recomputed every second while being constant for the entire business date. On 50,000 positions against 150,000 stored versions the hash join discards two rows for every one it keeps, and the per-row nested loop a bad estimate would choose instead costs 50,000 index descents and roughly three times the runtime.
- Prefer the middle option to either extreme. Materialize an as-of dimension once per business date, one row per (instrument_id, business_date) resolved at session start, and make the dashboard an equality join on that pair. The range predicate disappears without duplicating attributes onto every position row.
- If you do copy onto position_snapshot, copy price_scale, contract_multiplier and currency together with their provenance: the effective_from (or a version surrogate) of the instrument_version they came from. A denormalised copy without provenance cannot be audited, cannot be reconciled and cannot be replayed.
- Handle the intraday hazard explicitly instead of hoping: a corporate action effective mid-session changes contract_multiplier within a business date, so a per-date dimension is wrong for that instrument that day. Either key the dimension at a finer grain for affected instruments or fall back to the as-of join for them, and know which instruments those are from the corporate-action feed rather than from a support ticket.
- Answer the correction question the books-and-records way: a derived snapshot records what the system believed when it computed, so a later vendor correction does not rewrite yesterday's rows. It produces a new snapshot row or a break, which is the same principle that keeps eod_derived and eod_reconciled as separate rows rather than one mutable number.
- State the cost you accepted: writes amplify, the dimension build becomes a session-start dependency, and a missed rebuild serves yesterday's attributes silently, so the dimension needs a freshness assertion that fails the dashboard rather than a scheduled job and optimism.
Worked solution 25 min
- Measure the current as-of join with EXPLAIN (ANALYZE, BUFFERS) over 50,000 positions: record which join method the planner actually chose, how many version rows the scan discarded through the effective-dating filter, and the estimated-versus-actual rows on that filter.
- Build the per-business-date dimension with CREATE TABLE AS from the as-of query, and add UNIQUE (instrument_id, business_date).
- Re-run the dashboard query as an equality join against the dimension and compare timing, plan shape and the size of the side being scanned.
- Simulate a mid-session contract_multiplier change on one instrument and inspect what the dimension returns for it.
Follow-up
- The dashboard now wants 30 days of the same view. Does the per-date dimension still work, and what does the join key become?
- Where does mark_px live in your model, and what stops a stale mark from being indistinguishable from a fresh one?
- How large is the dimension, and does it fit in memory on the service that serves the dashboard?
Why the execution-report lookup stopped using its composite index
execution_report holds 4 x 10^9 rows with an index on (account_id, received_ts). The query WHERE account_id = $1 AND received_ts::date = $2 runs a sequential scan. A second query, WHERE venue_exec_id LIKE $1 || '%', also scans despite a btree on venue_exec_id VARCHAR(48) in a database with a non-C default collation. A third, WHERE account_id = $1 alone, scans and the planner is right to. Explain each, give the rewrite for the first (a business date is a venue-local concept, not a server-timezone one), and say what EXPLAIN output you would ask for.
Approach
- First query: received_ts::date wraps the indexed column in a function, so the index's second column can no longer bound a range and only the account_id prefix is usable. If that prefix is not selective, a sequential scan is the cheaper plan and the index was never going to help.
- Get the rewrite's boundaries right rather than just removing the cast. Casting timestamptz to date depends on the session's TimeZone setting, so the same query means different instants in different sessions. A business date is defined by the venue's calendar, so take the session open and the next open from that calendar and write received_ts >= $open AND received_ts < $next_open.
- If the cast semantics are genuinely wanted, index the expression: (received_ts AT TIME ZONE 'UTC')::date is immutable because the zone is a literal, so it can be indexed, while the bare ::date is only stable and PostgreSQL will refuse it. The cost is pinning the zone into the index definition.
- Second query: a default-collation btree cannot serve a prefix LIKE, because the collation's sort order is not the byte order the pattern match needs. Rebuild it with varchar_pattern_ops (or run the database in the C collation), and keep the plain index too if equality lookups still need collation-aware comparison.
- Third query: an index scan returning a large fraction of the table reads most of the heap in random order on top of the index, so the sequential scan is correct. The fix is a different layout, such as partitioning by session_date or a BRIN on received_ts over a naturally time-clustered table, not a different btree.
- Ask for EXPLAIN (ANALYZE, BUFFERS) and compare estimated against actual rows. A two-orders-of-magnitude estimate error points at stale or correlated statistics, which CREATE STATISTICS or a composite index can fix; an accurate estimate that still chooses a scan means the scan is the right plan and the question is wrong.
Follow-up
- The rewritten range query is still slow because one account-day is 200 million rows. What changes about the physical design?
- Before dropping an index you believe is unused, how do you establish that in production?
- When does BRIN on received_ts beat the composite btree here, and what breaks that assumption?
Capture a million events a second for later replay
The market data gateway receives on the order of 1,000,000 normalized events/second sustained across venues, roughly ten times that in the auction bursts, each 60 to 120 bytes with venue and receipt timestamps. Capture must record every message to an append-only store that a research run later replays through the same strategy build, and a single-instrument replay must not scan the whole day. Design the write path and the layout: partition key, how the writer stays off the decode path, what it does when storage falls behind, and how a reader proves nothing was lost.
Approach
- Size it before designing it. 1,000,000 messages/second at about 100 bytes is roughly 100 MB/s, about 2.3 TB over a 6.5-hour session before compression. A datacentre NVMe device sustains on the order of 1 to 3 GB/s sequential write, so sustained bandwidth is not the constraint; the constraint is that fsync, allocation and file creation are multi-microsecond to multi-millisecond events that must never land on the decode thread.
- Hand off through a preallocated single-producer single-consumer ring. The decoder writes into it and returns; a separate capture thread drains it and writes sequentially in batches, with group commit rather than a durability call per message. A crash then loses at most one batch, and the bound is a number you chose.
- Make the overflow policy explicit. Blocking the producer preserves completeness and stalls the feed handler, which is not acceptable inline; dropping preserves the feed and loses data. Drop, and record the loss in feed_channel_session (gap_count, unrecovered_msg_count) so a replay knows the recording is incomplete instead of reading it as a quiet market.
- Partition by (session_date, venue_mic) and sort by instrument_id inside each file so per-row-group min/max statistics let a single-instrument read skip most of it. Making instrument_id a partition column looks faster and is not: 1,000,000 instruments across 250 sessions is 250,000,000 partitions, and the listing and open cost exceeds the scan it was meant to avoid.
- Prove completeness structurally rather than by inspection. Per (venue_mic, channel_id, line) record first_seq, last_seq and received_msg_count; last_seq minus first_seq plus one minus received_msg_count is the loss on that line, computable without decoding a single payload.
Follow-up
- Research wants 300 concurrent replays of the same session date. What does that do to the read pattern, and what would you change in the layout?
- The capture thread runs 40 ms behind the feed every day between 09:30 and 09:32. Is that a bug?
- How would you keep raw wire bytes as well as normalized events without doubling write bandwidth?
Partial-failure contract for a batch order-entry endpoint
POST /v1/orders:batch accepts up to 500 orders from a portfolio rebalancer that wants one round trip into the opening auction. Some items will fail pre-trade risk; the venue session can drop mid-batch, leaving earlier items live. Design the response so the caller can act with no ambiguity. Decide whether the batch is atomic and defend the decision, specify what a retry of the byte-identical batch does, and say which HTTP status the envelope carries and why that status cannot express per-item outcomes.
Approach
- Reject atomicity and say precisely why: once an item is matched at the venue, undoing it is not a rollback but a new order-cancel or a closing trade, each with its own latency, its own rejections and its own market impact. An API that advertises all-or-nothing over a remote authority is lying about a guarantee it cannot implement.
- Split transport status from item status. The envelope returns 200 (or 207) meaning 'the batch was processed and here is what happened'; per-item results live in an array keyed by the caller's client_order_id, each carrying a class from the retryable/terminal/unknown taxonomy. A 4xx envelope over a batch where 380 orders are now live at the venue actively misinforms the caller.
- Use per-item idempotency keys, never a single batch key. A batch key makes a retry all-or-nothing again; per-item keys make a retry of the identical batch re-drive only what is unresolved, since accepted items replay their stored result and rejected items replay their rejection.
- Bound the request and the response: cap items at 500, enforce a server-side deadline, and on deadline return the decided items plus the remainder marked unknown rather than holding the connection open. Echo only the key and the outcome per item, not the full order, so the response size stays proportional to the batch and not to the payload.
- Handle the mid-batch session drop explicitly: items after the drop are unknown, never failed, and the response format must be able to carry a run of unknowns. The caller resolves those from the drop-copy stream or an order status query, and must not resubmit them.
- State ordering: if the caller depends on submission order (a hedge leg before its exposure leg), say whether the server preserves it, and if it does not, make that a documented property rather than an accident of concurrency.
Worked solution 40 min
- Write the request and response schemas, with the per-item result object fully typed.
- Write three scenarios (all accepted; 20 risk-rejected; session drops at item 200) and fill in the exact response for each.
- Trace a retry of the identical batch against the scenario-three response and count how many orders exist at the venue afterwards.
- Write the deadline behaviour and the size caps, with the reasoning for each number.
- Write the two sentences you would put in the API documentation stating that the batch is not atomic and what the caller must therefore do.
Follow-up
- The caller pipelines four batches without waiting. How do you apply backpressure, and what does the second batch see if the first is still in flight?
- Would you offer a streaming response so results arrive as decided, and what does that change about the retry story?
- How does the mass-cancel operation for this batch differ in contract from the batch submit?
Fix bugs in a custom filtering iterator designed to yield modular math…
Fix bugs in a custom filtering iterator designed to yield modular mathematical sequences from continuous data streams.
Approach
- Pick a bisection that eliminates candidates whichever way it turns out.
- Separate the trigger from the cause; the deploy is rarely the bug.
- Establish what changed and when, before forming any theory.
Follow-up
- What would you add now so this is faster to diagnose next time?
- How would you tell a cause from a coincidence here?
Debug a custom tree map data structure that fails on specific boundary…
Debug a custom tree map data structure that fails on specific boundary edge cases during concurrent insertion and deletion.
Approach
- Say what evidence would prove you wrong, then go and look for it.
- Establish what changed and when, before forming any theory.
- Pick a bisection that eliminates candidates whichever way it turns out.
Follow-up
- What would you add now so this is faster to diagnose next time?
- What would you look at first, and what would it rule out?
Roughly ninety minutes on weeknights with one longer weekend block. The plan cuts scope rather than compressing everything, on the assumption that one thing finished per night beats four half-started.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Online assessment: graph traversal and parsing
- From a blank file, write BFS for the reported grid shortest-path question (obstacles, from (0, 0) to (x, y)) and test a blocked origin, an unreachable target and a 1x1 grid.
- Model the reported currency question with -log(rate) edge weights, detect arbitrage as a negative cycle with Bellman-Ford, then write the no-revisit maximum path as a DFS with a visited set and state its worst-case cost.
- Do one timed set of two or three problems mixing string parsing and array manipulation, submitting a correct brute force for each before optimising any.
Deliverable: Two graph solutions that pass your own edge-case tests, plus one line per timed problem naming what slowed you down.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Trees, dynamic programming and backtracking
- For the reported maximum set of non-adjacent nodes, first ask whether the graph is a tree. If it is, write the include/exclude tree DP in O(n) (compare the bank question on pairwise strangers in an acquaintance tree); if not, state that it is maximum independent set, which is NP-hard.
- Implement Huffman encode and decode with a min-heap, with a deterministic tie-break, and test a single-symbol input and an empty string.
- Write the Trie-backed word search with pruning on dead Trie nodes, and remove found words so that duplicates are not reported.
- Solve the bank's at-most-k-transactions stock DP and write the state definition before the recurrence.
Deliverable: Four solutions, each with its complexity and a test for the edge case most likely to break it.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Systems: concurrency, memory and IPC
- Build a thread-safe LRU cache with TTL eviction: a hash map plus a doubly linked list under one mutex, with expiry checked on get. Then write one paragraph on what finer-grained locking would cost.
- Write malloc and free over a fixed byte array with block headers, first-fit search, splitting, coalescing on free and alignment, and test an allocation pattern that fragments memory.
- Write the non-repeating random generator as a partial Fisher-Yates shuffle under a lock, and state its memory cost for a large range.
- Write a short comparison of processes and threads and of shared memory, pipes, Unix domain sockets and message queues, and say when you would pick each.
Deliverable: Three working implementations with tests, plus a one-page IPC and concurrency note you can deliver aloud.
Practice prompt ↗Practice prompt ↗04Debugging code you did not write
- Have a friend plant bugs in a BST or tree map implementation (or plant them yourself and set it aside overnight), then find each one through a failing test before you edit anything.
- Debug a filtering iterator: check that calling hasNext() twice does not skip an element, that next() works without a preceding hasNext(), and that an exhausted or empty stream is handled.
- For every bug, write down the failing input, the root cause and the minimal fix, and keep the test in the file afterwards.
Deliverable: A log of at least four bugs, each with its failing input, root cause, one-line fix and a regression test.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Object-oriented and system design
- Design and implement the bank's price-time order matching problem: price levels in an ordered map with a FIFO queue per level, partial fills, and cancel by order id through an index.
- Sketch the reported in-memory database: table creation, key-value insertion and SELECT with several conditions, keeping parsing separate from predicate evaluation.
- Work through the design exercise on this page, 'Partial-failure contract for a batch order-entry endpoint', and compare your response schema with its expected result.
Deliverable: A tested matching engine, a class sketch for the in-memory database, and your batch-endpoint contract with its three scenarios filled in.
Practice prompt ↗Practice prompt ↗06Superday rehearsal
- Run a back-to-back mock of two or three technical problems from different categories (one graph or DP, one systems, one debugging or design) in an IDE, with tests and no long break.
- Use the coding exercise on this page, 'Publish top instruments by traded notional every second', as one of the problems, and check your pruning argument against its expected result.
- After each problem, write one line on what went wrong and then practise your reset routine before starting the next.
Deliverable: Mock notes naming the weakest moment in each problem, with one specific fix written under each.
Practice prompt ↗Practice prompt ↗07Behavioral stories and taper
- Map the reported prompts (a project from design to production, a disagreement with a senior lead, a production bug under deadline, why Two Sigma) to four of your own projects.
- Take each story three follow-up questions deep: what you did, why that and not the alternative, and what you would change now.
- Write a warm-up of one problem you can already solve from a blank file, and confirm the language options and coding environment with your recruiter.
Deliverable: A one-page story index mapped to the reported prompts, plus a warm-up and logistics card.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report behavioral rounds in the afternoon of the final stage, after the technical morning. The reported prompts are engineering stories: ownership of a complex project, a technical disagreement, a production bug under deadline, and your reasons for the role. Prepare a small number of projects that you can explain down to the code you changed and the alternative you rejected, because follow-up questions will push past the headline.
How do you handle technical disagreements with senior engineering lead…
How do you handle technical disagreements with senior engineering leads regarding system architecture or tool selection?
Approach
- Close with what you would do differently, concretely.
- State the situation in two sentences and spend the rest on the reasoning.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that again?
Own the postmortem for a stale-book quoting incident
A sequence gap hit both the A and B lines of one venue channel at 09:31. Recovery was requested but never completed, the book stayed marked ok, and a strategy quoted against phantom levels for 14 minutes. Take the on-call role. Describe an incident you owned of comparable blast radius: how it was detected, how you bounded which instruments and orders were affected, what you stopped first, and what the loss was. Give a wall-clock timeline, the query that sized it, and the one change that would have caught it sooner.
Approach
- Open with the invariant that broke rather than the symptom: no order is priced off a book with a known, unrecovered gap. The invariant tells the listener what to count; 'we got bad fills' does not.
- Bound the population with a stated query, not an adjective. From feed_channel_session, the rows for that (venue_mic, channel_id, session_date) on both lines where unrecovered_msg_count > 0 give the window; join order_event on instrument_id where sent_ts falls between the first gap and the recovery. The finding that matters is that book_state read 'ok' throughout — the gap was the event, the unchanged state flag was the bug.
- Separate mitigation from fix and say which came first. Mitigation is blunt and needs no deploy: force the channel's book_state to stale, pull quotes, and cancel resting orders — resting orders keep trading while you are deciding, which is the part people forget. Making detection structural per line is not an incident-window change.
- Size the loss with a method attached: replay the capture, rebuild the book with the gap recovered, and remark the fills against that. State what you cannot attribute — some of the adverse selection in those 14 minutes would have happened anyway — because a loss number that claims everything is not believed.
- Name one detector with a threshold and a cost, not five. max_interarrival_us exceeding the venue's heartbeat interval catches a silent line; per-line sequence continuity catches a lossy one. Say which you shipped and its expected false pages per week.
- Name your own error inside the response window — the wrong hypothesis you held for 20 minutes, or the mitigation that made it worse. That is the part candidates rehearse away and interviewers weight most.
Follow-up
- Resting orders kept trading while you were deciding. What is the policy: cancel on stale, or leave them and stop adding?
- Recovery completed but the book could still be wrong. How do you prove a reconstructed book is correct before you quote off it again?
- What do you tell risk about the portion of the loss you cannot separate from ordinary adverse selection?
Reverse a simulator fill model after live results diverged
Your backtest fills a passive order whenever the market trades at its price. Two strategies approved on that model reached production and filled at roughly a third of the simulated rate, turning a projected edge into a loss. Describe a decision you reversed. State what you originally believed and why it was reasonable, the evidence that changed your mind, what reversing cost — including work discarded and strategies withdrawn — and how you made the replacement trustworthy rather than merely newer. Say what you would have measured earlier to shorten the gap.
Approach
- State the original model's appeal honestly before demolishing it: it is cheap, it needs no order-level data, and it is close to right for aggressive orders. The reversal is about scope, not about anyone being foolish.
- Name the mechanism rather than the symptom. A passive order fills only once the quantity resting ahead of it at that price level has traded or cancelled. Touch-the-price assumes queue position zero — the most optimistic assumption available — and it is biased in exactly one direction, which is why the error never showed up as noise.
- Give the comparison you ran: the same recording through both models, reporting fill rate and per-fill P&L, and the ratio of simulated to live fills over the same period. One reproducible ratio on one recording is the evidence; the two withdrawn strategies are its consequence.
- Own the replacement's residual error. A queue model needs the quantity ahead, and at price-level depth you cannot observe cancellations ahead of you, so your estimate is itself wrong — state the direction of that error. A candidate who claims the new model is correct has repeated the original mistake in a more expensive form.
- Describe how you made the reversal stick: re-run the already-approved backlog through both models and publish the per-strategy delta, so the reversal arrives as a number every strategy owner can see rather than as a memo they can ignore.
- Close on the earlier measurement. The live-versus-simulated fill ratio is computable in the first days of any passive strategy; tracking it from day one turns a six-month surprise into a two-week correction.
Follow-up
- Price-level data hides cancellations ahead of you. How wrong can your queue estimate be, and in which direction?
- How do you stop the new model being tuned until it happens to reproduce the live result?
- What does the reversal imply for strategies that were rejected under the old model?
- 01
Describe a complex technical project you drove from initial design to production deployment, highlighting your key architectural decisions.
- 02
How do you handle technical disagreements with senior engineering leads regarding system architecture or tool selection?
- 03
Tell me about a time you encountered a production bug under tight deadlines. How did you diagnose the issue and prevent future occurrences?
- 04
Why do you want to join Two Sigma, and how does quantitative financial engineering align with your career interests?
- 05
Explain why you are making this move and walk through a recent project in technical detail.
- 06
Describe a decision you reversed: what you originally believed, the evidence that changed your mind, and what reversing it cost.
Is this an official Two Sigma interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Two Sigma. Rounds and questions reflect what candidates have reported, not a process Two Sigma has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What do the coding rounds expect you to produce?
Candidate reports describe coding in a real IDE, with code that is expected to run and come with unit tests, rather than pseudo-code on a whiteboard. Practise in an editor you can run code in, get a correct version working before optimising, and write small tests as you go: an empty input, a single element and the example from the prompt. Ask your recruiter which environment you will use so its shortcuts are not new on the day.
PracHub Software Engineer practice ↗Which programming language should I use for the coding interviews?
Prepare in the language you can debug fastest. Under a clock, an unfamiliar language costs you standard-library lookups and iteration mechanics, and that time comes out of your problem-solving time. Language expectations can differ by team, so confirm them with your recruiter early, especially if you are interviewing for a low-latency or infrastructure team.
PracHub interview research ↗Do I need finance knowledge to pass the engineering interview?
Some reported questions use financial settings such as order books, exchanges and currency tables as context, but the problems underneath are algorithms, object-oriented design and systems engineering. Spend your preparation time on those. Know the vocabulary well enough not to stall on it: what a limit order is, what price-time priority means, and why an exchange rate multiplies along a path. If you are unsure whether a particular team expects domain background, ask your recruiter.
PracHub interview research ↗What if I do not finish the complete solution in a technical round?
The sources stress producing functional code with passing tests, and they report that candidates who do not reach working code rarely move forward. The best protection is structural: confirm the requirements briefly, get a correct brute force running early, and improve it only while the working version stays in place. A running, tested simple solution with a stated plan for improving it is a stronger position than an unfinished optimal one.
PracHub interview research ↗What happens if the morning technical rounds go badly?
Candidate reports describe a morning gate at the final stage: if the morning technical sessions do not meet the bar, the afternoon behavioral rounds may be cancelled. Treat each morning round as its own gate, rehearse several technical problems back to back, and prepare your behavioral stories beforehand anyway, since you will not know in advance whether the afternoon goes ahead.
PracHub Software Engineer practice ↗Which question categories should I prioritise?
Across the reported questions, the recurring categories are graph traversal and dynamic programming (grid shortest path, currency conversion, non-adjacent node sets, Huffman coding, Trie word search), systems and concurrency (LRU cache with TTL, allocator over a byte array, non-repeating random generator, processes versus threads and IPC), object-oriented design (order matching, an in-memory database) and debugging of data structures. The seven-day plan on this page gives each category its own day.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
Point72 Software Engineer Interview Guide
Testing exercises for Point72 software engineer prep: choosing boundary cases over repetition, isolating tests from shared clock and ordering, and treating an intermittent failure as a defect rather than noise.
Jane Street Software Engineer Interview Guide
API design practice for Jane Street software engineer prep: which changes existing clients survive, how an optional field differs from a removed one, and what a contract costs once it is public.
Hudson River Trading Software Engineer Interview Guide
Database practice for Hudson River Trading candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.
IMC Software Engineer Interview Guide
API design practice for IMC software engineer prep: which changes existing clients survive, how an optional field differs from a removed one, and what a contract costs once it is public.