Capital Markets Technology Interviews: A Masterclass for Engineers and Architects

What it is

A capital markets technology interview is an assessment of whether you can build software inside a domain where the software is not the system of record for anything that matters. The system of record is a chain of legal obligations that exists independently of your code: a trade is an agreement between two parties, a cleared position is a contract with a clearing house, and a settled delivery is a movement on the books of a depository. Your service holds a representation of those things. When the representation and the obligation disagree, the obligation wins, and your firm carries the difference.

That asymmetry generates almost every question you will be asked, and it is why an interviewer will not accept "we retry the operation" for a failed settlement or "we roll back the deployment" for a routing bug that traded. The domain is not unusually hard algorithmically. It is unusually unforgiving about the difference between an operation you can repeat and an act you cannot take back.

flowchart TD
    accDescr: The trade lifecycle from order capture and risk checks through routing and execution, allocation and confirmation, and clearing and novation, to settlement versus payment, with the branch at delivery where ownership transfers and is serviced if delivery is made, and otherwise the fail stays open with claims and buy-in.
    A[Order capture and risk checks] --> B[Routing and execution]
    B --> C[Allocation and confirmation]
    C --> D[Clearing and novation]
    D --> E[Settlement versus payment]
    E --> F{Delivery made}
    F -->|Yes| G[Ownership transferred and serviced]
    F -->|No| H[Fail stays open with claims and buy-in]

The branch at the bottom is where the domain gets its character: the failure path is not an error state to be retried but a parallel life the trade can lead for days, with its own costs, claims and remedies, and roughly half the questions in an interview live on it.

The surface is wider than most engineers expect, because the lifecycle crosses more organisational boundaries than a typical product does: front office for order entry, routing, algorithms, market data and pre-trade risk; middle office for allocation, confirmation, position keeping, valuation, margin and reporting; back office and custody for settlement, corporate actions, income, lending and reconciliation against external agents. An architect is expected to hold the whole chain and know where the seams are, and a senior engineer to hold their own segment properly and know which segment their errors land in.

The four shapes a question arrives in

Concept questions check that you are not fluent in words you cannot define. "What does novation change?" is not trivia; it decides whether the rest of the conversation about default risk is possible. Scenario questions put you at a moment of failure and watch you order your steps: settlement morning with nothing to deliver, a fill for a cancelled order, a payment a hundred times its usual size. Design questions ask for something whose correctness is externally observable, such as an order book, a limit-check path or a reference-data store, and grade invariants rather than throughput. Case-study and judgement questions put you between a desk that wants a change today and a control process that says three days, and grade whether you can hold both without capitulating or hiding behind the process.

Most interviewers mix all four in an hour, and the transitions are deliberate. A confident but shallow concept answer invites a scenario that breaks it, and a scenario answer that reaches for the right control invites a design question about implementing it. If your answers keep pulling the interviewer deeper rather than sideways, the interview is going well.

What sits underneath the vocabulary

Three ideas recur so often that they are effectively the syllabus. The first is the distinction between an obligation and a record of one. An execution creates an obligation to deliver or to pay, everything until settlement exists to make its discharge certain, and your data model has to say what is owed, to whom, on what date, at what place, in a state that includes "overdue" as normal rather than as an error. The equity order lifecycle from the click to settlement is asked so often because it forces a candidate to name where the counterparty changes and where reversibility ends.

The second is that time here is calendar time. A settlement cycle counts business days on a specific market's calendar; a corporate action's ex, record and payment dates are set by an issuer and cannot be renegotiated; a report deadline runs from trade date; a margin call has a cut-off after which non-payment is a default rather than a delay. Systems that model time as a duration since an event, rather than as a position on somebody else's calendar, fail in ways that look like off-by-one bugs and behave like breaches.

The third is that evidence is a first-class output. You will be asked what you submitted, when, on what basis, and what you believed at the time, and an architecture that answers by reading current state has already lost the argument. That is why append-only trade stores, dated reference data and archived submissions surface in interviews that appeared to be about something else, and why point-in-time price history is a design concern rather than a data-quality complaint.

Why we need it

A domain-specific interview exists because general engineering judgement gives the wrong answer here often enough to be dangerous, and the wrong answers are the confident ones.

Take idempotency, which every backend engineer treats as solved. Resending a NewOrderSingle after a timeout is not a safe retry, because the venue may have accepted the first one and you may now hold twice the intended exposure; the recovery mechanism is an order status enquiry, a drop-copy comparison, or a session-level resend by sequence number. An instinct to make it idempotent and retry builds something that doubles positions under exactly the conditions it was built for. Rollback fails the same way: reverting a binary is a complete remedy only when the effects were confined to your own state, and in an order-routing path they left the building as executions that will clear and settle whether or not the code still exists. The remedy for the position is a market transaction at whatever price is available when you notice, and the loss is real money in an error account. That is why releasing a change to the order-routing path is asked as a proxy for whether you understand the domain at all.

Eventual consistency is usually a reasonable trade and is unreasonable in front of a pre-trade limit check, because the window in which two order paths both believe there is headroom is the window in which the firm exceeds its limit. It is unreasonable across a regulatory cut-off too, since "we converged an hour later" and "we reported late" are the same sentence to a supervisor. Deletion inverts as well: most systems improve when stale data goes, whereas here the corrected record and the record you previously believed are both needed permanently, because every later question is about a past belief, such as what the risk system saw when it approved the next order or which population a margin call was computed on. That is why correcting a mis-booked trade after it has been reported is answered by reversal and rebooking rather than by fixing the row.

The cost of being wrong is asymmetric and public

The failures that shaped this industry's engineering practice were not outages. In August 2012 Knight Capital deployed new code to seven of eight order-routing servers; on the eighth, a repurposed flag reactivated an old code path that began sending orders nothing was tracking against a parent instruction, and roughly $440M was lost in about forty-five minutes while staff could not identify which component to stop. In May 2010 an automated selling programme working a very large order without regard to price or time interacted with liquidity that was already thin and helped produce a violent intraday collapse and recovery in US equities. In August 2020 Citigroup, acting as loan agent, intended an interest payment and instead transmitted roughly $900M of principal to Revlon's lenders, because an operator working through a payments interface left fields at defaults and the approvals that followed did not catch it.

