Decode String (LeetCode 394) — given an encoded string of the form k[encoded_string], decode it by repeating the inner string exactly k times (e.g. '3[a2[c]]' → 'accaccacc').

Use a stack: push the current count and the built string onto the stack whenever you see '[', then pop and multiply when you see ']'. Time O(max-k * n), space O(n). The key insight is that nested brackets demand a stack, not simple iteration. Common follow-up: handle multi-digit k; handle edge cases like plain text with no brackets. Comfort with stack-based parsing of nested structures; clean handling of digit accumulation and string building without extra passes.

Merge Intervals (LeetCode 56) — given an array of intervals, merge all overlapping intervals and return the result.

Sort by start time O(n log n), then do a single linear pass merging whenever the current interval's start is <= the last merged interval's end. Overall O(n log n) time, O(n) space. Follow-ups often ask about inserting a new interval into an already-sorted list (LC 57) or applying this to a financial scheduling context. Ability to recognize the sort-then-sweep pattern; correct off-by-one on the overlap condition; discussion of edge cases (touching intervals, single interval).

Invalid Transactions (LeetCode 1169) — given a list of transaction strings 'name,time,amount,city', return all transactions that are either amount > 1000 or share the same name as another transaction in a different city within 60 minutes.

Group transactions by name into a hash map. For each transaction, check the amount rule directly, then do a pairwise scan within the same-name group for the time+city rule. Time O(n^2) worst case per name, but acceptable given constraints. Follow-up: how would you scale this to a streaming feed of millions of transactions per second? Correct multi-condition filtering; grouping strategy; candidate flags that both the flagged transaction AND the one it conflicts with should be included in the output.

Design an IP address store — design a service that can store, look up, and efficiently query large volumes of IP addresses (e.g., for rate limiting, geo-blocking, or audit logging). Reported directly by a 2025 Bloomberg Senior SWE/SRE candidate on Substack.

Start by clarifying operations: insert, exact lookup, prefix/range query, and expected volume. A trie (prefix tree) over the 32-bit address gives O(32) per operation and enables efficient prefix queries. A hash set handles O(1) exact lookup but not range queries. Discuss trade-offs: trie uses more memory but enables CIDR-block queries natively. For scale, partition the trie by the top octet (256 shards), replicate for read throughput. Follow-up: support IPv6 (128-bit addresses); handle concurrent writes. Whether the candidate identifies that the interesting constraint is range/prefix query, not just key-value storage; trie is the expected insight; ability to reason about memory vs. query-flexibility trade-off.

Design an in-memory trade subscription processor — design a system that manages client registrations for financial instrument events and delivers real-time updates when instruments change status (e.g., price update, delist, stock split). Reported in Bloomberg interview experience write-ups as 'in-memory services to manage registrations for events'.

Core components: a subscription registry (instrument ID -> set of subscriber IDs), an event ingestion layer (Kafka or internal bus), a dispatcher (fan-out per event to all subscribers), and a delivery layer (WebSocket or server-sent events). For in-memory: use a concurrent hash map of topic -> subscriber list; a thread pool dispatches events. Discuss ordering guarantees (per-instrument ordering with partition-by-ticker), back-pressure (slow subscriber gets a bounded queue then drops or disconnects), and recovery (replay from a persistent log on reconnect). Follow-up: how do you handle a subscriber missing events during a brief disconnection? Clarity on the pub-sub pattern vs. request-response; recognition that financial event delivery requires per-instrument ordering; proactive discussion of the slow-consumer problem.

Design a distributed rate limiter for Bloomberg's public API — limit request volume per client ID across multiple API gateway nodes. Reported in Bloomberg system design interview guides sourced from candidate reports.

