← Bloomberg Interview Insights

Bloomberg·Software Engineer·Onsite - System Design / Architecture·Senior

Senior
May 2026

Summary

Bloomberg SWE interview, system design round focused on building an in-memory trade subscription engine in C++. The problem looked deceptively like a coding question but quickly turned into a full design discussion about data structures, matching logic, and concurrency.

Questions Asked (3)

Q1

Design and implement the internals of an in-memory trade subscription processor in C++. Given a simplified interface with subscribe, onNewTread, and unSubscribe methods, what private data structures would you use, and how would each method work conceptually?

System DesignAlgorithms & Data StructuresTechnical Trade-offs
Author's notes

The interface looked clean so I jumped straight to a flat vector of subscriptions and immediately realized that's a disaster at 10^5 subs with tens of thousands of trades per second.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints (e.g., thread safety, performance, memory) and then propose a design using appropriate data structures like unordered_map and unordered_set. Explain each method's implementation conceptually, focusing on time complexity and trade-offs, and mention potential optimizations.

Pro tip: Demonstrate awareness of real-world concerns by discussing thread safety and lock granularity, and suggest using a read-write lock or sharding to balance performance and correctness.

1. Clarify Requirements

Ask about expected throughput, latency, thread safety, and memory constraints to tailor the design.

2. Design Data Structures

Propose using an unordered_map to map trade IDs to subscriber sets, and an unordered_set for subscribers per trade. Consider memory and lookup efficiency.

3. Implement subscribe

Add the subscriber to the set for the given trade ID, creating the set if it doesn't exist. Ensure thread safety if needed.

4. Implement onNewTrade

Look up the trade ID in the map and notify all subscribers in the associated set. Consider iteration safety and performance.

5. Implement unsubscribe

Remove the subscriber from the set for the trade ID, and delete the set if empty to free memory. Handle concurrency.

Key Points to Mention

  • Use of unordered_map for O(1) average trade ID lookup and unordered_set for O(1) average subscriber operations.
  • Thread safety mechanisms: mutexes, read-write locks, or lock-free data structures, and their trade-offs.
  • Memory management: removing empty sets to avoid leaks, and potential use of weak pointers or reference counting.
  • Performance considerations: avoiding locks during notification, using copy-on-write or snapshots.
  • Scalability: sharding by trade ID to reduce contention.
  • Error handling: dealing with duplicate subscriptions or unsubscribing non-existent subscribers.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you handle thread safety in this system, given that one thread is continuously calling onNewTread while another may be adding or removing subscriptions concurrently?

System DesignTechnical Trade-offs
Author's notes

This is where I felt the pressure.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the concurrency model and data structures involved, then discuss synchronization primitives (locks, concurrent collections, or lock-free approaches) with trade-offs. Emphasize correctness, performance, and avoiding common pitfalls like deadlocks or race conditions.

Pro tip: Mention that you'd first try to avoid shared mutable state by using immutable snapshots or message passing, and only introduce locks when necessary—this shows you understand both safety and scalability.

1. Clarify the concurrency scenario

Identify which threads access which data (e.g., onNewTread reads subscriptions, while another thread modifies them) and the required consistency guarantees.

2. Choose a synchronization strategy

Evaluate options: coarse-grained locks, fine-grained locks, read-write locks, concurrent collections, or lock-free structures. Consider contention and performance.

3. Address potential pitfalls

Discuss deadlock avoidance, lock ordering, and the impact of blocking on onNewTread's continuous execution (e.g., use non-blocking reads or copy-on-write).

4. Propose a concrete solution

Recommend a specific approach, such as using a ConcurrentHashMap for subscriptions or a ReadWriteLock, and explain how it ensures thread safety.

5. Validate and test

Mention the importance of stress testing, race condition detection tools, and code reviews to ensure the solution works under concurrency.

Key Points to Mention

  • Use of concurrent data structures like ConcurrentHashMap or CopyOnWriteArrayList
  • ReadWriteLock for scenarios with many reads and few writes
  • Atomic references and immutable snapshots to avoid locking
  • Lock granularity and its impact on performance and contention
  • Deadlock prevention through consistent lock ordering
  • Testing with tools like ThreadSanitizer or stress tests

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

What is the time and space complexity of your design for subscribe, onNewTread, and unSubscribe?

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

Pretty standard follow-up.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by briefly restating the design components (e.g., data structures used for subscriptions and thread notifications) to set context. Then analyze each operation separately, stating the time and space complexity with clear reasoning, and discuss trade-offs if applicable. Finally, summarize the overall complexity and mention any optimizations or edge cases.

Pro tip: Always relate complexity to the specific data structures and algorithms you chose, and proactively discuss trade-offs (e.g., time vs. space) to show depth. If the design uses multiple data structures, explain how they interact and affect complexity.

1. Restate the design

Briefly describe the data structures and algorithms used for subscribe, onNewThread, and unSubscribe to provide context for complexity analysis.

2. Analyze subscribe

Determine the time complexity by identifying the dominant operations (e.g., hash map insertion, list append) and space complexity by considering additional storage per subscription.

3. Analyze onNewThread

Identify how new threads are processed and notified to subscribers; analyze time complexity based on iteration over subscribers and space complexity for any temporary storage.

4. Analyze unSubscribe

Examine the removal process from data structures; state time complexity (e.g., O(1) for hash map removal, O(n) for list removal) and space complexity (usually O(1) auxiliary).

5. Summarize and discuss trade-offs

Provide a concise summary of all complexities and mention any trade-offs or potential optimizations, such as using balanced trees or concurrent data structures.

Key Points to Mention

  • Choice of data structures (e.g., hash maps, sets, lists) and their impact on complexity
  • Time complexity for each operation with justification (e.g., O(1) average for hash map operations)
  • Space complexity, including auxiliary space and storage per subscriber/thread
  • Trade-offs between time and space, such as using more memory for faster lookups
  • Edge cases like duplicate subscriptions, concurrent access, or large numbers of subscribers
  • Potential optimizations (e.g., batching notifications, lazy deletion) and their effect on complexity

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.