None of those three was a crash. In each case the system was available, healthy and doing precisely what it had been instructed to do, which is the property interviewers probe for: whether you can reason about a system that is working correctly and producing a catastrophe. Uptime is necessary, and it is not what the incidents are made of.

The regulatory surface is an engineering requirement, not a compliance footnote

Trading firms operate under obligations that translate directly into system properties. Brokers offering direct market access must apply pre-trade controls on their own systems rather than trusting the client's, which is why the limit check sits on the latency-critical path at all. Transaction reporting regimes require completeness, accuracy and timeliness, so a submission pipeline has to prove all three rather than merely send files. Best-execution obligations require evidence of why an order went where it went, which makes routing decisions data you retain rather than logic you execute. Record-keeping obligations require reconstruction of an order's whole life, which makes the audit trail a feature.

No interviewer wants the rules recited. They are checking that you know the requirements have architectural consequences, so that nobody has to tell you the timestamp precision, the clock synchronisation, the retention period and the immutability were never optional.

The lifecycle as the spine of the interview

Almost every question in this domain sits somewhere on the path from an intention to trade to a discharged obligation, and interviewers navigate that path deliberately. What you need is not a recital of the stations but the transition each one owns, because that is what lets you place a question you have not seen before.

sequenceDiagram
    accDescr: A sequence between client, broker OMS, venue, clearing house and depository, running from order instruction and limit reservation through router child orders and per-fill execution reports back to the client, then the allocation instruction, the affirmed trade, novation and netting at the clearing house, and net delivery versus payment at the depository transferring ownership.
    participant C as Client
    participant B as Broker OMS
    participant V as Venue
    participant H as Clearing house
    participant D as Depository
    C->>B: Order instruction
    B->>B: Validate and reserve limits
    B->>V: Child orders from the router
    V-->>B: Execution report per fill
    B-->>C: Fills and average price
    C->>B: Allocation instruction
    B->>H: Affirmed trade
    Note over H: Novation and netting
    H->>D: Net delivery versus payment
    D-->>C: Ownership transferred

Two moments in that sequence carry all the weight. At novation the party you are obliged to changes, and at the depository's transfer the ability to change your mind ends.

Pre-trade owns the last moment at which nothing has left the firm. Validation asks whether the instrument is tradable and not suspended, whether the client is permissioned for it, whether price and quantity sit inside fat-finger tolerances, and whether short-sale and buying-power constraints hold; brokers offering direct market access are required to run those checks on their own systems rather than trusting the client's, because the broker carries the risk of a runaway algorithm. The insight to carry in is that a limit check is a reservation against a shared quantity rather than a read of one, which is why pre-trade limit checks without adding latency is an engineering problem rather than a caching exercise.

Execution owns the transition from one instruction to many actions. A router slices the parent across lit venues, dark venues and possibly an internal crossing engine where it may match against another client of the same firm, so the parent-child relationship is state you must be able to reconstruct. On most equity venues the matching rule is price-time priority, and the consequence candidates miss is that time priority is forfeited the moment a resting order's price is amended or its size increased, so an algorithm that continually repegs sends itself to the back of the queue each time. This is also where the sharpest control problem sits, because an algorithm is an autonomous agent whose mandate has to say what happens when the market stops cooperating, which is the substance of what an execution algorithm optimises for, of liquidity disappearing a third of the way through the order, and of the fact that matching rules are venue policy rather than market physics, as placing orders on a pro-rata venue shows.

Post-trade owns the transition from what your firm believes to what two firms have agreed. A block executed for a fund manager is allocated across underlying accounts, normally at the block average price so no account is advantaged, then enriched with settlement instructions, fees, commission and tax before both sides confirm and affirm the economics. Breaks found here are cheap and the same break found on settlement date is expensive, which is the entire economic argument for the function: somebody has to own the difference between the front office's version and the version the outside world will accept, which is why the middle office exists rather than being an artefact of history.

Clearing owns the transition of counterparty. Novation replaces your exposure to the firm on the other side with margin obligations, default-fund contributions and a cut-off whose breach is a default rather than a delay, and netting collapses gross activity into one obligation per line, which is why a member trading millions of shares may deliver a small fraction of that volume. What a clearing house takes on when it novates separates candidates who know the word from those who can say what risk moved where.

Settlement owns the transition of ownership and the end of reversibility, with securities moving on the depository's books against cash in the payment system so that neither side is exposed to having performed alone. The United States, Canada and Mexico moved to a T+1 cycle in May 2024, India completed its own move earlier, and the EU and UK have committed to follow; compression removes slack from everything upstream rather than shifting a date, which is why T+0 is not T+1 minus a day. When delivery does not happen the trade does not vanish: it stays open, is re-presented on the next cycle, attracts a daily penalty in markets that operate one, and propagates to everybody downstream who was relying on the delivery, which is the scenario in settlement date arriving with the securities missing.

Asset servicing then owns everything the issuer does to a position you already hold, and its transition is between economic and legal ownership. Entitlements follow the register, so a holding that is lent, pledged or sitting at the wrong custodian pays somebody other than the person your books call the owner. Elections add a second complication, because the deadlines stack: the registrar sets one, the depository an earlier one, the global custodian earlier again, and your own operations team needs time before that, so a client told the market's deadline has been told the one they will miss. That is what makes a dividend on stock that is lent and pledged the question that most reliably identifies candidates who have worked in custody.

What interviewers ask

Interviewers in this domain are grading a small number of observable behaviours, and they are largely the same behaviours whether the question is about an order book or a corporate action. Being able to name them changes how you answer, because you can supply the signal deliberately instead of hoping it emerges.

The signals being graded

The first is whether you ask what has already happened before proposing a remedy. Every scenario here has boundaries the transaction may have crossed, and the remedy is set by the furthest one crossed rather than by the size of the error. Asking "has it been confirmed, reported, submitted for clearing, settled" before saying anything is the most valuable habit in post-trade engineering; beginning with a correction workflow skips the only part of the problem with money in it.

The second is whether you distinguish an absence of data from a datum of absence. A quiet feed and a dead feed look identical from the inside, as do an empty book and a stale one, and a counterparty who has not confirmed and a confirmation you failed to receive. The two cases require opposite responses, and what separates them is always the same shape: heartbeats, sequence continuity and an explicit staleness clock, with degraded treated as a state rather than as quiet.

