Drw · Software Engineer
Updated · 2026-09-24

Drw Software Engineer
Interview Guide

THE 60-SECOND BRIEF

Drw is a principal trading firm, so its software is the business itself rather than a product sold to outside users. Software Engineers there build systems that connect to exchanges, calculate real-time risk, process market data streams and run quantitative trading strategies across equities, fixed income, commodities and cryptoassets. Teams range from C++ and Rust engineers working on exchange gateways and execution systems to C#, Java, Python and Clojure engineers building analytics platforms and trading tools.

This guide covers the four stages candidates report: a proctored online assessment, a technical phone screen, a take-home coding project that some teams skip, and a Superday of back-to-back technical sessions. It groups the reported questions by category (coding and algorithms, low-level systems and language internals, CS fundamentals and networking, system design, behavioral) and turns them into a seven-day plan. The questions are candidate reports, not a published process, so check the format with your recruiter.

Drw candidates report 4 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Bound every outbound call with a timeoutTrace a symptom to a mechanism under loadPaginate large result sets with keyset cursors

37 min read

Practice 16 Software Engineer prompts
5Company bank questionsSnapshot · Sep 26, 2026 PT
11Candidate experiences ↗Read their reports
16Practice promptsAcross five skill areas
3With worked solutionsIncluded in the practice prompts

A Software Engineer at Drw builds the systems trading runs on: exchange connectivity, real-time risk calculation, market data processing and the execution of quantitative strategies across equities, fixed income, commodities and cryptoassets. Engineers may sit on an algorithmic trading desk, the Unified Platform team, or front- and middle-office analytics groups, and they work alongside quantitative researchers, traders and infrastructure engineers.

The language spread is wide: C++ and Rust for exchange gateways and execution systems, and C#, Java, Python and Clojure for distributed analytics platforms and trading tools. That spread shows up in the reported questions. Some are language-neutral algorithms, and others ask how a vtable dispatches a call, how the JVM allocates and collects objects, or how a mutex and a condition variable are built.

For preparation, expect the reported questions to go below the level of "it works". Reported topics include virtual memory and process address spaces, thread synchronization primitives, CPU cache locality, the TCP handshake and socket buffers, and designs such as an order execution engine or a trade logging service that must not lose data in a crash. Pick one primary language and learn its runtime and standard library well enough to explain what your code does in memory, not only what it returns.

01

Online Assessment

reported

Candidates describe a proctored online assessment on Codility or HackerRank, with video and microphone enabled, that tests algorithmic problem solving, array manipulation and dynamic programming. PracHub's bank has two Drw entries framed as sets of algorithmic OA tasks, and other reported Drw coding problems in the bank include digit-string problems with even-count constraints, an odd-string task, a digit swap and a slot-assignment problem. Practise as if you cannot look anything up: standard-library calls, loop bounds and DP recurrences should come from memory, and the camera and platform setup should not be new to you on the day.

What to demonstrate

  • Algorithmic problem solving and array manipulation, the areas candidates name for this stage
  • Dynamic programming: whether you can define the state, write the recurrence and turn it into an iterative table without a reference
  • Correctness on edge inputs such as empty arrays, a single element, repeated values and values at the edge of the input range

How to prepare

  • Solve a few array problems and one of the bank's digit-string problems in a browser editor with the camera on and no other windows open, so the proctored setup is familiar before the real one
  • Write three DP problems from a blank file, including a stock buy-and-sell variant, stating the state, the transition and the base case before writing any code
  • For every failed submission, write down the smallest input that fails and its expected output before you edit anything
PracHub interview research ↗
02

Technical Phone Screen

reported

Candidates describe a technical phone or video call with an engineer or a hiring manager covering core CS fundamentals, memory layout, language details and a review of past technical work. The reported low-level and fundamentals categories fit that description: virtual memory and address spaces, vtables and their overhead, how mutexes, condition variables and atomics work, JVM allocation and garbage collection, process scheduling and context switches, and cache locality. Prepare each answer as a mechanism, a cost and an example that ties the two together.

What to demonstrate

  • Whether you can explain the mechanism under a language feature (dynamic dispatch, heap allocation, a lock) instead of naming the feature
  • Grasp of memory layout: stack versus heap, virtual-to-physical translation, and why contiguous data is faster to scan than linked data
  • Whether your account of a past project names your own decisions and the trade-offs behind them

How to prepare

  • For each reported low-level question, write a spoken answer with three parts: what the runtime or OS does, what it costs, and one situation where that cost matters
  • Pick the one language you will be questioned in and review its standard containers: layout, growth policy, iterator invalidation, and the complexity of each operation
  • Prepare a walkthrough of your most technical project that names two decisions you made, the options you rejected and what each one would have cost
