Bloomberg Software Engineer Interview Experience (2026) - 4-Round Offer

Onsite Round 1: Coding — Consecutive Element Elimination

Problem: You have a list of integers. Repeatedly find any group of 3+ consecutive equal values and remove them. After removal, newly-adjacent equal runs can combine and be eliminated too. Return the final list after all cascading eliminations.

This is Candy Crush on a 1D line. The right data structure is a stack storing (value, count) pairs. Scan the array once, merge on push (if the top is the same value, bump its count), and pop whenever the top count reaches 3. O(n) time, O(n) space.

The subtle bit: after a pop, the new top and the next incoming value might be the same, so you have to merge again. By merging on push instead of after pop, you avoid a second rescanning loop. I verbalized this invariant before coding and the interviewer nodded — I think that was the signal they were waiting for.

Practice it: [[problem/498?company=11|Consecutive Element Elimination (Candy Crush)]]

Follow-up: What if the threshold is a parameter k instead of hardcoded 3?

Replace = 3 with = k . Trivial.

Follow-up 2: What if elimination is = 3 but they don't have to be equal — they have to be strictly increasing or strictly decreasing ?

This made me stop and think. The stack approach breaks because we're no longer comparing to a single "run value." The right approach is to track a "current direction" in the stack and break into a new entry when direction changes. I sketched it verbally; didn't code it fully.

Onsite Round 2: Coding — First Unique Word in a Stream

Problem: Implement a class that processes a stream of words and can at any time return the first word that has appeared exactly once so far. Must be O(1) amortized for both operations.

This is the classic "first non-repeating character in a stream" problem, word version. My data structures:

• A doubly-linked list of "unique so far" words, in insertion order
• A hashmap from word to node in the list, with a sentinel entry for "seen multiple times"

On add , new words go to the tail and into the map. A word that reappears gets unlinked from the list in O(1) and flipped to the duplicate sentinel so it never comes back. first unique is just the head of the list. Both operations are O(1) amortized.

I spent a minute up front naming the invariants out loud ("the list contains exactly the words seen once so far, in arrival order"). That saved me from an off-by-one where I almost re-added a word after it had already flipped to the duplicate sentinel.

Practice it: [[problem/502?company=11|First Unique Word in String]]

Follow-up: What if the stream is infinite and we want to cap memory?

Tricky. If we cap memory, we can't guarantee correct answers for words whose second occurrence is outside the memory window. I said: depending on the use case, either (a) accept that words older than N are dropped, or (b) switch to a probabilistic data structure (Count-Min Sketch for repeat detection plus a bounded cache of candidates). The interviewer liked the CMS suggestion and asked me to sketch it.

Onsite Round 3: Systems — Design a Market Data Cache

Problem: Design a service that sits between Bloomberg's upstream feeds and consumer applications. It should cache recent market ticks, serve point-in-time queries ("price of AAPL at 14:32:00"), and broadcast real-time updates to subscribers.

Bloomberg's system design rounds are not "scale to 1B users." They're "design a specific, bounded system" — closer to the real work you'd do on the team.

My architecture:

1. Ingest. A thin protocol-conversion layer translates upstream feed formats (PDA, Reuters, etc.) into a canonical Tick struct with (symbol, timestamp, bid, ask, last, volume) .

2. In-memory store. Per-symbol ring buffer of the last N ticks (configurable per symbol — equities get 10K ticks, options might get 1K). Accessed by symbol - RingBuffer .

3. Point-in-time queries. A secondary sorted structure per symbol keyed by timestamp. I proposed a std::map<timestamp, Tick or a B-tree for range queries. For "price at time t," binary search for the largest timestamp <= t.

4. Historical tier. Ticks evicted from the ring buffer get flushed to cold storage (parquet on S3, or similar). Point-in-time queries older than the ring buffer's window fall through to cold storage with a much higher latency budget.

5. Broadcast. A pub/sub layer (ZeroMQ or a custom UDP multicast, both common in market-data systems) pushes ticks to subscribers. Bloomberg uses their own internal messaging, which I didn't claim to know but asked about.

The interviewer spent the last 15 minutes on one question: "What happens when you get an out-of-order tick?" My answer: accept it, but log a warning. For point-in-time queries, out-of-order ticks can change a historical answer — the alternative (rejecting them) is worse because you'd be dropping data. In practice, timestamps from exchanges are usually monotonic per symbol, and cross-symbol skew is handled by consumers.

Onsite Round 4: Behavioral + Deep Dive

Half behavioral (why Bloomberg, tell me about a project, tell me about a conflict) and half deep-dive into my most recent project. The deep dive is Bloomberg's signature — they read your resume carefully and ask you to walk through the technical details of something you built.

I picked a rate-limiting system I had built at my prior job. The interviewer grilled on:

• Why did you pick token bucket over sliding window?
• How did you handle clock skew across the rate-limit nodes?
• What happens if the Redis that stores the buckets goes down?
• Did you run it under load, and what p99 did you see?

Have numbers. "It reduced latency" is a non-answer. "It reduced p99 from 180ms to 45ms under 2K QPS sustained load" is an answer.

Result

Offer came 8 business days later. Senior SDE, standard Bloomberg comp for NYC. The base was higher than I expected, the equity lower than FAANG (private-ish company, no public stock) but compensated by a fixed bonus.

Tips

1. Bloomberg loves stack-based problems. The elimination problem, parenthesis validation, daily-temperatures, next-greater-element — these are all variations on the same pattern. If you master the monotonic stack, you cover a big chunk of Bloomberg's coding pool.
2. For the deep dive round, have *your* project. Not "the team's project." Not "what my team worked on last quarter." Pick something you owned end-to-end and can talk about for 45 minutes with numbers at every turn.
3. Expect protocol-level questions in system design. Bloomberg designs real distributed systems, not toy "scale to 1B users" diagrams. Expect questions about UDP vs TCP, multicast, message ordering, and retransmission.
4. Prep C++ if the role lists it. About half of Bloomberg's teams are C++-heavy. They'll let you code in Python in the interview but will ask C++-flavored questions (memory management, RAII, when to use `std::map` vs `std::unordered_map`). I coded in Python but had to answer those questions.
5. The "why Bloomberg" answer that works is specific. "I love finance" is weak. "I've been using the terminal for 3 years and I find the PX1 screen shockingly good" is memorable. Find something concrete you can point to.
6. Don't under-prep because it's not FAANG. Bloomberg's bar on pure algorithmic skill is as high as Google's. The loop is less theatrical, not less selective.

Bloomberg's loop is honest, technical, and free of the performance theater you get at some other companies. I enjoyed the interviews more than any other loop I did in 2026.