The third is whether you say who owns the decision, because few hard cases here are purely technical. Pausing an algorithm protects the market and leaves the client holding timing risk; recalling a loan recovers a vote and forfeits revenue; publishing a partial risk run lets the desk open and understates exposure. Name the trade-off, identify the owner, and design so the owner sees the numbers while the decision is live.

The fourth is whether your verification is about substance rather than liveness, since a health check and a flat error rate can both be satisfied while the system does the wrong thing: sending orders is the normal behaviour of an order gateway and the venue will accept every one. What catches this class of failure is a reconciliation, of parent to child, position to fills, your record to the venue's drop copy, your books to the custodian's statement.

The fifth is precision about identity and time: which instrument, under whose identifier, valid on which date; which price, struck by which venue; which position, at which place of settlement, in which legal state; which timestamp, on whose clock. Vagueness here is the commonest reason a technically strong candidate reads as inexperienced, because the vagueness is where the defects live.

How the same question is scored at different levels

The questions barely change between a mid-level and a staff interview; the scope of answer that satisfies the interviewer does. At mid level, a good answer is mechanically correct within one system: the right message, the right sequence, the right failure mode, the control that catches it. At senior level it has to cross a boundary, covering what the counterparty sees, what downstream consumers must be told, and which deadline the fix has to beat. At staff and architect level it is expected to change the shape of the problem, by proposing the derivation that removes the class of error, the invariant that makes the failure detectable in the first minute rather than the fortieth, or the data model that makes a category of investigation unnecessary.

The vocabulary tells

A few distinctions are impossible to fake and quick to check. Conflating the clearing house with the custodian is the most common, since they are different institutions and only one becomes your counterparty. Treating a position and a holding as synonyms is the second, which is why positions, holdings and corporate-action elections is asked as a definitional question with consequences attached. Using "settled" to mean "executed" is the third, and it marks someone whose exposure to the domain stopped at the trading screen.

The positive tell is the reverse. Candidates who have built these systems raise reference data unprompted, because that is where their time went, and the specific observation that the same security held under two identifiers in two places will project as two positions and hide a shortfall says more about experience than any answer about throughput.

What interviewers do not ask, and what candidates over-prepare

Low-latency micro-optimisation dominates interviews for roles on a latency-sensitive path and is close to absent from platform, post-trade, risk and custody interviews, where the questions are about correctness under partial failure, evidence and the ordering of remedies. Someone who has memorised cache-line behaviour and lock-free queues but cannot say what happens to a resting order when their gateway restarts has prepared for a different interview.

Regulation is the mirror image. Naming a regime and reasoning about its system consequences is strong, whereas quoting article numbers is risky and adds nothing: the interviewer's recall of the clause is probably no better than yours, and the engineering consequence is the part being assessed. The same applies to market structure trivia. Knowing that a venue's matching rule changes optimal placement is worth credit; knowing a specific fee schedule is worth none, and getting it wrong costs you.

Questions

What follows is a working set of questions phrased the way interviewers put them, grouped by the part of the lifecycle they sit in, each with the answer that earns credit and the signal it supplies.

Order lifecycle and order handling

Walk me through the lifecycle of an equity order from the click to settlement.

Answer it as five regimes rather than one pipeline, naming a failure at each: validation, where the failure is a reject and the interesting property is whether the client can distinguish "rejected by us" from "never received"; routing and execution, where one parent becomes many children and a dropped session leaves orders you cannot see but can still trade; fills and allocation, where the failure is a break between the block and the account splits; clearing, where the failure is a margin call the member cannot meet; and settlement, where the failure is a non-delivery that leaves the trade open.

The signal is that you treat execution as a milestone rather than the finish line, because a candidate who says the trade is done when it fills cannot then say who owes what on Tuesday morning. State that the obligation is created at execution and discharged at settlement, and that everything in between exists to make the discharge certain. The full walk is in the lifecycle question.

A fill arrives for an order you already cancelled. What does your system do?

Accept it, because the venue's view of the order is authoritative and a cancel request is a request rather than a command. The race is inherent: your cancel and the venue's match crossed in flight, and the venue's matching engine decided first. The correct model is that your cancel request has three outcomes, namely accepted, rejected because the order is already filled, or rejected because the order is unknown, and that between sending it and receiving the response the order is still live.

What earns credit is the consequence you draw. The position is real and has to be reflected in risk immediately even though your order state said cancelled. The fill must be attributable to a parent instruction, and if your cancel handling removed the parent then you have created an unattributable execution, which is the highest-severity condition such a system can produce. This is treated in depth in what happens when a fill arrives for an order you already cancelled.

Why keep parent and child orders as separate entities rather than one order with a list of fills?

Because they have different owners and different lifecycles. The parent is the client's instruction, carrying limit, participation cap, completion obligation and benchmark; the child is your firm's action in the market, carrying the venue's identifier, state machine and queue position. A single entity cannot express that a parent is working while three children rest, one is being replaced and one has been rejected.

The stronger reason is the invariant it lets you state. With children first-class you can continuously assert that every child maps to exactly one parent, that the sum of child quantities never exceeds the parent's, and that every execution reconciles to a parent, which is what detects a routing defect in the first minute. A model that treats fills as a list attached to the client's order cannot notice an order it never intended to send.

A client says they never received a fill that you show as sent. How do you settle the argument?

By sequence number and by an independent path, not by log inspection. A FIX session guarantees an ordered, gap-detectable stream in each direction, so the question "did message 4,182 reach you" has a determinate answer, and the recovery mechanism is a resend request against the session rather than a re-derivation from your database. If your side sent it and the session gapped, the gap is visible on both sides and the remedy is defined by the protocol.

The part that distinguishes a strong answer is the independent path. Drop copies exist so that a third view of your own executions is available through a channel that is not the one under suspicion, and a firm that reconciles its order state against its drop copy continuously can answer this class of dispute in minutes with evidence rather than in hours with assertions. Add that timestamps on both sides must come from synchronised clocks at a precision the regime requires, or the reconstruction is contestable regardless of who is right.

Where in the lifecycle does your firm stop being able to change its mind?