PracHub interview research ↗
03

Take-Home Coding Project

reported

Candidates report that, depending on the team, some get a take-home project, with examples such as a game engine variant, an execution bot or a data processor, while others go straight to the Superday. Candidates also describe the Superday as including a code review of the take-home, so expect to discuss the submission and be ready to change it for a new requirement. Make naming, module boundaries, boundary tests and extensibility easy to see in what you submit, and treat it as code you will have to modify in front of someone, not just code that passes.

What to demonstrate

  • Idiomatic style in the language you were asked to use: naming conventions, small functions and a clear module layout
  • Test coverage that reaches boundary conditions, not only the example in the prompt
  • Whether the design can take a new requirement, such as streaming input instead of a batch, without a rewrite

How to prepare

  • Before submitting, list the two changes a reviewer is most likely to ask for and check that each one touches a single module
  • Write tests for empty, single-element, duplicate and malformed inputs, then break the code on purpose and confirm at least one test fails
  • Include a short README covering your assumptions, what you left out and why, and how to run the tests
PracHub interview research ↗
04

Superday / Onsite Interview

reported

Candidates describe the Superday as several back-to-back technical sessions: live whiteboard or paired coding, a code review of your take-home if you had one, system design, and behavioral conversations with team members and leadership. Reported design questions include an object-oriented order execution engine handling thousands of quotes per second, a risk and P&L schema and API for historical and what-if scenarios, a low-latency trade logging service that must lose nothing in a crash, and a lock-free queue for dispatching orders across threads. Reported behavioral questions ask about your most complex project, debugging a production issue under time pressure, ambiguous requirements from traders or researchers, and why principal trading interests you.

What to demonstrate

  • Object-oriented design with clear class responsibilities, interfaces and error handling for a trading-style component
  • Thread safety and durability: who owns shared state, and what has to be written and flushed before a trade counts as recorded
  • Whether you can extend or defend your take-home code live when the requirements change
  • How clearly you explain trade-offs in past work and handle ambiguous requirements

How to prepare

  • Design the order execution engine from the reported question on paper: the classes, the threading model, and where a lock or a queue sits on the hot path
  • For the trade logging question, explain step by step what happens to a record between the API call and durable storage, and which crash each step survives
  • Practise two design problems and a coding problem back to back, so the multi-session format is not new on the day
  • Prepare the four reported behavioral stories with a concrete decision and an outcome in each
PracHub interview research ↗

11 candidate reports. Individual accounts describe a particular role and hiring cycle.

Quantitative Researcher

DRW New Grad Quantitative Researcher Interview Experience — Auto-Rejected Before the OA Deadline Even Hit

Online AssessmentOutcome: rejected

I cold-applied online to DRW's US New Grad Quantitative Researcher role. Less than a week after applying, I got an online assessment invite. The email said the OA link would expire in seven days, and there was no other deadline notice anywhere. Then, five days later, I got an email saying I hadn't finished the OA in time, and I was flat-out rejected. But the OA link was still valid, so I went ahe…

Read full experience
Software Engineer

DRW New Grad Software Engineer Interview Experience — A Greedy String-Parity Coding Problem

Other

I ran into a greedy string problem. Given a string digits made up only of the characters '1' and '2', representing a positive integer, you can delete zero or more characters. After deleting, the requirements are: The remaining '1's must appear an even number of times. The remaining '2's must also appear an even number of times. Subject to those two conditions, the resulting integer should be as l…

Read full experience
Software Engineer

DRW New Grad Software Engineer Interview Experience — A Greedy Deletion Problem on a String of 1s and 2s

HR Screen

I got a string greedy problem: Given a string digits made up only of '1' and '2', which represents a positive integer. You can delete 0 or more characters from it, and after the deletion: the number of remaining '1's must be even; the number of remaining '2's must also be even; and, while satisfying those first two conditions, the final integer should be as large as possible. Note that you can on…

Read full experience
Customer Success Engineer

Drw Customer Success Engineer interview: Three back-to-back interviews followed by a location rejection

HR Screen → Other

I started with an internal recruiter reaching out about a very senior trade support type of role. My first call was with HR, and it felt like it went well. I then spoke with the hiring manager about my background, the team, and what the role involved. The conversation felt a little unfocused on their side, but it was still decent overall. The role I initially interviewed for didn't work out becau…

Read full experience
Software Engineer

Drw Software Engineer interview with a one-hour coding assessment

Online Assessment → OtherOutcome: rejected

