Bloomberg Software Engineer Interview Questions
Software engineers at Bloomberg build the systems behind financial data, news and analysis used by people in markets around the world. The problems mix algorithms with domain rules: order books, running calculations over streams, history adjusted for share splits, and search across a very large news archive. Prepare stories about careful testing, working with finance specialists and finding hidden slowdowns. What to show here: sound algorithms applied to real market rules. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Bloomberg hires, in its own words, and its questions for every job →
1. An order book holds buy and sell orders for one share at many price levels. Orders are added and cancelled all the time. How would you structure it so the best buy and best sell price are always ready at once?
- Keep two sides, buys and sells, each ordered by price.
- Hold total quantity at each price level.
- Use a map from order identifier to its place, for quick cancels.
- State the cost of add, cancel and read best price.
“I would keep two ordered structures, one for buys and one for sells, keyed by price. A balanced tree works, or an array of price levels if the prices fall in a narrow range. Each level holds its total quantity and a queue of orders in arrival order. For cancels I need to find an order directly, so I keep a hash map from order identifier to its node. Reading the best price means reading the top of each side, which I can also cache and update on change. I would test with a level that empties, since that is where bugs hide.”
Weak answers use one unsorted list and search it each time, or have no quick way to cancel an order.
2. You need the average price of a share over the last twenty minutes, updated on every new trade. How do you compute it without adding up the whole window each time?
- Keep a queue of trades in the window and a running sum.
- On a new trade, add it and remove those that are now too old.
- Guard against drift in the running sum.
- Decide what to do with late trades.
“I would keep a queue of the trades inside the window, plus a running sum and a count. When a trade arrives, I add it to the back and update the sum. Then I remove trades from the front that are older than the window and subtract them. The average is the sum divided by the count, so each update is cheap. If the sum is floating point, small errors build up over a long day, so I would use whole number units or rebuild the sum from the queue now and then. I would also ask whether the average should weigh each trade by its size.”
Weak answers loop over the full window on each trade, or never ask whether the average is weighted by quantity.
3. Design a search over a news archive that goes back many years, where users want the newest and most relevant stories about a company within moments of publication.
- Clarify query types and how fresh results must be.
- Build an inverted index, with stories tagged by company.
- Keep a small fast index for new stories and a large one for the archive.
- Rank by relevance and recency together.
- Handle corrections and withdrawn stories.
“I would split the index in two. New stories go into a small index that is updated at once, so they are searchable almost immediately. Older stories live in a large index, split by time, that is built in the background. A query goes to both and the results are merged. Stories are tagged with the companies they mention, because names in text are unclear and one company has many spellings. Ranking mixes text match with recency, since in news an older story is usually less useful. A corrected or withdrawn story must update both indexes, not only the new one.”
Weak answers rebuild one giant index for each new story, or rank by text match alone and ignore how recent a story is.
4. A function that handles every incoming price message has become slower over several releases, and nobody knows why. How do you find the cause?
- Build a repeatable benchmark with recorded messages.
- Compare releases to find where the slowdown began.
- Profile the slow version for time and memory allocation.
- Fix, confirm with the benchmark and keep the benchmark in the build.
“I would first make the problem repeatable. I would record a sample of real messages and replay it against the function in a benchmark, so I get stable numbers. Then I would run that benchmark against older releases and search between versions to find the change where it got slower. On that version I would use a profiler, looking at both time and memory allocation. On a hot path the cause is often a new allocation, a copy of a large object or a log line that builds text. After the fix, I would keep the benchmark in the build so the next slowdown is caught early.”
Weak answers start rewriting code by instinct, or measure once on a busy machine and trust that figure.
5. Tell me about a change you made where a mistake could have cost users money. What extra care did you take before it went live?
- Describe the change and what could go wrong.
- Explain the extra tests and reviews you arranged.
- Describe the release plan and the way back.
- Share what happened.
“At your company I changed how a fee was calculated in your project. A mistake would have put wrong amounts on customer statements. Beyond unit tests, I ran the old and new code side by side on a copy of real data and compared every result. Where they differed, I checked each case by hand with a colleague from the finance team. I asked for two reviewers and not one. We released behind a switch to a small group first, with the old path ready to turn back on. The result was your result.”
Weak answers treat a risky change like any other, or rely on tests they wrote themselves with no comparison against real data.
6. Describe a time you worked with a specialist who was not an engineer, such as a finance or legal expert, to get a business rule exactly right in code.
- Describe the rule and why it was hard.
- Explain how you gathered examples and edge cases.
- Show how the expert checked your result.
- Share what you learned about the domain.
“In your project I had to code a rule for how interest built up over time, and the written rule left gaps. I met the specialist who owned it and asked for worked examples instead of definitions. I turned each example into a test. Then I asked about odd cases, such as a period that crossed a holiday, and she found two I had wrong. Before release she reviewed a table of results, not my code, because that was what she could judge. The result was your result. I now ask for examples first on any domain rule.”
Weak answers guess at the rule from a document, or expect the expert to read code to find mistakes.
7. A company splits each of its shares in two, so the price halves overnight. The next morning your price chart shows what looks like a crash. What do you do?
- Confirm the cause is a split and not bad data.
- Explain that prices before the split must be adjusted to compare.
- Keep raw prices and store the adjustment factor apart.
- Test with other events and make the chart say which view it shows.
“I would first confirm that a split took place, so I do not hide a real fall or a data fault. If it was a split, the chart is comparing two different units. The fix is to adjust prices from before the split by the split ratio, so the line is continuous. I would never overwrite the raw prices. I would store the events and their factors apart and apply them when reading, because some users need the raw values. Then I would check similar events, such as a reverse split, and make sure the chart tells the user which view they are seeing.”
Weak answers treat it as a display bug and smooth the line, or overwrite stored history with adjusted values.
8. What interests you about writing software for financial markets, and why Bloomberg?
- Say which engineering problems you like.
- Link them to financial data, news and analysis.
- Show you accept the need for care and correctness.
- Say how you want to grow.
“I like problems where a clean algorithm meets messy real rules. Financial data is full of them: splits, holidays, different trading hours and corrections that arrive late. Bloomberg provides data, news and analysis to people who depend on them for decisions, so correctness is part of the engineering and not an extra. In my work on your project I enjoyed the careful parts most, such as comparing old and new results row by row. I want to work where that care is normal, and to learn the domain well enough to spot a wrong number by sight.”
Weak answers say they want to learn trading for themselves, or cannot say what the company's products do.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.