Token bucket or sliding window counter are the two main algorithms to compare. Token bucket: each client key maps to a (tokens, last_refill_timestamp) tuple; refill at a fixed rate, reject when tokens exhausted. For distribution: store state in Redis with Lua scripts for atomic check-and-decrement. Single Redis node is a SPOF; use Redis Cluster with consistent hashing on client ID. Discuss eventual-consistency approaches (each node holds a local counter and syncs periodically) vs. strong consistency. Follow-up: per-endpoint rate limits; burst allowances; how to handle Redis failover without cascading 429s. Candidate distinguishes between the algorithm choice and the distribution problem; Redis-based atomic update via Lua is the expected production answer; awareness of the CAP trade-off in a rate-limiting context.

Why Bloomberg? Why do you want to work here specifically — not just at a tech company?

Generic answers about prestige or compensation fail. A strong answer connects to Bloomberg's core mission: market transparency, the Bloomberg Terminal as critical financial infrastructure, open-source contributions (OpenBBTerminal, Powdermill), or the scale and complexity of real-time financial data systems. Tie it to a specific product, team, or technical challenge you researched. Interviewers listen for whether the candidate understands what Bloomberg actually builds. Genuine preparation and intellectual curiosity about Bloomberg's domain; candidate can articulate the difference between Bloomberg and a generic tech company; red flag is a vague or flattering non-answer.

Tell me about a time you took ownership of a failing project or a situation where something went wrong.

Use STAR: set up a concrete failing project (behind schedule, bad architecture, team conflict), describe the specific actions you took to intervene or pivot — not just 'I worked hard' but tangible decisions — and quantify the outcome. Bloomberg's culture prizes individual accountability; the answer should show you diagnosed the root cause, made a call, and drove it to resolution rather than escalating passively. Evidence of personal accountability rather than blame-sharing; concrete actions not vague effort; awareness of what the candidate would do differently; composure in describing failure.

Describe a time you disagreed with a teammate or a superior and how you resolved it.

Structure: establish the technical or design disagreement clearly, explain your reasoning and how you communicated it (data, prototyping, seeking third-party input), describe how the disagreement was resolved, and reflect on the relationship outcome. Bloomberg wants engineers who can hold a technical position under pressure but ultimately collaborate. Avoid anecdotes where you simply capitulated or where you 'won' dismissively. Ability to disagree constructively without damaging relationships; use of evidence over authority; willingness to update position given new data; respect for the other party's perspective.

Bloomberg Interview Questions

Bloomberg's SWE interview loop typically runs 4-5 rounds conducted over 1-2 weeks: two to three technical coding rounds (HackerRank/Zoom, 45-60 min each, usually 1-2 LeetCode-medium problems per round), one unique code-review round (several hundred lines of intentionally buggy C++ to critique like a PR), an optional system design round (senior roles), and a behavioral/manager close with a senior director or EM. The process is language-agnostic in coding but most teams are heavy C++; interviewers weigh verbal communication and reasoning as heavily as correctness. Multiple candidates report solving every problem and still being rejected due to poor behavioral fit and an unconvincing answer to "Why Bloomberg?"

21 real questions across 3 rounds

Reported via LeetCode Bloomberg company tag (hxu296/LeetCode-Questions-CompanyWise CSV, krishnadey30 company-wise repo), LeetCode Discuss threads (post/682024, post/4187528, post/7363661, post/7347254, post/6069292, post/964672, post/439548), first-hand Medium write-up by Akash Kumar (akash-kumar916.medium.com 2024), Substack reports (reliabilitywhisperer.substack.com 2025), interviewing.io Bloomberg guide, Glassdoor Bloomberg SWE reviews 2024-2025 · Bloomberg Blind thread 'Bloomberg Interview Code Review Round' (teamblind.com/post/bloomberg-interview-code-review-round-jknhwkaw), reliabilitywhisperer.substack.com 2025 Senior SWE experience, prepfully.com Bloomberg guide citing multiple candidate debriefs, TechPrep Bloomberg interview process guide, interviewing.io Bloomberg page

9 more coding questions Bloomberg actually asks, each with how to approach it and exactly what the interviewer is evaluating. Unlock the full set across every round.

Continue with Google

Or run a Bloomberg mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews