Define a Reliable Trade-Reconciliation Library Contract
Citadel SecuritiesSoftware Engineer · Technical Screen
Last updated
Define trade-reconciliation contracts and OOP boundaries with exact values, timestamp tolerance, partial-fill questions, deterministic policy ownership, and traceable breaks.
Design the parsing and domain boundaries of a trade-reconciliation library that identifies unmatched buy/sell records. Explain how timestamp tolerance, partial fills, and malformed data affect the contract before implementing matching.
Constraints & Assumptions
The source reports reconciliation coding and OOP discussion but does not disclose the matching fields, tie policy, partial-fill rules, or file grammar. This exercise preserves the supported engineering discussion; it does not invent a specific executable matching problem.
Clarifying Questions
Which fields identify compatible trades? Is matching one-to-one or can quantities split across fills? What timestamp unit, timezone, and tolerance apply? If several matches are possible, which pairing objective and tie rule are intended? Is input batch or streaming?
Follow-up questions
- Why is exact timestamp equality inappropriate under the reported tolerance requirement? What if tolerance makes several candidates eligible? How do late records or duplicate inputs affect a break already reported?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.