Name the boundaries in order, because the answer decides where controls belong rather than merely describing the plumbing. Every control worth having sits to the left of an irreversible boundary; one placed to the right of it is not a control on the action but an early start on the recovery.

The rows are not evenly spaced in cost. The first four are administrative, the middle two involve another institution's records and timetable, and the last is a trading loss whose size is whatever the market did while nobody noticed. That is why the first question in any correction scenario is which row you are on, and it is the load-bearing idea in correcting a mis-booked trade after it has been reported.

Execution algorithms and liquidity

What does an execution algorithm optimise for?

Not price, and saying "the best price" is the answer that ends the conversation. An algorithm optimises a stated objective against constraints supplied by the client's instruction, and the objectives conflict: minimising market impact means trading slowly, minimising timing risk means trading quickly, and tracking a volume-weighted benchmark means neither. The instruction has to say which constraint wins when they disagree, because if it does not, the algorithm answers that question on the client's behalf.

Credit comes from naming the measurement problem alongside the objective. Performance against arrival price, against a scheduled benchmark and against the market's own subsequent behaviour are three different results, and an algorithm evaluated on the benchmark it was designed to track will always look good. What an execution algorithm optimises for goes through the objective set properly.

Your algorithm is a third of the way through a large sell order and the liquidity on the other side disappears. What should it do?

Establish first whether the book is empty or your view of it is, because a thin market means slow down and a stale feed means stop entirely. Then recognise the feedback loop: a participation-rate algorithm targets a share of traded volume, and traded volume includes its own prints, so in a thin market trading more raises measured volume, which raises the permitted rate. The defence is that the participation measure excludes your own executions and the price constraint is anchored to something your trading cannot move.

Then specify the behaviour, because the default is bad. Only one of the available responses is acceptable as a silent default, and saying which and why is most of the answer.

The third row is the only one that keeps the decision with the party entitled to take it, and it is the row that has to be built rather than emerging by accident. It needs a trigger the desk can reason about, a defined posture on resting orders, a resumption condition so a two-second event does not require a human, and a visible escalation to somebody who can widen the constraint or work the residual by hand. A venue halt is a different regime again, since resting orders may be cancelled or carried into an auction whose dynamics continuous-market logic gets wrong. The full treatment is in liquidity disappearing a third of the way through.

How would you set a price collar that does not simply follow the market down?

By anchoring it to a reference the algorithm's own trading cannot influence. A collar computed from the current best bid moves every time you hit it, making it a ratchet rather than a limit, whereas one struck from the arrival price or from an interval far longer than your trading horizon holds still while you work. Pair it with an escalation rather than treating it as a decision: when the collar binds, the algorithm has learned that the market has moved beyond the client's stated tolerance, and the client or the desk decides whether the tolerance or the order changes.

How does your placement logic change on a venue that allocates pro-rata rather than by price-time?

Under price-time, queue position is the scarce resource and the discipline is to join early and avoid amendments that cost priority. Under pro-rata, allocation is proportional to displayed size at the price level, so size becomes the lever and early arrival buys you much less. That inverts several habits: showing more quantity is rational in a way it is not on a price-time book, and the risk profile changes because you can be filled on a larger proportion than you expected when other participants pull.

The signal is knowing that matching rules are venue policy rather than market physics, and that an algorithm which hard-codes price-time assumptions will behave incorrectly on a venue where they do not hold. Some venues also use hybrid allocations that reward the first order at a price with a fixed portion before splitting the rest, which changes the calculation again. Placing orders on a pro-rata venue works through the consequences.

How do you know whether your smart order router is any good?

By measuring outcomes rather than fill rates, and by designing the measurement so it can be wrong. Fill rate flatters a router that sends flow to venues where it is easy to trade and expensive to have traded, so the honest measures compare execution prices against the arrival price and examine what happened to the price shortly after each fill. A venue where your buys are systematically followed by falls is selecting against you, whatever its fill rate says.

What separates a strong answer is proposing that routing decisions be randomised deliberately across a controlled proportion of flow, so venue comparisons are not confounded by the router's own preferences; without that, your data describes only the orders the router chose to send, which is the population under evaluation. Add that the decision and its inputs must be retained, because best-execution obligations require you to evidence why an order went where it went.

Market data and reference data

Design an order book.

Start from the operations it has to support and the invariants it must never break. Insert, cancel, amend and match, with price levels ordered on both sides and time priority within a level, and the invariant that the best bid is strictly below the best offer outside a crossed or auction state. That points at an array or map of price levels, each holding an intrusive queue of orders, with an index from order identifier to its node so that a cancel is constant time rather than a scan.

The design conversation then goes where the interviewer wants it: what happens when a feed gaps, whether the book is rebuilt from a snapshot plus increments and how you sequence the two, whether you support multiple books per instrument across venues, and how you represent a level that empties. Say that prices are integers in tick units rather than floating point, and that you keep aggregate quantity per level incrementally rather than summing on read. How to design an order book covers the recovery path in detail, which is the part candidates prepare least.

Consolidate quotes from several venues whose feeds arrive with different latencies.

Accept at the outset that a consolidated best price is a statement about a moment, and that the moment differs per venue. A naive consolidator takes the best quote it currently holds from each venue and reports the maximum bid and minimum offer, which can produce a locked or crossed composite made from quotes that were never simultaneously true. That composite is not merely imprecise, it is actionable in a way that loses money, because the arbitrage it appears to show has already gone.

The answer is to timestamp by the venue's own clock where available, keep per-venue staleness clocks, and treat a venue whose updates have stopped as degraded rather than as unchanged. Say what the consumer should be told: the composite plus its constituents plus their ages, so an algorithm can decide whether to trust it. Consolidating quotes across venues with unequal latency sets out the degraded-state design.

A researcher's backtest and the desk's live results disagree about the same stock's price history. Where do you look first?

Not at the arithmetic. Narrow the definitions in order, because each step invalidates the comparison below it. First identity: is it the same instrument for the whole period, given that companies reorganise and tickers get reused, so a history keyed on ticker can contain two businesses joined where one ended. Then series definition: an official closing price struck in an auction is not the last trade on the primary venue, which is not the last trade anywhere, which is not a consolidated close. Then adjustment: a price-adjusted series and a total-return series differ by income the live book only receives if it held through the record date and was not lent out.

