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.

Crowd-reported, not published

No company publishes its question bank. The round structure and the bar below are corroborated by recruiters and candidates; the problem list is crowd-reported, stale, and biased toward whoever posted it. Treat the pattern families as the durable signal — which families a company leans on changes far more slowly than which individual problems it uses.

The most object-oriented-design-heavy of the common targets. Expect at least one round that is class design rather than an algorithm, and expect follow-ups about extending your design.

The loop

Phone screen 1× · 45 min One or two mediums

Onsite / virtual loop 2-3× · 60 min Coding plus an explicit OOD round

Team match + manager 1× · 45 min Fit and domain interest

The bar

Design rounds are graded on extensibility. Sketch the classes and their responsibilities before writing a method body, and say which requirement each class exists to serve.

What they lean on

This is the durable part. Which pattern families a company favours is far more stable than which individual problems it uses, so prepare in this order:

1. design-with-stacks-and-queues
2. design-lru-and-lfu-caches
3. design-iterators-and-flatteners
4. linked-lists
5. hash-tables
6. strings
7. tries

Quirks worth knowing

• The OOD round is close to guaranteed. Practise the parking-lot / elevator / deck-of-cards family, not just algorithms.
• Financial-data framing is common (tickers, order books, time series) but the underlying structures are standard.
• Follow-ups are about change, not scale — "now support a second currency" rather than "now a billion users".

Reported problems

Read this before you trust the list. No company publishes its question bank. Every "asked at Bloomberg" list in circulation — including this one — is aggregated from candidate reports, is months to years out of date, and over-represents whoever bothered to post. Use it to choose an order to practise in. Do not use it as a question bank, and do not assume a problem missing from it is safe to skip.

23 problems

7 easy13 medium3 hard

AllEasyMediumHard

Unsolved onlyExportImportReset

• ○1Two SumeasyNeetCode 150Blind 75LeetCode Top Interview 150
• ○20Valid ParentheseseasyNeetCode 150Blind 75LeetCode Top Interview 150
• ○121Best Time to Buy and Sell StockeasyNeetCode 150Blind 75LeetCode Top Interview 150
• ○206Reverse Linked ListeasyNeetCode 150Blind 75
• ○21Merge Two Sorted ListseasyNeetCode 150Blind 75LeetCode Top Interview 150
• ○141Linked List CycleeasyNeetCode 150Blind 75LeetCode Top Interview 150
• ○242Valid AnagrameasyNeetCode 150Blind 75LeetCode Top Interview 150
• ○3Longest Substring Without Repeating CharactersmediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○153SummediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○53Maximum SubarraymediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○56Merge IntervalsmediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○146LRU CachemediumNeetCode 150LeetCode Top Interview 150
• ○11Container With Most WatermediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○33Search in Rotated Sorted ArraymediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○49Group AnagramsmediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○138Copy List with Random PointermediumNeetCode 150LeetCode Top Interview 150
• ○143Reorder ListmediumNeetCode 150Blind 75
• ○208Implement Trie (Prefix Tree)mediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○380Insert Delete GetRandom O(1)mediumLeetCode Top Interview 150
• ○739Daily TemperaturesmediumNeetCode 150
• ○42Trapping Rain WaterhardNeetCode 150LeetCode Top Interview 150
• ○295Find Median from Data StreamhardNeetCode 150Blind 75LeetCode Top Interview 150
• ○297Serialize and Deserialize Binary TreehardNeetCode 150Blind 75

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.