The process began with an online coding assessment that took me about an hour, even though it was described as a roughly two-hour test. I felt confident after finishing it, but I didn’t hear anything afterward and received a rejection notification a couple of days later. I also interviewed with DRW for a technical role in Singapore, and that process took much longer than I expected. I completed e…

Read full experience

PracHub editorial advice for the preparation topics above.

01

Losing online-assessment time to the proctored platform instead of the problems

Candidates report Codility or HackerRank with video and microphone on. Beforehand, solve problems in a browser editor with the camera running and no other windows open, and make sure you can write sorting with a custom comparator, string splitting and your DP table setup without looking anything up. When a test fails, find the smallest failing input before you change code.

02

Answering a low-level question with the feature name instead of the mechanism

"Virtual functions give polymorphism" does not answer the reported vtable question. Explain where the vptr is stored, what the indirect call costs, and why it blocks inlining. Apply the same standard to virtual memory (page tables, address translation), JVM allocation (the allocation fast path, what a GC pause does to tail latency) and locks (what happens when a mutex is contended). Prepare each answer as mechanism, cost and example.

03

Submitting a take-home that passes but is not idiomatic, tested or extensible

Aim for idiomatic code, not only correct code. Follow the style conventions of the language you were given, separate parsing, core logic and output, test the boundaries, and keep the code modular enough that a live change for streaming input touches one place. Candidates describe a code review of the take-home during the Superday, so every shortcut is something you may have to explain.

04

Designing the order engine or trade logger without saying who owns shared state or when data is durable

For the reported execution engine and lock-free queue questions, state which thread owns each structure and how work moves between threads, whether through a single-writer queue, a lock or atomics. For the zero-data-loss logging question, say exactly when a record counts as written: appended, flushed to disk, and acknowledged. A design that skips these points does not answer the question as asked.

05

Describing your most complex project as team output with no decisions of your own

A reported behavioral question asks specifically about your own architectural choices and trade-offs. Choose two decisions you made, the alternatives you rejected, what each would have cost, and what you would change now. For the production-debugging question, give the symptom, the first thing you checked and why, and how you confirmed the fix.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

13 technical prompts3 include a worked solution

Implement a custom binary search tree traversal or serialization metho…

medium
data structures and algorithms

Implement a custom binary search tree traversal or serialization method from scratch without relying on external libraries.

Approach
  1. Name the brute-force solution and its complexity before improving on it.
  2. State the target complexity and say which constraint rules the naive version out.
  3. 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?
  • Which test case would catch an off-by-one here?

1–2 sentences introducing the category and what it tests. This categor…

medium
data structures and algorithms

1–2 sentences introducing the category and what it tests. This category evaluates your ability to translate complex logic into clean, efficient code under time constraints, with a focus on data structures, time complexity, and edge case handling.

Approach
  1. Choose the data structure from the access pattern, not from familiarity.
  2. Walk one small example through your approach before writing the whole thing.
  3. Restate the input: its shape, its size, and what is guaranteed about it.
Follow-up
  • Which test case would catch an off-by-one here?
  • What is the worst case, and how likely is it on real data?

How does the Java Virtual Machine (JVM) manage object allocation in he…

medium
languages, concurrency and fundamentals

How does the Java Virtual Machine (JVM) manage object allocation in heap memory, and how does garbage collection impact application latency?

Approach
  1. Distinguish a value from a reference to it, and say which one you handed out.
  2. Identify the window where an invariant is briefly untrue.
  3. Say what the runtime actually does before reasoning about the code.
Follow-up
  • How would you prove the race exists rather than suspect it?
  • Where could this allocate more than you expect?

Explain the difference between virtual memory, physical memory layout,…

medium
languages, concurrency and fundamentals

Explain the difference between virtual memory, physical memory layout, and process address spaces in C++.

Approach
  1. Reach for the cheapest primitive that closes the race, not the broadest lock.
  2. Name what is shared across threads and what owns each piece of state.
  3. 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?

Find overlapping job attempts and peak concurrency from lease records

mediumWorked solution
sweep lineintervalsleases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach
  1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
  2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
  3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
  4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.
  5. State the clock caveat: started_at and finished_at are written by different workers, so under skew of a few hundred milliseconds an apparent overlap shorter than that bound is not evidence. Filter reported overlaps by a minimum duration, or prefer timestamps written by whichever component heartbeats the lease.
  6. Scale the sort rather than assuming it fits: the sweep emits two endpoints per attempt, so 50,000,000 records become 100,000,000 endpoints, and at roughly 24 bytes each, an 8-byte timestamp plus a 4-byte job_type plus a kind flag padded to alignment, that is about 2.4 GB of sort keys before any scratch space. Either push the ordering into the database behind an index on (job_type, started_at) or run an external merge sort in chunks; the overlap pass sorts n records rather than 2n, so it is the cheaper of the two.