The point to lead with once identity is settled is that adjusted history has no fixed value: every new corporate action causes the vendor to recompute factors, so the number recorded three years ago has since changed, and a backtest quoted without its data vintage is unfalsifiable. Store raw prices immutably, corporate actions as dated events, derive the adjusted series as at a stated date, and treat the currency conversion as a second series with its own defects. The backtest and the desk disagreeing on price history ranks the usual causes.

What is point-in-time reference data, and why do golden-source projects fail without it?

Point-in-time reference data answers what you believed on a date, not what is true now. Index membership, sector classification, shares outstanding, credit rating, lot size, tick size, instrument identifiers and the mapping between them all change, and are all commonly stored as current values with an update overwriting the previous one. Any calculation that filtered on such a field was filtering on facts from the future, which is how a research result becomes a story.

Golden-source programmes fail when they define the goal as one correct current value rather than one traceable history. A single value satisfies today's report, destroys the ability to reproduce yesterday's, and hides the genuinely hard problem, which is that two sources disagreeing is normal and the resolution is a decision that has to be recorded with its reason. What works is a permanent internal identifier minted once and never reused, external identifiers attached as dated mappings, source values retained as received, and the resolved value derived with a stated as-at date.

Risk and margin

How do you run pre-trade limit checks without adding latency to the order path?

By making the check local, in-memory and free of network dependencies at decision time, and by treating the limit as a quantity you reserve rather than a value you read. Limits and current consumption are pushed to the checking process and updated asynchronously; the check itself is arithmetic against local state. Where multiple order paths share a limit, the consumption has to be partitioned or reserved atomically, because a read-then-send pattern across two gateways is a race that ends with the firm past its limit.

The nuance to volunteer is what happens when the risk state is uncertain. A check that cannot establish current consumption has two options, and the safe one is to fail closed by rejecting rather than to let flow through on stale numbers. Firms that choose otherwise usually do so with a deliberately tightened limit for the degraded period, which is a legitimate design if it is stated. Pre-trade limit checks without adding latency covers the partitioning approaches.

The clearing house calls margin larger than your own model computed. What do you do?

Pay it, then investigate, and say that in that order. The clearing house's number is contractual and the cut-off is a default boundary rather than a service-level target, so funding the call is never contingent on agreeing with it. Disputing before paying converts a modelling difference into a membership problem.

The investigation then follows a ladder of causes. Population first: does the clearing house hold positions you do not think you have, from a trade you booked differently, an allocation that did not reach them, or a give-up that did not complete. Then the market data: their end-of-day prices and curves are theirs, not yours. Then the model: initial margin methodologies, whether scenario-based or a value-at-risk family, have parameters, holding periods, add-ons for concentration and liquidity, and procyclical responses to volatility that your replica may not track. Then the account structure: gross and net margining at account level produce very different numbers from the same positions. Saying that you maintain a shadow calculation whose purpose is to explain differences rather than to be right is exactly the register that earns credit here, and a clearing house margin call larger than your own number develops the escalation path.

Your overnight risk run will not finish before the desks open. What do you do, and what do you change?

Answer in three horizons, because the interviewer is testing incident judgement, product judgement and architecture in one question.

Tonight, the decision is not technical. Someone must choose between opening the desks without a complete picture and delaying the open, and that person is the risk officer. Your job is to make the choice informed, by publishing what completed with an explicit statement of what did not: which books, which measures, and what the excluded exposure was at the previous valuation. A partial run presented as complete is worse than a late one, because it understates exposure on precisely the population that failed. For the gap, an approximation such as applying today's market moves to yesterday's sensitivities is often defensible if it is labelled and its weakness stated, since it misses the non-linearity that made the position interesting. And where risk is stale, the compensating control is to tighten limits or restrict new business on the affected books, which the risk function can do quickly once you have given them coverage figures.

Tomorrow, find what the run was waiting for, because it is rarely raw compute. The dominant causes are late or missing inputs: a fixing that arrived after the snapshot, a curve that failed to build because one instrument was absent, a position feed that landed late, or a corporate action that invalidated a cached instrument definition. A single missing input failing a whole batch is an availability defect wearing a performance problem's clothes, and the fix is to degrade at the smallest unit rather than the largest.

flowchart TD
    accDescr: Triage for a batch run that will not finish before the open, branching first on whether it is waiting on a missing input, completing that dependency chain if so and otherwise ranking the remaining books by materiality, both routes publishing with coverage stated, then a second branch where coverage unacceptable to risk tightens limits or restricts new business and acceptable coverage lets desks open on a stated basis.
    A[Run will not finish before the open] --> B{Waiting on a missing input}
    B -->|Yes| C[Complete that dependency chain first]
    B -->|No| D[Rank remaining books by materiality]
    C --> E[Publish with coverage stated]
    D --> E
    E --> F{Coverage acceptable to risk}
    F -->|No| G[Tighten limits or restrict new business]
    F -->|Yes| H[Desks open on a stated basis]

The decision the engineer owns is everything above the coverage question; the two branches below it belong to the risk function, and an escalation that arrives without coverage figures forces them to take it blind.

Structurally, name these. Restartability at fine granularity with idempotent units, so a failure at hour four costs minutes. Checkpoints that separate valuation, aggregation and reporting rather than one long transaction. Ordering by materiality, so the largest and most non-linear books finish first and a partial result is useful rather than arbitrary. A coverage measure published alongside every risk number. A market data snapshot decoupled from the run, so a late fixing revalues one dependency chain instead of restarting everything. Incremental revaluation of what changed, which requires the dated reference data discussed earlier. And continuous measurement of headroom, because a batch that finishes just in time has no capacity for the day when volatility is exactly what makes the number matter. The scaling failure modes are drawn out in the trade-offs when scaling risk and margin in production.

What is your kill switch scoped to?

To something a person can name from the evidence in front of them: this session, this gateway, this strategy, this account, this instrument. "Stop trading" is not an operable instruction in the middle of the afternoon, because the operator is reasoning from an alert and needs a control whose granularity matches the alert they are holding.

