Bloomberg Interview Guide

Bloomberg is the company on this page most likely to ask you to design classes, not just write a function. Expect object-oriented design as a distinct round or a large chunk of a coding round -- model a trading system, an order book, a subscription feed -- and expect follow-ups about extension rather than complexity.

The data-structure questions skew toward the practical and composite: LRU caches, iterators, ordered collections, anything where the answer is two structures working together. That maps directly onto this course's design-problems phase.

Pitfalls

• Writing a function when they asked for a design. If the prompt names entities, produce classes with responsibilities and relationships, not one long function.
• Designing for the current requirement only. The follow-up is almost always "now add X". Leave an obvious extension point and say where it is.
• Over-engineering in the other direction. Five interfaces for a two-entity problem reads as poor judgement. Model what exists, name where you would extend.
• Skipping the composite-structure insight. Most of their data-structure questions want two structures cooperating -- a map for lookup plus a linked list for ordering. Saying "neither alone can do both" is the answer they want to hear.

Interview follow-ups

They ask	What they're checking	The answer
"Design an order book."	Whether you model before coding	Name the entities and their responsibilities first -- orders, price levels, the book -- then the structure per operation: a heap or sorted map per side, a map from order id to node for cancellation.
"Now add order cancellation."	Whether your design has an extension point	This is why you keep an id-to-node map. If your first design cannot cancel in better than $O(n)$, say what you would change rather than defending it.
"Why do you need two data structures?"	The composite insight	One gives $O(1)$ lookup and no ordering; the other gives ordering and $O(1)$ removal of a known node. Neither alone does both -- that sentence is the answer.
"How would you extend this to multiple instruments?"	Whether the model generalises	A book per instrument behind a registry, and say what becomes shared versus per-instrument. Extension questions are the standard shape here.

Recall card

• Most likely to ask for classes, not functions. OOD is a distinct round or a large slice of one.
• Model the entities and responsibilities first, then pick a structure per operation.
• Leave an obvious extension point -- the follow-up is always "now add X". But do not over-abstract.
• Composite structures are the recurring insight: map for lookup + list for ordering, because neither alone does both.
• Practical data structures dominate -- caches, iterators, ordered collections. See the design-problems phase.

Self-check

quizCheck yourself

1. A prompt says 'design an order book'. What should you do first?

   AAsk for the time complexity targetBStart with a database schemaCWrite one long functionDName the entities and their responsibilities, then choose a structure per operation
   Show answer

   D — Name the entities and their responsibilities, then choose a structure per operation — Bloomberg leans toward object-oriented design. Model first, then pick data structures.

2. Why do many Bloomberg data-structure questions want two structures cooperating?

   AOne gives O(1) lookup without order, the other gives order and O(1) removal of a known node; neither alone does bothBPython has no single structure for thisCIt is a house style ruleDTo make code longer
   Show answer

   A — One gives O(1) lookup without order, the other gives order and O(1) removal of a known node; neither alone does both — A map plus a linked list, as in an LRU cache, is the recurring example. Saying why neither alone works is the answer they want.

3. Your first design cannot cancel an order faster than O(n). What is the right response to the follow-up?

   ADefend it as good enoughBSay what you would change, for example an id-to-node mapCRefuse the follow-upDSwitch to a different language
   Show answer

   B — Say what you would change, for example an id-to-node map — The follow-up is almost always 'now add X'. Acknowledging the gap and naming the fix scores better than defending the design.