Worked solution 30 min
  1. Write the interval derivation with the COALESCE and state in one line which of the two end sources is observed and which is assumed.
  2. Write the concurrency sweep: the endpoint tuples, the sort key including the end-before-start tie-break, and the per-job_type counter.
  3. Hand-trace four attempts of one job, two disjoint and two overlapping by three seconds, and confirm the overlap detector fires exactly once.
  4. Add the skew filter as a minimum overlap duration, state the value you chose, and justify it from how the timestamps are written.
EXPECTED RESULTOne global sort by (job_run_id, started_at) driving a running-maximum-end check for overlaps, plus a sweep over 2n endpoints with ends ordered before starts for per-job_type peak concurrency, both O(n log n), with half-open intervals, NULL finished_at falling back to lease_expires_at, and overlaps shorter than the clock-skew bound excluded.
Follow-up
  • A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
  • Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?
  • How would you compute both answers incrementally as records arrive rather than in a daily batch?

Four days sample coding, design, fundamentals and the practical rounds at deliberately shallow depth, which is enough to surface the topics you did not know were in scope. That map, rather than a guess made on day one, decides where the last three days go.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Online assessment: arrays and dynamic programming
  • Solve three array problems of the reported kind, such as finding non-overlapping sub-regions that meet a constraint, and a digit-string problem with even-count constraints like the Drw coding entries in PracHub's bank
  • Write a stock buy-and-sell DP from a blank file, stating the state, transition and base case before coding
  • Record every standard-library call you had to look up and drill each one until you can write it from memory

Deliverable: Four solved problems, a written DP state definition, and a list of library calls you can now write without a reference.

Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗
02Online assessment: trees, grids and a proctored mock
  • Implement BST serialization and deserialization from scratch, plus an iterative DFS over a grid that computes connected-component bounds
  • Run a timed mock in a browser editor with the camera on and no other windows open, covering one array, one DP and one graph problem
  • For each failure, write the smallest failing input, the expected output and the actual output before fixing it

Deliverable: Working serialization and grid DFS code, and mock notes listing each failing input you isolated.

Practice prompt ↗Practice prompt ↗Practice prompt ↗
03Phone screen: memory, runtimes and the language you will be tested in
  • Write spoken answers to the reported questions on virtual memory and address spaces, vtables and their overhead, and JVM allocation and garbage collection, each covering mechanism, cost and example
  • Review your chosen language's main containers (for C++, vector and unordered_map; for Java, ArrayList and HashMap): layout, growth, and the complexity of each operation
  • Compare arrays, linked lists and hash maps on memory layout and cache behavior, one paragraph each

Deliverable: A one-page answer sheet for the low-level category that you can say aloud without reading.

Practice prompt ↗Practice prompt ↗
04Phone screen: concurrency, OS and networking
  • Explain how a mutex, a condition variable and an atomic compare-and-swap work, and what a contended lock costs
  • Answer the reported fundamentals questions: process scheduling and context-switch overhead, cache locality, the TCP three-way handshake, and how socket buffers and window sizes affect delay
  • Rehearse a walkthrough of your most technical project that names two decisions you made and the trade-offs behind them

Deliverable: Written answers for the concurrency and networking questions, plus a rehearsed project walkthrough.

Practice prompt ↗Practice prompt ↗Worked solution ↗
05Take-home: build it to be changed
  • Build a small data processor or execution-bot core in your primary language, keeping parsing, logic and output in separate modules
  • Test empty, single, duplicate and malformed inputs, then break the logic on purpose and confirm at least one test fails
  • Change the design live to accept streaming input instead of a batch, and note which files you had to touch

Deliverable: A small tested project with a README of assumptions, and a note on what the streaming change required.

Practice prompt ↗Practice prompt ↗
06Superday: system design
  • Design the reported object-oriented order execution engine: classes, interfaces, threading model and error handling
  • Explain the reported zero-data-loss trade logging service, stating exactly when a record counts as durable and which crash each step survives
  • Sketch a thread-safe, lock-free queue for order dispatch and name the memory-ordering guarantees it relies on
  • Work the guide's outbox relay design exercise for at-least-once delivery and deduplication

Deliverable: Three design sketches, each with a stated ownership model and durability point.