Two properties beyond scope decide whether the switch is real. It has to be reachable when the component that would decide to pull it has failed, which means it cannot live in the same process or depend on the same store. And its effect on existing state has to be defined in advance, meaning whether it blocks new orders, cancels resting ones, or both. An operator discovering mid-incident that the switch stopped new orders and left a thousand resting is discovering it at the worst possible moment. Say also that you exercise it in production on a schedule, because an untested switch is a belief rather than a control, and a firm that has never pulled it does not know how long it takes to take effect.

Clearing and settlement

What does a clearing house take on when it novates, and what does it hand back to you?

It takes on counterparty credit risk, becoming buyer to the seller and seller to the buyer, so the failure of the firm on the other side of your trade stops being your exposure. It hands back a set of obligations that are stricter than the ones it replaced: initial margin posted up front, variation margin met intraday to a hard cut-off, contributions to a default fund that mutualises losses among surviving members, and membership requirements you must continuously satisfy.

The mature part of the answer is that novation concentrates risk rather than removing it. The clearing house is now a single point whose failure would be systemic, which is why its default waterfall, margin methodology and liquidity arrangements are so heavily regulated, and why a member's real exposure is not just to its own positions but to a fund that could be drawn on because somebody else failed. What a clearing house takes on when it novates sets out the waterfall properly.

Why is T+0 not simply T+1 minus a day?

Because the day between execution and settlement is doing work, and removing it removes the work rather than compressing it. Netting requires a window in which offsetting activity accumulates, so a shorter cycle nets less and increases the gross volume of deliveries and the funding required to support them. Securities lending recalls need time to settle, and a recall that cannot complete before delivery becomes a fail. Cross-border activity needs a window in which the currency leg can be funded across time zones. Exception handling needs a window in which a human can fix a break.

At T+0, several of those windows become zero, which means the activities have to be eliminated rather than accelerated: pre-funding instead of netting, borrowing rather than recalling, and straight-through processing with no manual repair path because there is no time for one. That is why the industry conversation is about atomic settlement models and pre-positioning rather than about faster batches. Why T+0 is not T+1 minus a day works through what breaks first.

Settlement date arrives and the securities you owe are not in the account. Talk me through what happens next.

Nothing settles, because delivery versus payment moves both legs or neither, and the trade stays open rather than failing in the way an operation fails. The depository re-presents the instruction on the next cycle, and your record has to be able to express "intended to settle on this date, still open, failing for this reason, for this many days" as a normal state.

Saying what each party now holds is what separates a candidate who has operated one of these systems from one who has read about it, because the states do not agree and every one of them has to be represented somewhere.

The last row is the reason markets price fails at all. The cost of your delay falls mostly on parties who are not on your trade, which is why penalties and buy-ins exist rather than leaving the two counterparties to settle it between themselves.

Then diagnose, because the remedies do not overlap. Either you never had the stock, because your own inbound purchase failed and you are in a settlement chain; or you have it and it is unavailable, being lent and unrecalled, pledged, or at a different custodian from the one the instruction points at; or the instruction never matched, which is a static-data failure wearing a settlement failure's clothes. The remedies in ascending order of cost are partial delivery, borrowing to cover, and being bought in by the receiving party, and only the first two are your choice. Add that entitlements arising during the fail belong to the buyer through a market claim, and that the preventive controls are pre-matching and a forward inventory projection rather than anything available on the morning itself. The settlement-fail scenario covers the choice between remedies.

You have been asked to move affirmation two hours earlier. Where do you look?

At the queue of manual exceptions, because that is what the two hours were being spent on. The mechanical path is usually already fast: allocations arrive, trades enrich, confirmations go out, affirmations come back. The time goes on the population that does not flow, and its causes are dull and specific: an account without a standing settlement instruction, a new counterparty not set up, an allocation whose quantities do not sum to the execution, a price differing by a rounding convention, a fee schedule that has not been applied, a client who affirms by email.

The credit is in proposing measurement before engineering: instrument the pipeline to attribute elapsed time to cause, attack the causes by volume, and expect the answer to be reference data and counterparty onboarding rather than throughput. There will always be a residue, and it needs an earlier internal cut-off, a named owner and an escalation, since the market's deadline is the last in the chain rather than yours.

Custody, corporate actions and securities lending

A dividend is declared, half the holding is on loan and part of the rest is pledged. Who gets the income, who votes, and what does the client see?

Legal title passes on a securities loan, so the borrower is the owner on the record date and receives the dividend; the lender receives a manufactured payment from the borrower under the lending agreement. That payment carries counterparty risk the real dividend did not, can arrive on a different date, and can be taxed differently, so the lender's net position may differ from the gross even when the amounts match. For the pledged portion, the answer depends on the documentation: a title-transfer arrangement behaves like a loan, whereas a security interest leaves title and therefore the dividend and the vote with the client.

Voting follows the register, so lent stock cannot be voted unless the loan is recalled early enough for the return to settle before the record date, making the operative deadline several days earlier and the decision a commercial one between lending revenue and the vote. Hold one economic position for the client with the legal breakdown by location underneath it, and allocate voting entitlement in omnibus accounts from record-date positions rather than traded quantities, or you will over-vote. The dividend on lent and pledged stock is the fullest treatment.

A corporate action is notified after you have already struck positions for the day. What now?

Establish which dates the event has already passed, because that determines whether this is a recalculation or a set of claims against other parties. If the ex-date has passed, trades executed on either side of it have different entitlements from the ones your struck positions assumed, and the correction is not just to the position but to everything derived from it: valuations, income accruals, client reporting, index-linked calculations and any election deadline that has now moved.

The strong answer distinguishes the categories of event, because they behave differently. A mandatory event changes the position whether anybody acts or not, so it is a recalculation. A voluntary event requires an election, so a late notification is a deadline problem and may mean the default outcome has been applied on the client's behalf. A mandatory event with options is both. Then say how you stop it recurring: the event has to be a dated, versioned record with its own lifecycle from announced through confirmed to paid, so that a late or amended announcement is an update to an entity rather than a message that arrived at the wrong time. A corporate action notified after positions were struck works through the reprocessing.

What is the difference between a position and a holding, and why does an election need both?

A position is what you own economically, including everything traded and not yet settled. A holding is what is present in a specific place, at a specific custodian or depository, in a specific legal state. They differ by unsettled trades, by lent and pledged quantities, and by anything held somewhere other than where you assume.

