Bloomberg SWE Interview: Coding Interview Guide

Estimated read time: 7-9 minutes

Summary: Bloomberg SWE coding interviews are the strongest signal in the public research. Candidate reports repeatedly point to one or more rounds of coding, CS fundamentals, complexity, and follow-up problem solving. This guide explains what changes after the first screen: repeated signal, deeper follow-ups, and more chances for small communication mistakes to become a pattern.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• Bloomberg's public SWE evidence is coding-heavy, especially for intern, new grad, junior, and mid-level paths.
• Rounds are commonly reported around 45-60 minutes each.
• Expect engineers to probe CS fundamentals, data structures, edge cases, and complexity.
• Technical loop questions can overlap with phone-screen topics but usually push deeper with follow-ups.
• Experienced candidates may receive design or project-depth follow-ups, but that evidence is less consistent.

Quick FAQ

How is this different from the phone screen?
The core skills are similar, but the loop repeats the signal and may go deeper into follow-ups, debugging, and tradeoffs.

Are Bloomberg questions always finance-themed?
No. Some examples can be product or data flavored, but the core signal is software engineering fundamentals.

Should I expect multiple coding rounds?
Many reports describe more than one technical round, but your exact path depends on role and level.

---

1) How loop coding runs

The coding loop usually asks you to solve one or more problems with engineers, then explain correctness, complexity, edge cases, and possible improvements. If the first solution is correct, the interviewer may add constraints or ask you to optimize.

Because Bloomberg evidence is stronger for coding than for senior design, do not underprepare coding even if you are experienced. Senior candidates can still be filtered by fundamentals.

---

2) Candidate-facing question examples

• Given a stream of price updates, maintain the latest price per symbol and return the top k symbols by update count.
• Given a binary tree, return the lowest common ancestor of two nodes. Then handle the case where one node may not exist.
• Given event intervals from multiple systems, merge them and return gaps longer than a threshold.
• Implement a queue that supports enqueue, dequeue, and max in constant or near-constant time.
• Given a graph of dependencies, determine whether all jobs can run. Then return one valid execution order.
• Given a grid of terminals and blocked cells, find the shortest route between two terminals. Then support multiple destinations.
• Debug a function that deduplicates events but fails on out-of-order timestamps. Explain the bug and fix it.
• Implement a simple order book summary. Support add, cancel, and query best bid or ask for a symbol.

---

3) Evaluation signals

Strong candidates are repeatably clear. They avoid guessing at constraints, choose appropriate data structures, test the failure-prone cases, and explain complexity without waiting until the end.

Bloomberg-style coding reports often emphasize fundamentals, so do not hide behind high-level talk. Write working code. Then, if the interviewer asks for a design or optimization follow-up, explain the tradeoff before changing the implementation.

---

4) Common failure modes

Only preparing one topic family. Bloomberg reports span arrays, strings, trees, linked lists, graphs, intervals, and implementation tasks.

Not debugging your own code. A small bug is survivable if you can reason your way to it.

Leaving complexity vague. State time and space costs, including how they change after optimization.

Letting one rough round affect the next. Multiple technical rounds mean you need a reset habit.

---

5) How to prepare

• Run repeated 45-60 minute coding sessions with a new interviewer or reviewer when possible.
• Rotate across maps, heaps, trees, graphs, intervals, linked lists, queues, caches, and streams.
• Practice explaining the invariant behind your solution, not just the code.
• Add a follow-up to every practice problem: optimize, handle repeated queries, or support streaming input.
• For experienced roles, prepare to connect coding choices to maintainability and production constraints.