Sharing my recent first technical round for an experienced-hire role on Treasury Engineering at the Citadel hedge fund. It was in Python and lasted about an hour.
For the first 15 minutes or so we talked about my background. They asked whether I prefer research or engineering, what I like most and least about my current job from a technical point of view, and whether I take part in production support and have on-call.
Coding: implement a simplified in-memory spreadsheet. It needs three interfaces:
set_cell: set a given cell to a numeric value.set_formula: set a cell to a formula, supporting add, subtract, multiply and divide.get_cell: return the cell's current computed result.
Follow-ups:
- Nested formulas.
- Circular references: direct self-reference as well as indirect cycles like A -> B -> C -> A. These need to be detected and reported as an error.
- Legitimate repeated references.
- Complexity and design trade-offs: why put the computation in
get? Could it go insetinstead? If writes are rare and reads are frequent, which design fits better?
Result and retrospective: about eight days after the interview, the recruiter told me I didn't pass. The feedback was "Strong on coding but weak in system design."
My own retrospective is that I should have gone into much more detail in the final design discussion: read/write ratio, a per-query memo, a persistent cache, reverse dependencies, cache invalidation, and how to update dependents when a formula gets overwritten.
Next steps: the interviewer said an experienced hire usually has about 4-5 technical rounds, followed by a chat with the head of the department about fit. It wasn't clear whether that number includes the current round. Rounds can be scheduled one at a time, or several can be coordinated on the same day, depending on the recruiter.
Overall the algorithmic difficulty felt like roughly Medium, but beyond working code they keep probing your design choices and the trade-offs in a business scenario.
Discussion
Loading comments…