Elections need both because eligibility is determined by the register, which sees the holding, while the client's instruction is naturally expressed against the position, which is what they think they own. An election submitted for more than the eligible holding will be rejected or, worse, partially accepted, and an election submitted for less quietly forfeits value. Fractional entitlements make it sharper: a ratio applied to an aggregated omnibus holding does not distribute cleanly to the underlying clients, so the rounding policy is a real design decision with a real winner and loser. Positions, holdings and corporate-action elections is the definitional question with the consequences attached.

You are building the engine that decides when to recall lent stock. What drives the recall date?

Work backwards from the event that requires the stock, then subtract every interval that must fit before it. For a sale, the driver is the intended settlement date; for a vote, the record date; for an election, the earliest deadline in the stacked chain. From there, subtract the settlement cycle for the return leg, the notice period in the lending agreement, an allowance for a failed return, and your own operational lead time. The recall date is the result, and it is usually earlier than people expect, which is exactly why an engine computes it rather than a person estimating it.

What earns credit is treating those intervals as data per market, per agreement and per event type rather than as constants, and saying the engine must also carry the economics, since a recall forfeits fee income and the desk is entitled to see the cost of the decision it is being asked to take. Then add the projection that feeds it: a forward view of what you will owe and what you will hold, per line and per place of settlement, which is what surfaces the shortfall while a recall can still complete.

Post-trade, payments and controls

Why does the middle office exist? Could you not automate it away?

It exists because two firms independently record the same trade and their records will differ, and somebody has to own the difference before it becomes a settlement failure or a misstated position. Its functions are enrichment, confirmation and affirmation, position and profit-and-loss ownership, break investigation and the interface to clearing and settlement. Automation has already removed most of the volume; what remains is the population that does not conform, and that population is generated by reality rather than by inefficiency.

The senior answer names what automation changes rather than claiming it removes the function. Straight-through processing raises the proportion that flows and concentrates the remainder into cases that are individually harder, so the expertise required per exception goes up rather than down, while a shorter settlement cycle shrinks the window in which those exceptions can be worked. The direction of travel is fewer people doing harder work under tighter deadlines, and a system designed as though exceptions were rare will be brittle at the only point where humans are still involved. Why the middle office exists covers the functions in order.

A payment instruction is about to leave that is a hundred times the usual size for that counterparty. What should stop it?

Locate the irreversible boundary first: an unconditional cash transfer through a high-value payment system is final once settled, and recovery depends on persuading the beneficiary or a court rather than on operating a reversal. So the question is how many controls sit before that boundary, and a firm with excellent reconciliation and no pre-release control will discover this error accurately, the following morning, after the money has gone.

The strongest control is that nobody typed the amount. Derive the payment from a recorded obligation, so an interest payment comes from a schedule, a settlement payment from a matched trade and a margin payment from a reconciled call. Then it cannot exceed the obligation, cannot go to an account that is not the standing settlement instruction, and a payment with no obligation is an exception by construction. Add that maker-checker fails predictably when the checker sees the screen the maker built, so the second review must show something new: the payment against the obligation it discharges, the amount as a multiple of the recent average for that counterparty, the beneficiary account with when it was last changed, and authority escalating with size. A payment a hundred times the usual size develops the derivation argument.

A trade was booked with the wrong quantity and you find out after it has been confirmed, reported and sent for clearing. What has to happen?

Ask what has settled before proposing anything, because the remedy is a step function in the boundaries crossed. Confirmed means reissuing and re-affirming with another firm involved. Reported means a cancellation and a corrected submission under the regime's action codes, promptly. Submitted for clearing means the clearing house holds a position that is not yours and has called margin on it. Instructed means recalling before the depository's cut-off. Settled means nothing can be reversed and only a new trade at today's price restores the position, with the price difference being real money.

Then correct properly. Static and settlement data can be amended in place; economic terms, meaning quantity, price, side, instrument and trade date, must be cancelled and rebooked, because changing one asserts that a different trade happened. Never edit the row, since every later question is about a past belief. Keep the original execution time and trade date on the rebooking: the correction happened today and the trade happened when it happened. Book the resulting profit or loss to an error account so the cost of mistakes stays visible rather than absorbed into a trading result, and separate approval of the correction from the person who made the error.

Regulatory reporting

Your transaction reports are being rejected at a small but persistent rate. Where do you start?

By splitting rejections from acceptances that are wrong, because the second population is larger and more dangerous: a rejection is visible and has a remedy, whereas an accepted report with a wrong field is a misreport you learn about from a supervisor. So build the reconciliation between the trade store and the submissions first, asserting that every reportable event produced exactly one current report, that its economics match, and that nothing was reported that should not have been, since over-reporting is a breach in the same way under-reporting is.

For the rejections, classify by cause rather than by count, because the causes have different owners and different fixes, and a single queue sorted by age hides that entirely.

Reference data dominates the volume in practice, and the economic row is the one to read carefully, because that is where a genuine misreport hides behind a rejection that looks technical.

Propose that reporting be derived from the trade lifecycle as an event stream rather than assembled by a nightly extract, so a correction upstream produces a correction downstream with the right action code. Retain the submission exactly as sent and the response exactly as received. And treat rejection feedback as a monitored input with an owner and an ageing report, since a rejection nobody resubmits is an unreported transaction with a clock running on it.

A supervisor asks you to explain a report you submitted eighteen months ago. What do you need to have kept?

The submitted message, byte for byte, with its identifiers and timestamps. The response, including any acceptance or rejection and its reason. The trade record as it stood at the moment of submission, not as it stands now. The reference data used to populate it, at the value it held then. The mapping logic version that produced it. And the chain of any corrections since, each linked to what it replaced with a reason code that distinguishes a genuine amendment from an error correction.

The reason this is a design question rather than a retention question is that most systems can produce today's answer and cannot produce the one they gave. If your reporting layer reads current state and current reference data, then regenerating the report eighteen months later produces a different message, and you have no way to demonstrate that the difference is a legitimate later correction rather than a defect you have just discovered. Immutable submissions, dated reference data and versioned mapping are what make the answer possible, and volunteering the third one is a strong senior signal because it is the one most firms miss.

Releasing and operating trading systems

Walk me through releasing a change to the order-routing path, and tell me what makes it different from deploying any other service.