Practice prompt ↗Practice prompt ↗
07Superday rehearsal: back-to-back sessions and behavioral
  • Run a coding problem, a design problem and a behavioral block back to back with no break
  • Prepare stories for the reported behavioral prompts: most complex project, a production issue debugged under time pressure, ambiguous requirements from traders or researchers, and why principal trading
  • Read the debugging drill on a slow endpoint stalling a shared pool and explain the saturation mechanism aloud

Deliverable: Notes from the back-to-back mock and four behavioral stories, each with a decision and an outcome.

Practice prompt ↗Practice prompt ↗Worked solution ↗

Expand any day for tasks and deliverables. Your progress is saved on this device.

The reported behavioral questions for this role ask about your own architectural choices, how you debugged a production problem under time pressure, how you handle vague requirements from traders or quantitative researchers, and why principal trading fits your goals. In each story, name a decision you made, the alternative you rejected, and what happened.

How do you handle ambiguous project requirements when building tools f…

medium
behavioural and engineering judgement

How do you handle ambiguous project requirements when building tools for traders or quantitative researchers?

Approach
  1. State the situation in two sentences and spend the rest on the reasoning.
  2. Give the blast radius: what could have broken, and what you measured.
  3. Pick a story where you made the decision, not one where you watched it.
Follow-up
  • How did you know your change caused the improvement?
  • What would you do differently if you ran that again?

Unblock an engineer without taking the keyboard

easy
mentoringleasesat-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach
  1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
  2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
  3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
  4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.
  5. Close on the systemic gap that let two days pass, which is usually a missing dashboard for attempt counts or an undocumented at-least-once contract, and fix that rather than only the bug.
Follow-up
  • How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
  • Their handler calls an external endpoint before recording that it did. What do you tell them to change first?
  • What do you do the third time the same person brings you the same class of bug?

Ship under a deadline and bound the debt you chose

medium
paginationtechnical debttradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach
  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.
  5. Report what actually happened in your real example, including the case where the trigger never fired and the debt was correctly never repaid.
Follow-up
  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?
  • Who would have overruled you if you had asked for two more days, and did you ask?
  • 01

    Walk through the most technically complex project on your resume, focusing on your own architectural choices and trade-offs.

  • 02

    Describe a time you debugged a critical production issue under tight time constraints. What did you check first, and why?

  • 03

    How do you handle ambiguous project requirements when building tools for traders or quantitative researchers?

  • 04

    Why do you want to work at Drw, and how does principal trading fit your technical career goals?

  • 05

    Explain an architecture decision you made, the options you rejected, and what you would change now.

  • 06

    How would you handle a production incident in a live trading system: what you prioritize, who you tell, and when?

PracHub interview preparation framework ↗
Is this an official Drw interview guide?

No. It is PracHub's own research and practice material for the Software Engineer role at Drw. Rounds and questions reflect what candidates have reported, not a process Drw has published, and they change over time. Confirm the current format and scope with your recruiter.

PracHub interview research ↗
How much of the Drw interview is algorithms versus low-level knowledge?

Both appear in the reported questions. The coding category includes array sub-region problems, BST traversal or serialization, a stock buy-and-sell DP and grid DFS. Separate categories cover memory layout, vtables, synchronization primitives, JVM garbage collection, OS scheduling and networking. Prepare both instead of assuming the algorithm rounds are the whole bar.

PracHub interview research ↗
Can I use any programming language?

Candidate reports suggest you can usually choose your language for online assessments and general algorithm rounds, while team-specific sessions and low-level infrastructure roles may use the team's main language, such as C++ for low-latency execution work. Ask your recruiter which language the team uses and learn its runtime and standard library in depth.

PracHub interview research ↗
How should I approach the take-home coding project?

Treat it as production code: clean, idiomatic, sensibly structured, attentive to performance, and tested at the boundaries. Candidates describe the Superday as including a code review of the take-home, so be ready to defend your choices and change the code live for a new requirement. Keep it modular and write down your assumptions.

PracHub interview research ↗
Does every candidate get a take-home?

Not according to candidate reports. Depending on the team, candidates either get a take-home project, with reported examples including a game engine variant, an execution bot and a data processor, or go straight to the Superday. Ask your recruiter which path applies to you.

PracHub Software Engineer practice ↗
Do I need prior trading or finance experience?

Most reported questions cover CS fundamentals, language internals and design. A few, such as the risk and P&L sensitivities schema for historical and what-if scenarios, assume basic trading concepts. Put most of your preparation into the fundamentals, and learn enough about P&L and risk sensitivities to reason about that kind of design question. One reported behavioral question also asks why principal trading fits your goals, so have a specific answer ready.

PracHub interview research ↗
Sources & methodology 3 sources ↗

Official role evidence, timestamped platform data and clearly labeled preparation advice.