The difference is that the node holds obligations you cannot drain. Orders it sent are resting at a venue under the venue's identifiers and will match whether or not the process is running; the session carrying execution reports has sequence numbers both sides track; and the mapping from venue order back to parent instruction has to survive the restart or the fills that arrive afterwards belong to nothing. So the release plan begins with what happens to those obligations: cancel everything the node has resting and accept the cost, or restart with session and order state recovered from durable storage and reconciled against the venue before the node may send anything new, or do not deploy while the market is open.

Then handle the mixed fleet, since a rolling release means two versions transacting at once, which is tolerable only if they agree about everything they share. Configuration is the item most often overlooked: a flag whose meaning changed means both halves read the same value and behave differently, with nothing reporting an error. Dead code must be deleted rather than disabled, because a disabled path is a latent instruction waiting for the wrong value. Verification is a continuous reconciliation of your working orders against the venue's view through a drop copy, so the comparison does not use the path under suspicion, and anything trading without an attributable parent should stop the flow rather than raise a ticket. Say plainly that rollback does not undo executions, which is why out-of-hours conformance testing, shadow running and ramping flow across a few instruments with a notional cap and a person watching are the real controls. Releasing a change to the order-routing path maps each element onto what went wrong at Knight Capital.

How do you test a system whose main dependency is a market?

With three distinct kinds of test, and the interviewer wants to hear all three. Deterministic simulation of the venue, so that your state machine can be driven through every transition including the awkward ones: a fill for a cancelled order, a reject after an acknowledgement, a session drop mid-sequence, a duplicate execution report, a partial fill on an order being replaced. Replay against captured production data, so the system meets sequences nobody would think to write, with the capture retained as a regression corpus. And conformance against the venue itself, out of hours, because the authority on the venue's behaviour is the venue and your simulator encodes your beliefs about it.

Add property-based assertions on the invariants rather than only example tests, since the invariants are what you care about: children never exceed the parent, cumulative quantity is monotonic, average price is consistent with the fills, no execution lacks a parent, and the position implied by fills equals the position risk holds. Then say what you cannot test, namely the market's behaviour in response to your own orders, which is why live ramping with small size is part of the verification rather than an admission that testing was incomplete.

An alert says your gateway is sending orders nobody can attribute. What do you do in the first sixty seconds?

Stop the flow at the smallest scope that certainly contains the problem, before diagnosing. Unattributable executions mean the firm is taking positions no risk system is measuring, and the cost of that grows with time while diagnosis does not. So the first action is the scoped switch: this session, this gateway, this strategy, chosen because you can name it from the alert in front of you. That is the argument for scoping a kill switch to something an operator can identify under pressure, for keeping it reachable when the component that would decide to pull it has failed, and for defining in advance whether it blocks new orders, cancels resting ones or both, since discovering that it left a thousand orders resting is a discovery best not made during an incident.

Then, in parallel rather than in sequence, establish the position from the venue's own record rather than the system under suspicion, get a human flattening the exposure at current prices, and preserve state before anything restarts. Recovery is a trading decision with a loss attached that belongs in an error account, and the incident ends when positions reconcile rather than when the process comes back. Interviewers grade the ordering: acting before understanding is correct here, and candidates who insist on diagnosing first have not internalised what an unattributed order costs.

Judgement and behavioural rounds

Tell me about a time you stopped a release, or wish you had.

Answer with the specific signal that made you stop and the specific cost you incurred by stopping, because both halves are being assessed. The signal should be something concrete: a reconciliation that did not balance in the rehearsal, a configuration difference between two hosts, a conformance test skipped because the venue window closed, a change whose rollback path had not been walked. The cost should be named honestly: a desk that could not get the feature that day, a delivery date missed, a colleague's weekend.

What is being graded is whether you can hold a control position under commercial pressure and communicate it in terms the business recognises. "It did not feel ready" is not defensible. "The reconciliation between the gateway and the drop copy did not balance in the rehearsal and we could not explain the difference, so we could not have detected a bad release in the first minute" is a sentence a trading manager will accept, because it names the risk they were being asked to carry.

The desk needs a change today and change control needs three days. What do you do?

Refuse to answer it as a binary, because that is the assessment. Establish what the desk is exposed to today, since a change to a workflow that is merely inconvenient and a change that prevents them managing a live risk are different problems with different answers. Then look for the smaller change that addresses the exposure without touching the path that requires three days, such as a limit adjustment, a manual workaround with a named owner, a configuration change inside an already-approved envelope, or restricting the affected activity for the day.

Then say what an expedited path should look like, because mature firms have one: a defined emergency process with a higher approval bar, a shorter but non-zero set of checks, mandatory post-hoc review and a hard rule that emergency changes are re-done properly afterwards. What loses credit is either capitulating without a control or hiding behind the process while the desk carries a real exposure. What earns it is being the person who finds the third option and documents which risk was accepted by whom.

The traders will not give you requirements. How do you work with them?

By watching rather than asking, and by bringing something to react to. Traders describe their work in outcomes and exceptions rather than in behaviours, so sitting with the desk during the hard parts of the day and noticing which figures they recompute by hand tells you what the requirement was: the spreadsheet is the specification. Then close the loop in their vocabulary by showing a narrow version early against real data from a real day and asking what is wrong with the numbers, since a trader who disagrees with a figure will explain the domain in detail. Be explicit about the two things they never volunteer, namely what the system should do when it is unsure and who expects to be told when it stops, because those decide whether the thing you build is trusted.

How to prepare without memorising

Efficient preparation here is not a longer glossary. Build the lifecycle spine until you can walk it out loud with a failure and a control at every station, then attach to each station the detail that surprises people: a cancel is a request, a participation algorithm measures its own prints, adjusted history is rewritten, a loan transfers title, a fail leaves the trade open, and reverting a binary does not unwind an execution. Each generalises to a family of questions rather than answering one.

The ordering habits matter more than the facts and are cheaper to acquire, so practise them until they are automatic: ask what has already happened before proposing a remedy, separate an absence of data from a datum of absence, name the owner when the trade-off is commercial, verify with a reconciliation rather than a health check, and be precise about which instrument, which price, which place and whose clock. Most candidates lose points not for missing knowledge but for having it and never making it observable, and each of those habits is a way of making it observable within the first minute of an answer.